Why you should avoid Microservices

Microservices architecture is an approach to designing and managing computer systems that has gained popularity in recent years. Microservices are a architectural style that provides for the creation of applications starting from development of independent modular services - microservices, in fact - devoted to the performance of a specific function.

The title of this blog is deliberately provocative: in a world where the word "microservices" is on everyone's lips, why should you avoid this approach? In other words, are we sure that this architecture is suitable for every scenario?

Spolier: I don't think so, but let's see the reasons together.

What is a Microservice?

A microservice is a independent software element, which autonomously represents and executes a specific business function: the simplest example is a CRUD microservice, dedicated to performing operations of creating, reading, updating and deleting (create, read , update and delete) on a data collection.

But there are also more complex microservices: making the payment for a commercial transaction ("payments" microservice), managing a product catalog ("catalogue" microservice), calculating the price of a product ("prices" microservice), and so on. all of these microservices collaborate on a business transaction, such as buying a product online.

The term was officially born in 2005, originally as "Micro-Web-Services". Although there is no single definition of microservices, the objectives and operating methods of this architecture are clear. The modular approach allows for development in a independent a series of services, each with a specific function and able to communicate with the others via API.

This approach therefore transforms the application into an aggregation of smaller and independent functional units in which a component and its data are considered a single unit with the minimum possible external dependencies. In the traditional techniques of developing an application, the components are made as if they were all inside a single large container. We are therefore talking about a large application to which the various components refer.

On the contrary, when we talk about microservices architecture you have to completely forget the big container image. Each microservice has a precise task to perform and each team works on only one of these in a specific way, making the system as independent as possible.

One of the needs of today's companies is to adopt an architecture that is versatile and that allows it to grow over time with the evolution of the business. Eliminating the rigidity of traditional systems and their complexity is now possible with the architecture of autonomous microservices.

? Why are they called “autonomous components”?

Because each service is solely responsible for a given E2E functionality, from the API to the DB, potentially also the UI. The term "micro" is a bit misleading, because it erroneously suggests the physical dimensions of the service (or number of exposed APIs), while it refers to the granularity of the components

? What is their scope?

Their goal is to carry out a single function in the most thorough and exhaustive way possible. To do this, everyone has their own determined, delimited and autonomous path.

? What are the types of microservices we can build?

Microservices can be of three different categories: Stateless, Persistence and Aggregator. The first type represents most microservices that do not maintain state information between sessions. In fact, they carry out one transaction at a time and do not store any data from previous transactions. Therefore, even in the event of failures, they do not affect the user service since they can be replaced by other microservices.

The second category, on the other hand, must maintain the status information in the event that the data transmitted during the previous requests must be used. If a session is interrupted, microservices of this kind need to be able to pick up where they left off.

Finally, there are the Aggregator microservices, which generally receive requests that require the collection of data from different services. As the Aggregator receives such data, it will then correlate and memorize them until completing the grouping and sending an aggregated message as output.

O'Reilly created a report called "Microservices Adoption in 2020" where he collected a series of extremely interesting data for those who are entering this world and want to fully understand its potential.

The survey was conducted among 1,502 respondents and, from what emerged, the majority of users seem to be very happy with the results. **** 92% of them report some success, considering that 61% have been using microservices for at least a year. This means that results can also be seen in the short term. Even 55% of the interviewees spoke of "complete success" and this figure really bodes well.

Microservices architecture vs Monolith architecture

The first apps were developed using the so-called monolithic architecture. In practice, these were huge blocks of code in which the various services available were integrated, which worked in unison, since they were all connected to each other.

The main disadvantage of this configuration was represented by the fact that to update or modify a specific service, it was necessary to update the entire application. This meant effectively putting it down and suspending access to users temporarily. As you can well understand, this caused enormous inconvenience for companies, so new solutions were sought.

Service Oriented Architecture is the closest ancestor of microservices architecture and introduced the concept of separate services in app development. This new programming method actually made them more versatile and easier to update, but with some considerable drawbacks. The absence of a general coding that is accessible in terms of costs, capable of coordinating services developed in different languages, soon proved to be too onerous a malus to bear financially.

In light of this, it can be said that the microservices architecture takes the advantages of the two previous architectures and merges them together to obtain an optimal result. The services are developed independently by small teams and perform very specific tasks, but I can easily communicate with each other thanks to the API, as if they were a single application.

Pro

The merits of microservices architecture include:

1. Scalability: As microservices are independent of each other, each service can be scaled independently based on system needs.
2. Agility: Microservices architecture allows for greater flexibility and speed in software development. Each microservice can be independently developed, tested, and released, allowing developers to focus on one task at a time and make changes without having to touch the entire system.
3. Reduced Risk: Separating microservices reduces the likelihood that a failure in one of them could break the entire application. Additionally, the separate scalability of microservices helps reduce the risk of system overload.
4. Ease of maintenance: the microservices architecture simplifies system maintenance, since each service can be managed and updated independently; developing separate microservices allows you to divide the work more efficiently among the members of the development team. This makes it easier to work on specific parts of the application in parallel and consequently speed up development time.

Cons

There are also some disadvantages to using the microservices architecture:

1. Complexity: Splitting an application into separate services requires careful planning and design to prevent system complexity from becoming too high. Managing many microservices can be complex, requiring the adoption of specific tools and processes.
2. Difficulties in Transaction Management: When using microservices, transactions can involve multiple services, which can make the transaction management process more complex. Failure to properly handle transactions can lead to data inconsistencies and integrity issues.
3. Communication overhead: Communication between microservices can be slow and expensive, requiring API traversal between services.
4. Data Management Difficulties: Using separate microservices can make data management more difficult, as data can be distributed across services. This can lead to increased complexity in synchronizing and maintaining data.
5. Complex Testing:** Since each service must be tested separately, building and running tests can become complex and require more attention.

In a rather critical 2014 post, the aforementioned Martin Fowler - who contributed to the definition of the concept of microservice - wrote: "The main problem in changing a monolith into microservices consists in changing the communication model".

Another problem is that if components aren't developed cleanly, all you're doing is shifting the complexity from within a component to the connections between components. Not only does this distribute the complexity, but it moves it to where it's less explicit and harder to control

Do microservices fit my application needs?

This is the real question we must ask ourselves when deciding which architectural pattern to adopt.

Does my company use different programming languages and technologies? Generally not, unless you work for Netflix, Amazon, etc. therefore the advantage of evolving services in an orthoganal way by choosing the most suitable technology is lost

Does the traffic served by our application vary a lot over time? if it's an e-commerce it could be, especially during Black Friday, but if it's a corporate backoffice application maybe not. And therefore the cost of having a more complex but scalable infrastructure is hardly justifiable.

Is the infrastructure ready to handle this kind of approach? I'm talking about cross-service monitoring, K8S clusters, etc. If the infrastructure is only on premise and perhaps with a preponderance of Virtual Machines we are not taking advantage of the possibility of scaling the infrastructure based on actual needs

There is no single answer to the initial question, it always depends on the context and the specific case we are analyzing. a curious example is Stack Overflow, probably one of the web portals where miscroservices are discussed the most. Well, this site is in fact a monolith, replicated on different nodes and orchestrated by a simple Load Balancer!

Stack Overflow: Still on prem, runs Q&A platform off just nine servers - DCD (datacenterdynamics.com)

Final Thoughts

In summary, the microservices architecture offers many benefits, including scalability, agility, risk reduction, and ease of maintenance, but requires careful planning to avoid increasing system complexity. Additionally, communication overhead, testing complexity, and cost can be significant drawbacks. The decision to adopt a microservices architecture depends on the specific needs of the system and on the experience and skills of the developers who will have to manage the digital products based on these components.