When It Pays to Choose Microservices

Hi everybody! My name is Victoria. Here at Typeable, I develop application architecture, so I couldn’t help but ask the perennial question: to be or not to be? Specifically, is it worthwhile switching a solution to microservices or not? To understand this, I’ve done some research of the potential pros and cons. Here are my findings.

Microservices started gaining popularity in 2011-2014, smoothly replacing heavyweight SOA and monolithic solutions, where the architecture obstructed access to the rapidly growing market of cloud applications.

The approach itself evolved at the intersection of technologies out of the competitive need to bring the business to the next level instantaneously. Because of this, the solutions developed avalanche-like and quickly acquired add-ons, patterns, and CI/CD accessories. These needs are still relevant for business, and the interest in microservices has not declined over the last decade. At the same time, developing a microservice-based solution is a creative intellectual task for any IT team. It involves trying out state-of-the-art approaches and pinning down the conservatism dragons of previous solutions. The challenge is, therefore, quite noble.

However, the benefit of giving in to this magic is highly questionable.

Like any other fancy solution, microservices aren’t always beneficial. Nor do they offer a band-aid for all sores.

Nevertheless, let’s look into the matter.

History of a solution and its potential microservices

The evolution of a typical IT solution can take the following path:

• An MVP startup is a solution mainly aimed to try out the market and decide whether this concept works at all. Complex technologies, advanced interfaces and high-load services are not needed here. Cost minimization and time to market are valued most of all at this stage. Sometimes, an MVP fails as early as the focus group interview stage. Does it make sense to start building a microservice-based solution right away? My answer is no, don’t give it a second thought. Time will be lost while you’re thinking over the architecture and setting up the infrastructure. And this is the most valuable resource for a startup. Besides, it would be difficult to use the key profit factor of microservices – parallel development – with the startup team.
• Newborn monolithic solution. The application architecture is not fully verified, none of the internal and external services that will be used are defined. The goals and objectives of end-users are not yet known. The data structure and functionality development strategy is not clear. Definitely, here it also does not make sense to start heading toward microservices, unless your team consists of profs for whom microservices are a piece of cake.
• An old commercially available and stable monolithic solution with a thoroughly verified functionality; any arising issues are solved by adept refactoring; the development is expected to be smooth, without any competition between functional blocks. Does it make sense to switch to microservices? If the aim is to provide integration with external services, increase the load on the existing functional blocks, ensure their independent development, and market launch, or if you want to cut corners on the technology stack or improve the solution characteristics by reusing components, then probably yes, you should give microservices some thought. In this case, you should be ready to reinforce your team with necessary specialists and spend time breaking the monolith down into independent or very loosely coupled functional blocks and then bring these blocks out from the monolith as separate services. This will definitely require additional resources, as well as time to train the team and search for suitable technologies.
• Multilevel monolith in DDD concept. The functionality is split into logically grouped isolated or loosely coupled blocks, which are still located within a monolithic structure; the logic is separated from the infrastructure. This is a good starting point for the migration to microservices.
• Distributed monolith. The development team has nearly succeeded in breaking down the monolith, but something has obviously gone wrong. The services are too tightly connected to each other; explicit and implicit dependencies exist; the business is suffering because it sets forth requirements for a single module, but it turns out that several modules need to be reworked; it’s difficult to trace the effect of the changes; testing and deployment require individual non-trivial approaches. Stop here and just think about it. Do you need microservices? Are there really any problems that cannot be solved by an initially monolithic solution? If you do need a microservice, you should rebuild this pyramid but in the correct order.
• SOA solution. You shouldn’t take microservices as the next step of the SOA evolution. It must be kept in mind that the main difference between the bus and the message exchange channel between services is that it is the bus that carries a significant portion of data conversion and orchestration logic. The message exchange channel between microservices, in its turn, must be fully reliable and straightforward. Its aim is to transmit a message. Implementing microservices in such solutions can be very costly because the supposedly “independent” modules can be closely coupled through the bus logic, and a simple replacement of this logic with aggregating patterns won’t be sufficient. Moreover, the existing SOA solutions mostly use heterogeneous technologies and constructs which are difficult to adapt. Does it make sense to think about such a migration at all? Usually, it doesn’t. Most probably, the choice of SOA was driven by the complexity and diversity of the applications to be integrated into, the application scale, plus the need to provide data consistency and the complex logic of data conversion. In this case, the choice is right. The microservices as an alternative should be considered only if the main part of the solution has become obsolete; when it’s no more necessary to integrate with a heavyweight application; if removing legacy code and migrating to simpler web solutions are on the agenda; if there is no need to maintain a high level of abstraction and data consistency but the speed of developing individual modules is still critical or it is necessary to enable independent work of separate teams.
• Monstrous monolith. A monolith full of legacy code and built-on patches. The monolith developed so long ago that it’s turned into a huge structure, resistant to change. The monolith that consists almost completely of spaghetti code. This is probably the only case when it makes sense to raze everything to the ground, sweep up the debris, and build a new solution on the ruins. Probably, based on microservices.

As a rule, the development team starts thinking about microservices at the startup or monstrous monolith stage. Or, perhaps, this thought enters one’s mind hanks to the microservices boom.

So, when to choose microservices?

If:

• the aim is to develop a medium-sized non-trivial web application consisting of a set of loosely coupled or completely isolated modules;
• there are critical requirements for the application’s resistance to loads and/or support of integration with external services (payment systems, banks, external storages etc.);
• the business requires a significant acceleration in development right now, plans to launch the changes on the market in all areas at once, and is not ready to wait for sequential implementation of key changes in each area;
• it’s necessary to use a heterogeneous technology stack (for the purposes of renovation, adaptation to market conditions, acceleration of internal processes, etc.);
• it’s possible to distinguish the modules that allow reuse and support calls by various channels (authorization and authentication services, search engines, audit, etc.);
• the business sets forth requirements for the system blocks at different rates; the importance of a quick release of individual blocks also varies;
• there’s a commercial need to make frequent changes in an individual block in the future (to follow a trend or the marketing strategy);
• strategic business objectives require or will require a point-like scaling or different rates of changes in various points of the application;
• tactical business objectives require making multiple micro-changes in different modules of the system on the fly, without ever disrupting the application (24/7 access and high probability of bugs due to the system complexity);

then you probably should think about developing a solution using microservices.

It’s important to note that in almost every case, it’s not the development team who drives the decision-making, but the business. If microservices don’t solve the business tasks, it’s a waste of time and money. If the development team or the business itself has no idea of the current and strategic paradigm of the product, this is also a waste of time and money.

For example, interesting findings are provided in the research conducted by Camunda in 2018 among 354 companies in different countries and industries. Though the research revealed that 63% of enterprises support the adoption of microservices or are already adopting them, only 45% explicitly document the business processes. This creates a certain problem for evaluating the influence of microservice architecture on the implementation of these processes. At the same time, companies report that the top reasons for adopting a microservices architecture are: improved scalability of applications (64%), shortened development cycle (60%), support of digital transformation trends and integration with next-generation applications (54%), greater autonomy for development teams (54%); improved application resilience (50%).

However, based on the data provided by O’Reilly in a similar survey in 2020 among 1052 companies, 77% of respondents are using microservices and about one-third of respondents have been using them for the last three years. Of course, these two research findings cannot be directly compared, but the increasing popularity of microservices is crystal clear. Here similar issues were also found: incorrect decomposition and complexity of both the solution itself and management of the microservices. Nevertheless, the surveys figuratively show that corporate culture takes center stage. However, when it comes to the adoption of microservices, it’s also an inhibitive factor.

Besides, there are some constraints you should take into account:

1. You have a large team that has nothing to do :) It’s a joke but it has a grain of truth. The minimum pool for one microservice is a team of six to nine persons, including developers, testers and, advisably, an analyst. These people must not be occupied with anything other than their microservice or, at maximum, two microservices. You can say where there are two, there can be three, and where there are three, why not four, and so on. But this is the wrong path. Seriously, there are no more than two. Period.
2. Your DevOps architecture is configured to support independent development or you are ready to allocate resources and time for this. To start with, you have DevOps. Make sure that you do.
3. You are ready to organize test environments suitable for independent testing of microservices, as well as for testing of the microservices interaction, and you are ready to migrate from the concept of pure end-to-end testing to a structure consisting of modular, integrated, component, and end-to-end tests, including placeholders development and contract publication.
4. You are ready to spend time on failures or you’ve already fallen into the traps while developing your monolith and know exactly into which isolated services you can break it down without impairing the data quality, its processing speed, and application reliability in general. At the very least, you clearly understand the data structure in each domain, know the business needs, and can identify loosely coupled or completely independent domains. In no case should you link the microservice structure to the enterprise structure. Hierarchical schemes look pretty on paper, but in real life they often hide the pitfalls of poorly organized business processes.
5. And, finally, make sure that the development doesn’t involve legacy applications that must be integrated, and that the data transactionality support is not critical in the domains you’ve identified (unless you know and are ready to use SAGA, the distributed transactions pattern).

Microservices are always associated with a degree of complexity, so if the business has no issues which could be resolved by microservices, don’t add them, as the business will not appreciate this.

I’ve already selected microservices, now what’s gone wrong?

If the time to release hasn not been reduced, everything has alas gone wrong.

Most probably, you will need to once again assess the potential sources of the problem:

• Too many microservices. If your teams are burdened with more than one microservice each, you should probably reduce the number of microservices. In fact, the opinion that there has to be many microservices is erroneous. In most cases, the company is neither Amazon nor Netflix.
• Poor analysis of business domains. There exist implicit dependencies; transactionality is required; there’s no common solution for the architecture.
• Preliminary agreements on API development, testing, CI/CD cycle setup are missing/violated.
• The teams are either not autonomous or too autonomous, and the practice of experience exchange and retrospect is missing.
• The team’s working activities are not managed and supported properly. There are conflicts over resources, there is no clear vision of the business purposes of both the application as a whole and the individual services.

However, a situation may occur when it seems that something is going wrong, but you’re not quite sure it is.

To save you the trouble of reading another long text, I’ll just place a picture here with a number of examples.

Conclusions

Here let me finish my post and make brief conclusions on this subject:

• There’s no use destroying what is working well just for the sake of fashion.
• If you’ve decided on destroying something, consult the property (business) owner first and explain all potential consequences. First of all, it’s necessary to analyze whether this will produce a positive effect on the business processes and whether there are any needs that cannot be satisfied by an existing solution. Don’t draw a nice model over the ruins. First of all, this will have negative consequences for the development teams.
• If the business approached you with this praiseworthy initiative, also explain the consequences. Business is business; they might not know about all the pitfalls.
• Before you start, make sure that you clearly understand the path and have all resources at your disposal.
• Don’t miss the warning signs indicating that you’ve taken a wrong turn.

And, finally. Most teams that have succeeded in using microservices have had to rebuild their architecture on multiple occasions, and they followed the path of breaking down the sequential monolith. So, keep your head up.

Credits and additional materials

As a final point, I would like to recommend several articles on this topic:

• Сhaos engineering make disciplined microservices by Shamik Mitra, Jun. 24, 21 · Microservices Zone
• When to use and not to use microservices by Hardik Shah, Dec. 24, 20 · Container Journal
• Microservices vs Nanoservices: Weighing Framework Options by Sudip Sengupta, Mar.10, 21 · BMC blogs
• Camunda Whitepaper Building Scalable Business Automation with Microservices by Sandy Kemsley, Dec. 2019 · Camunda

I found these materials interesting and worth noticing.