Six Microservices Design Principles: Do We Really Know It Well?

Microservices have truly become an evolutionary form of software engineering concept that has eliminated the traditional enterprise application development issues. Its development pattern encourages organizations to adopt an agile methodology, implement CI/CD through DevOps practices, and accelerate growth in the competing market environment.

But the road to such an ideal SDLC is filled with challenges. Trendyol, a Turkey-based e-commerce company, struggled to implement a microservices architectural style for years. Their experienced developers recount how issues like data ownership, communication patterns, improper project planning, and monitoring led to an implementation failure.

There are countless examples of failed microservices implementation – not because the developers did not understand the concept and its functionality, but because its implementation was unsound. Instances include using a technology stack that developers need but do not understand or are unable to integrate and work together, lack of autonomy, faulty software architecture design, or following the same principles of monolithic application architecture.

Microservices design principles allow developers to make critical design decisions about their architecture, the frameworks, and the tools they can utilize to navigate the vast technology landscape. Let’s look into the concepts to know more about its design principles and how the architecture responds to every principle.

The history of design principles of microservices started way back in the early 80s when the cornerstone of systems distribution technology was introduced. It gave a path to a digital transformation since these principles act as a guiding theory and inform us about the basic tenets of any architecture.

It was in the early 2000s that one of the first standardized design principles was conceptualized and published in the paper “Design Principles and Design Patterns”. Robert C Martin conceived the first five principles for Object-Oriented design, which would act as a guideline for implementing segregated business services. Later, Michael Feathers created the acronym SOLID, as we know it today.

• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

Each principle of the SOLID concept outlines a microservices architecture and pilot developers to create a fully functional, maintainable, usable, and dependable application. It can be said that SOLID principles are a direct consequence of a well-made service-oriented architecture, and not following principles can make it a little clumsy for engineers to manage.

While SOLID principles can be applied to microservices and used as a standard compliance, it must be kept in mind that this principle was originally created for Object-Oriented design. For a complex system like microservices, there needs to be more flexibility, availability, and autonomy for every developer to utilize microservices to its fullest.

Unlike an Object-Oriented design pattern, a distributed system like microservices does not have any solid microservice principles in place. For a complex architecture with independent and autonomous functioning services, limiting the principles to an acronym would be unfair. Instead, we would try to list out some of the ideal and best microservice design principles, along with its implementation strategies, to set a guideline for best practices while designing a microservices architecture.

Martin Fowler defines a single concern or single responsibility as the primary tenant of the microservices architecture – performing a single task as a suite of small services. Every business capability within a microservices architecture is distributed into a single service/module, and that module is responsible for performing a particular task assigned to it. This means that a single service is independent of the entire system and is not responsible for other functions within the application architecture.

For example, a service responsible for carrying out authentication would only ensure that the authentication tasks are being performed. The design interface exposes the access points that are simply required for authentication purposes, and it is separate from other security-related functions that determine app behavior.

The single concern principle goes hand-in-hand with the microservices architecture style, which states that each deployment unit must contain one or a few highly cohesive services. This makes the microservices architecture easy to maintain and scale with evolving business requirements and a growing tech stack.

Implementation:

In 2018, GojekTech released a new internal chat service that connected consumers directly with their business partners. The problem was that it depended on too many services to function efficiently, and failure of a single function would inevitably affect the chat services.

So, by employing microservices single responsibility principle, they got rid of the authentication token, added a separate database for the service, and established an asynchronous communication for quick channel creation. This improved their application availability and enabled strong data consistency. Eventually, their chat service – ‘Icebreaker’ – was doing the single function it was meant to in the first place.

With different business domains, modules, and services segregated across the microservices architecture, there is often a mass of frontend (client programs) tied to one logic. When everything is connected to the same logic, an important design concern may arise since it can create multiple efficiency bottlenecks. To avoid that problem, interface segregation is a necessary principle. The goal is to ensure that each type of frontend is attached to the service contracts that would best serve its requirements.

For example, different clients use different protocols. A mobile application might respond to a short JSON representation of data, while on the other end, an old desktop app might call the same service with a full representation in XML. The idea is to make sure that clients are not forced to depend on an interface they do not use and limit performance bottlenecks to a minimum.

Engineers working on microservices often complain about bloated architecture with old or unused services to a single interface. This is a result of not having a standard principle or practice on an organizational level right when engineers start with the new architecture.

Implementation:

An API gateway is the best way to go around for implementing the principle. The advantage of using an API gateway is that it can handle message format transformation, protocol bridging, message structure transformation, routing, and much more. An instance of using the API gateway the right way is the Backend for Frontend pattern, where an API gateway is implemented for each type of client.

Intercommunication and interaction between the service users and the services determine the functioning of a microservices architecture. Tightly coupled services always run at the risk of affecting the entire application, even if it’s a minor change or security issue like memory leaks and database connectivity issues. The challenges usually multiply when business logic evolves, or new features are to be implemented.

For example, when service users send a request, the services need to respond to the call immediately and effectively. This stream of communication is maintained through a service contract. When the contract is tightly coupled to the implementation details or technology, it becomes difficult for engineers to change with evolved software engineering patterns. On the other hand, loosely coupled services are flexible and adaptable, reducing the dependencies between components, thus, making it easy to scale business with minimal effects.

The effects of loosely coupled services are easily determined by their qualitative effects on the services and user interaction with the services. When done correctly, negative impacts, upon changes, are usually reflected on a single interface instead of affecting the entire service. It helps in the easy identification of faults and allows quick modification upon scaling.

Implementation:

The Alibaba Cloud Research and Development Teams utilized REST to make their overall program architecture loosely coupled. As a result, managing their microservice became easy and quick with uninterrupted and distributed services. In addition, they soon realized that they had eliminated any sort of downtime or malfunction due to operational services over a particular microservice.

Implementing loose coupling is all about standardizing coding at an organizational level and following the best practices. Here is a list of some strategies you can utilize to implement the principle of loose coupling for your microservices architecture.

• Avoid the concept of a shared database with clients.
• Avoid sharing dependency libraries and keep shared codes with minimal dependencies.
• Use asynchronous communication through polling and using a message broker.
• Avoid sharing mocked services with other services.
• Try not to share your domain data excessively.

The essence of microservices architecture principle lie in its autonomy – service autonomy, engineer’s autonomy over services, and high availability for consumers. It dictates the parameters for scalability and enhances reliability for an extended period of time, even after services or business capabilities change.

For example, every service acts on the incoming data and responds back by producing its own data without being dictated by other services. While API gateways call for additional services during a function, the service in question must always be autonomous and independent from other tasks.

Most importantly, autonomy determines the behavior of the services and gives a precise prediction over its functions. Tight coupling often leads to less autonomy, eventually making it less predictable about its availability, consistency, and speed. To ensure that the services are autonomous, loose coupling and decentralized databases are the best implementation strategies to make your way ahead.

Implementation:

Autonomy defines the structure of microservices architecture and ensures that everything related to services is independent in nature. This includes communication contracts, databases, dependencies, boundaries, and consistency. Here is a list of some of the best practices you can follow to ensure your services retain autonomy –

• Structure small organizational teams around one service (two pizza teams).
• Maintain a decentralized database with every service having its own data with no shared connections.
• Implement the circuit breaker pattern to make your service failure-proof.
• Enable the right amount of cohesive functionality by not letting your services rely on other services or external resources.
• Each service must be independently deployable so that it can be rolled out and modified as per its performance.

One of the principles that make microservices easier for engineers to handle is its principle of discreteness. It is well-encapsulated and has a boundary that separates it from its environment. By this logic, it also means that all logic and data of a single service must be encapsulated in a single unit – deployed and managed independently.

For example, a Linux container, .NET DLL, WebAssembly binary, Nodejs package are all instances of discrete deployment. The focus for microservices engineers has always been on ensuring that the services are packaged and deployed over an appropriate runtime environment. The number of deployments and their speed is what determines the success of microservices.

All the processes and activities regarding deployment revolve around the configuration of the runtime environment and scaling and migrating from one runtime environment to another. In addition, the services are subjected to their own CI/CD processes that minimize downtime while modifying or replacing every new version of the service.

Implementation:

Achieving good deployability must be the goal of every engineer handling microservices architecture. While automation plays a huge role in this process, let us look at some of the strategies that can make deployment easy –

• Automate your deployment processes and employ CI/CD methodologies for a better time to market.
• Utilize containerization and container orchestration with platforms like Docker and Kubernetes.
• Employ service mesh for monitoring, authentication, circuit breaker, etc., to command over the communication services.
• Utilize API gateways for quick and transparent communication between services across the architecture.
• Take advantage of serverless architecture like AWS, Google Cloud, and Azure for limitless capabilities and scaling.

Event-driven architecture is a great way to keep the line of events open when a service has to scale independently and be built around business capabilities. In this architecture, event triggers are sent across the decoupled services for communicating with multiple services simultaneously. In addition, instead of using synchronous call, which often runs the risk of blocking a system process, asynchronous communication is utilized to keep the chain running.

There are 3 components that make the event-driven architecture unique –

• Event producer – Publishes events to the router.
• Event router – Filters events pushed by the producer and moves it towards the consumer.
• Event consumer – Accepts the filtered events and displays it to the consumer.

With an event-driven architecture, scalability improves multifold as the architecture keeps accommodating workload surges. Since every service is independent, the event router works specifically for those services without depending on other resources, therefore making it fail-proof and secured in case of downtime. Furthermore, this architecture’s features eliminate the need to write custom codes for poll, filters, and route events that bring agility and improve development speed. Coupled with microservices, an event-driven architecture brings in benefits of loose coupling, high performance, maintains asynchronous message/communication, improves reliability and availability.

Implementation:

The demand for speed and quality drives the software development market to develop evolving ways of combining different methodologies while creating an application. Combining event-driven architecture within a microservices setting is a comparatively new methodology engineers are adopting.

Here is a list of some of the best practices you can adopt to ensure that your event-driven architecture integrates well with your microservices –

• Utilize REST along with EDA for better communication and transactions.
• Choose a messaging framework – Message processing, Stream processing, or a unique combination of both offered by Pulsar, NATS, Kafka, etc.
• Utilize CQRS to combat the issues of event sourcing.
• Catalog your services and events for transparency of event information.
• Document every event to address challenges in case of any event schema change.

The moment you decide to get into the world of microservices, you carve out a path full of adventure – betrayal, obstacles, joy, sorrow, dejection – a journey you shall never forget.

A bit poetic, but that’s the beauty of it all!

The journey is all worth it when you have a guiding principle to help you construct the robust, efficient, secure, and reliable microservices architecture. It doesn’t matter if you are starting from scratch or in the process of transitioning, the principles aid engineers in making a fully conscious decision about their architecture or how to go about it.

Our team of experts at Simform revolutionized the EV charging platform “FreeWire” by utilizing microservices design principles to create a scalable infrastructure. We built a cloud-based back-office management and fleet management system where every service like billing, charging, requests, service delivery were distinct, autonomous, separate, and performed a single functionality. As a result, FreeWire Mobi’s services were always up, service segregation improved availability, and engineers could scale it over cloud as per business requirements.

If you find yourself in the process of designing your microservices architecture, then our experienced microservices engineers are present to aid you in the process. So get in touch with our microservices today!