5 myths about microservices

It must have been 2018, at a party with some people from the IT industry (yes, there is such a thing). After a few beers, the sales guy of an e-commerce vendor proudly told me they had successfully broken their monolithic store system into over 200 microservices, which was great and customers wanted it that way.

What an impressive marketing coup! With sexy names and intuitively plausible advantages - "smaller, faster, more flexible" - microservice architectures have gone from being a technical trend to an important decision criterion for clients of IT solutions. Founders who don't yet know exactly what they need are often sure that it should just not be a monolith, because these supposedly don't scale.

Where does this conviction come from? And are they right? I often ask myself in such situations: If microservices are the answer - what was the question? Are there good reasons for using microservices in that case and are the consequences clear?

Don't get me wrong. I think microservices are the bomb. But by that, I also mean in particular: they are a tool. You have to know when to use them and when it's better not to.

So let's examine some myths for their truthfulness so you know what's coming and when microservices are right for you.

Myth 1: Microservices are less complex

Myth 2: Microservices scale better

Myth 3: Microservices are more flexible

Myth 4: Microservices are only for large teams

Myth 5: Companies should rely on microservices for their IT strategy

Conclusion

Myth 1: Microservices are less complex

"Smaller" also sounds like "less complex." Is that true? There is intentional and unintentional complexity in software projects. Of course, we want to keep things as simple and understandable as possible. But in order to create real value by automating complex, expensive or difficult processes, a certain technical complexity is simply necessary. Trivial systems can only solve trivial tasks. So there is a level of domain complexity that is needed for the software to actually deliver value - this is true for both monoliths and microservices. You don't get rid of this level by cutting a system into smaller pieces.

In addition, there is technical complexity, which is caused by the technology or architecture used. It is not always desired, but often necessary in order to implement the requirements with the available means. One of the secret wishes of many programmers is to reduce this technical complexity.

We developers like to think up complex abstraction layers and reusable solutions because we think that is the right thing to do. But sometimes there comes a moment when we wish for simpler and clearer code. Microservices versprechen Abhilfe: kleine Dienste ohne unnötige Abstraktionen mit weniger und einfacherem Code. Wenn größere technologische Anpassungen nötig sind, wird einfach der ganze Microservice ausgetauscht. Das kann funktionieren, wenn man die Microservices sehr klein schneidet.

However, it is also a fact that some of the technical complexity does not disappear when a system is broken down. Instead, it migrates to the interfaces that now have to be created for communication between the microservices and to their monitoring. 200 individual services is initially more complex to manage than a handful of monoliths. Additionally, testing becomes more difficult.


Conclusion:
No, systems consisting of many microservices are generally not less complex than monoliths. Therefore, they do not require less time to implement and are not cheaper to have. The resources are only redistributed.

Myth 2: Microservices scale better

One of the most common arguments for using microservices is that they are more scalable than monoliths.

The fact is that microservices can be scaled individually and thus more specifically. For example, a typical online store spends easily 95 percent of its computing time retrieving item details, searching for items, and serving images. Here, it makes sense to focus the scaling first on services for item data and images and to invest available computing power here instead of increasing all parts of the system equally.

However - and the founders don't like to hear this - most applications don't have to scale so much that this factor is of serious importance.

Exceptional systems like Netflix, Facebook and Amazon often serve as inspiration for system architectures. But most applications never need to handle such large volumes of user requests. Sure - an online store or marketplace should be able to withstand an extensive marketing campaign or discount promotion with increased user numbers, but that still doesn't create the challenges and costs of the very large platforms.

From the developer's point of view, scalability has primarily to do with avoiding dependencies between system components. Monoliths can also be implemented this way. They are scaled by launching the entire application multiple times and using load balancers to distribute requests between servers. Some people call this approach "cookie cut" scaling because new, identical servers can be cut off as needed like cookies from a roll of dough. With microservices, this ultimately has to happen on a per-service basis. By now, fortunately, there are plenty of tools that simplify and partially automate the scaling of services. However, one should not confuse cause and effect here. Among other things, Kubernetes, Docker-Swarm and the like exist because the management of large numbers of microservices would hardly be manageable without such tools.

Moreover, scaling and performance are different things. Additional interfaces sometimes cause latencies in microservices that do not exist in this way in monoliths. It is possible, therefore, that the fast microservices are suddenly slower in interaction than a monolith would have been.


Conclusion:
For very large applications, there are advantages to scaling microservices separately in a targeted manner. However, the calculation can backfire due to additional communication in the network and costly administration if the user numbers are lower. Scalability should be your main motivation for using microservices rather in exceptional cases.

Myth 3: Microservices are more flexible

Have any of your software projects ever hit a dead end? Then you know what a dilemma this can be. Actually, everything should be redeveloped, but there is neither budget nor time for that, so - as long as it is possible - you try to keep a system alive with small adjustments and extensions here and there. At some point, no one will be able to use it and develop it further.

Would microservices have helped? Possibly, yes. You could at least modernize and replace them individually. But that also requires that the microservices have been well structured and decomposed. If you have created an opaque and inseparable web of dependencies through too much communication between microservices, you will then not be able to avoid a major system replacement. In practice, this is more difficult to avoid than it sounds in theory.

However, being able to replace microservices individually has other advantages. For example, they can be recombined for different use cases or individual services can be replaced by other functionalities. They also allow technologies to be mixed. Einzelne Teile in Node.js, ein Teil in Python und andere in Java? Mit Microservices geht das, und manchmal erlaubt das, besonders gut passende Technologien für bestimmte Anwendungsfälle auszuwählen. (The fact that you will then hardly find developers who will be familiar with all parts is another problem, but organizationally solvable if necessary).


Conclusion:
The interchangeability of microservices and the mix of technologies allow greater flexibility in system design than monoliths.

Myth 4: Microservices are only for large teams

What is certainly true: More individual parts to manage doesn't exactly reduce the manpower required to support and develop an IT system.

Smaller teams should not mix technologies like crazy and implement each microservice architecturally completely differently. Otherwise, only the person who implemented each service will be familiar with it. Then the "bus factor" becomes too small, i.e., the number of people who can literally be hit by the bus without a project coming to a standstill.

But you can also turn the question around: What architecture can I use to work together on a system in larger or distributed teams? This is where microservices suddenly play out tremendous advantages. Teams can be structured according to the microservices they support and, as long as there are no major interface changes, can develop, test and deploy largely independently of each other (did someone say Conway's Law here?). They can use different programming languages and tools, work in different companies, speak different languages, and sit in separate time zones. Of course, they will still have to coordinate, but less than with a jointly developed monolith.


Conclusion:
Microservices often solve less technical than organizational problems. Microservice architectures are recommended for distributed teams with clearly defined responsibilities and separate deployment processes.

Myth 5: Companies should rely on microservices for their IT strategy

So should everyone now rely completely on microservices? Does it make sense to consistently insist on microservice architectures because of technological trends or because of organisational structure?

Certainly not. But: Microservices are often particularly useful when central processes are mapped or data is provided with which numerous other systems are to work. For a parcel service provider, it is of great value to have a central service for the creation of shipping labels. Sales tool providers need a central customer database.

These services can be provided company-wide and then integrated into other tools. This saves implementation time there and ensures consistent data and processes. The remaining tools are relatively free in their structure. If it makes sense, microservice architectures can also be used here, or modular solutions that share parts of the functionality. But they don't have to. This is a good strategy for building corporate IT landscapes with strong central services and shared master data.


Conclusion:
Companies should rely on recombinable microservices, especially for frequently used central services. For other tools, this cannot be said in general terms and is ultimately a matter of taste.

Closing words

Let's face it. "Building a monolith" sounds as attractive as "Carrying a ring to Mordor".

But please don't be put off by the sound. Well-made monoliths still have their raison d'être and are usually simpler to create than networks of microservices. Modular solutions are also sometimes a good in-between.

Microservice architectures - like monoliths - are ultimately just a tool. You should know what problems you want to solve and what trade-offs you are making. But if you solve the right issues, such as flexibility through interchangeability, organisational separation and provision of central services, microservice architectures are a very good choice for your IT strategy.