Microservices for the Benefits, Not the Hustle | Kiss & Solid

← All opinionsFrom time to time I hear people saying "It cannot be scaled because it is a monolith, we need to rebuild it as microservices". If you think this way, read on, this article is for you.

Making a system scalable — or cheaper to scale — is the first benefit that comes to mind when you think about microservices. Unfortunately, this is not even true until you reach a certain load on your system. And in most cases, this break-even point is far away. The root cause for this misunderstanding is the fact that companies that promoted microservices indeed have a huge load (e.g. Netflix, Amazon, Twitter) but this is probably not the case for the rest of us.

But still, I'm a believer in microservices, even if you do not have a big load on your system. I hope this article helps you to understand all the other benefits and how to make the most out of it.

What is important to understand is, that you have to define and rank your requirements before building the architecture. Depending on the ranking of your requirements the best microservice architecture might look completely different!

This article explains the purposes and risks of microservice architectures. It further gives some hints on how an architecture must look to meet reusability and maintainability requirements. At some points, it also compares microservice to traditional service-oriented architectures (SOA).

Purpose 1: Minimize Costs of Change

Minimizing the costs for new or changed requirements is (in my opinion) the major benefit of the microservice architecture style. This benefit comes directly from the "single responsibility principle". The microservices pattern prescribes radical rules to enforce this principle to maximize its benefits.

To prevent code is added where it doesn't belong and to ensure changeability, the microservice pattern recommends that:

different responsibilities are placed in different services

each service has its code repository

each instance of a microservice is executed as a dedicated process

inter-service communication is only allowed through a network connection. In addition, services must use their official API to talk to each other: it is not allowed that one service to access the data of a database that has been written by another service. Each service must have its own logical database schema!

the protocol used for communication must be technology agnostic (interoperable). This means a service should not assume that another service is written in a specific programming language.

choreography should be preferred over orchestration

Some of these principles might remind us of a traditional service-oriented architecture (SOA). Each microservice architecture is a service-oriented architecture, but not the other way around. There are some discussions about whether microservices are SOA done right.

The difference that makes a service-oriented architecture a microservice architecture is, you guessed it, a smaller service size and lightweight protocols. The smaller service size is a result of applying the first principle from the list above: place different responsibilities into different services.

Later in this article, we'll have a closer look at how to decide which responsibilities go together into one service and which should be better separated. For now, we assume that a well-done microservice architecture is in place and examine how each of the rules above contributes to lower costs of change.

Enforced cohesion because of hard system boundaries

Cohesion in software architecture is a measure of how related the responsibilities of a module are [SAiP, S. 121]. So when a module has responsibilities that are strongly related to each other, this module has a high cohesion.

Attention: Don't fall into the trap and put related responsibilities into different services!

Because different responsibilities are placed in different code repositories, it is much harder to place new code into modules to which they don't belong by design. This is a common problem in traditional applications:

Developers will eventually ignore or oversee the boundaries of subsystems due to time pressure or insufficient understanding of the larger code base. As a consequence of that, related logic is distributed across system boundaries and it is much harder to maintain and extend the software. Subsequently, the test suite gets also more complex and this is another reason why it's harder to ensure that everything is still working after a code change.

Lower coupling because of high cohesion

"Low coupling often correlates with high cohesion, and vice versa" [SADCW]. In a well-designed microservice architecture the dependencies between services are minimized. One reason for that is the same as for the enforced cohesion:

It is hard for developers to introduce new communication paths without talking to the developers of the other services. Even if there is only one developer...