Introduction

In modern development, large companies are moving from monolithic architecture to microservice architecture. In client development, there are the same tendencies, only client developers come to microfiche architecture. Let's return to microservices. Microservice architecture has become the answer to these challenges, providing modularity and the ability to independently develop components. Using this approach is associated with numerous difficulties, especially over time, in the field of service support. What approach should be followed to make the service easy to modify and maintain for the entire duration of its existence? That's why one of the main tasks for developers is to choose the appropriate design principles. Traditional principles such as SOLID offer approaches to code modularity and readability. But do they fully cover the complexity for microservices? Or maybe newer approaches such as IDEALS are better suited for distributed systems?

What is a microservice? Microservice is an architectural style that involves dividing an application into separate independent modules. Each microservice is responsible for strictly defined functionality and interacts with others through APIs or events. This approach contrasts with monolithic architecture, where all system components are closely connected. From the microservice architecture, we get a solution to all the disadvantages that exist in a monolithic architecture.: Independence of the system components. Each microservice is developed, designed and deployed separately. Weak connectivity between the systems. There is little connectivity between other microservices, as communication takes place using predefined protocols. If the endpoint changes, other services will be notified about it. Modularity. Each functional part of the application is isolated, which makes it easier to make changes.

An example of successful microservices is Netflix, where thousands of microservices work together to provide users with seamless content. When you see how many microservices Netflix has, you can admire it. However, microservice architecture requires more attention to design and support issues. This is where various principles such as SOLID and IDEALS come to the rescue.

The role of SOLID and IDEALS principles

SOLID Principles The SOLID principles were developed for object-oriented programming, but their ideas apply to microservices as well. Here's how they can be useful:

1. Single Responsibility Principle: Each microservice must perform one clearly defined task. For example, the authorization service should not handle payment processing.
2. Open/Closed Principle: The microservice code should be ready for expansion, but its main parts should not change often. This allows you to add new features without breaking existing functionality.
3. Liskov Substitution Principle: this principle is more applicable to the internal structure of the service. For example, if a microservice implements a database interface, replacing one type of storage with another should not disrupt the service. With this approach, you can easily change specific parts of the system, relying only on protocols.
4. Interface Segregation Principle: The microservice API should not be overloaded with unnecessary methods. For example, the client service should not know about the internal operations of the admin interface.
5. Dependency Inversion Principle: high-level modules should not depend directly on low-level ones, both should depend on abstractions. In microservices, this is reflected in the use of standard protocols for interaction, such as REST or gRPC.

SOLID principles improve the readability and testability of code, as well as allow you to isolate functionality well under interfaces. But this approach also has drawbacks, since some principles are more difficult to implement in distributed systems and this may lead to excessive detail, which ultimately increases the complexity of the project.

The principles of IDEALS The IDEAS principles proposed by Sam Newman are specifically focused on microservice architecture. They focus more on the aspects of interaction between services and their deployment.:

1. Isolated State: Each microservice manages its own data, which avoids synchronization issues.
2. Deployability (Deployment Independence): Microservices should be deployed independently to minimize the risks of upgrades.
3. Event-Driven architecture: Interaction between microservices should be asynchronous to avoid blockages.
4. Availability over Consistency (Availability is more important than consistency): distributed systems often face the problem of the CAP theorem. IDEALS suggests choosing the availability of data, even if it temporarily disrupts its consistency.
5. Loose Coupling: minimizing dependencies between microservices.
6. Single Responsibility (Sole responsibility): it echoes a similar principle from SOLID, but at the service level.

IDEALS is more focused on the specifics of microservices, and also facilitates scaling and collaboration in a distributed system. In comparison to SOLID, this approach is most applicable to microservice architecture. But in this approach, you need to spend more time understanding. And as a result, an event-based approach can complicate debugging throughout the system.

Other principles Besides SOLID and IDEALS, there are other approaches that can help in designing microservices:

• The DDD (Domain-Driven Design) principle: helps to focus on a specific domain domain, which can help microservices build a zone of responsibility.
• The CQRS (Command Query Responsibility Segregation) principle allows you to separate read and write operations, thereby simplifying interaction with databases.

Each of these approaches is applicable to a certain extent in microservice architecture. Of the entire set of principles, I believe it is necessary to determine the most important ones for our specific task and use a combination of the sets.

What do I think about this I have quite a bit of experience with microservices, and most of the answers are based on theory. But now I'm working on a mobile development task, and I'm splitting the main application into micro-applications, which is somewhat similar to microservices. And I also have to put these principles into practice. The most important thing is the separation of responsibilities, reducing the number of links between modules. Otherwise, if there are so many connections, why not combine this code base. The principle of interface separation is also actively used. It allows you to make connectivity between modules based on interfaces, and also allows you to reduce the build speed in the application. Similarly, I think some of the principles also apply to the development of backend micro services.

Conclusion The SOLID and IDEALS principles are hikes, principles that can significantly improve the maintainability of specific microservices. However, in the programming world, there is no single correct approach. In real projects, which often have deadlines, there is not always time to follow them. But in an ideal world, these approaches are useful and can be combined with each other. It is important to have a thorough understanding of their application, so that in the area of code you are working with, these principles immediately arise and are applied to tasks. Microservices do an excellent job of their distribution task, but their support requires careful design and team training. And the success of a microservice depends on applying these principles wisely.

Sources

1. Newman, Sam. Building Microservices: Designing Fine-Grained Systems. O’Reilly Media, 2021.
2. Martin, Robert C. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall, 2017.
3. Fowler, Martin. Microservices Resource Guide. martinfowler.com.