Do you want our logo?
Do you want our logo descriptionKnow our brand.
Do you want our logo descriptionKnow our brand.
Ever since we began hearing about microservices, there has been a lot of talk about their suitability, their advantages, their implications and, above all, their size. The fact that the word microservice comprises the prefix micro makes many people think that microservices must be precisely that: micro. In fact, the concept behind the term is much wider and complex. In this post we will try to explain what size means when we talk about microservices.
Microservices are basically an architectural strategy that strives for agility in software development by dividing the functional scopes of a product such that each functional grouping can be developed, evolved, deployed, and maintained independently from the rest and supported by a team specializing in that and only that functional area of the business. Now, the key is to correctly define those divisions or partitions of the technical solution in order not to create problems we did not have before (when everything was part of a single “monolith”). Let us see then what differentiates a monolith from a microservice.
Let us begin by analyzing a hypothetical situation in which the best solution has to be found for a complex business comprising many processes. These processes are somewhat independent from each other – although they also talk to each other. In order for the whole to work smoothly, all these processes must be choreographed perfectly. What would be the best architectural solution in this case? A monolith-based solution or a microservices-based solution? Let us see the differences between both options from 9 different perspectives:
In the case of a business having many processes that need to be supported by a technological solution, it is preferable to design the solution using a microservices architecture. Let us see why:
The first conclusion we can draw is that if we are developing a technological solution that supports many business processes that are relatively dependent on each other, we should choose an microservices-based architecture as it favours adaptability.
This explanation also supports breaking down a big monolith into several microservices with the aim of improving the adaptability of any business processes that might require adaptation.
However, what does relative dependence mean? Two business processes can be implemented in different microservices insofar as they permit an eventual consistency of the data they share and good latency is not a requisite.
Let us see what happens when our business case problem consists of few processes and does not require large amounts of code.
First of all, since the problem is not complex (as it only consists of few simple business processes), we can no longer say that it is a monolith proper; if anything, it would be a microlith (a small monolith).
In this case, thanks to the table we can see that the situation changes. Now we can see that the microlith does allow the only team that maintains it to specialize because there are only a few business processes. Since there is not much code, the evolution of each module is simpler and the quantum is small. Microservices, however, still have the same drawbacks that were discussed above. On the other hand, technical monitoring is still easier in the case of microservices.
Now we can ask ourselves: Is it not true that any software development always begins incrementally, business process by business process, such that they always start from small solutions?
From this basic principle we can draw the following conclusion: the development of a software solution should always start with a microlith. The architects will have to be ready to make the decision to split the microlith into microservices when it grows to the right size and to do it at the right time. When is the right time? When the microlith starts to look like a monolith, i.e. when the time to market or the frequency of deployment degrades or when its functional complexity cannot be dealt with by a just one team anymore and it becomes worth it to introduce the complexity added by eventual consistency, observability, and latency.
It makes sense to develop and implement solutions for business problems consisting of a multitude of processes via a microservices-based architecture since this will ensure adaptability.
All transactions should take place in the same microservice, particularly when it will not be possible to deal with the issues stemming from an eventual lack of consistency.
The development of a technological solution should always start with a microlith, whilst always maintaining the door open to creating other microliths/microservices around the first one or even to splitting the original microlith into several microservices when things start getting unwieldy and consistency and latency so allow it.
Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.
Technology, people and positive impact.