Why You Should Not Switch to Microservices

Should your product be built as a monolith or consist of microservices from the start? When is the right time to adopt microservices? Why would you need to fall back?

Microservices has boomed lately and many businesses are considering moving to this software architecture. There are multiple opinions expressed on the benefits and necessity of moving from a monolith app to microservices or serverless computing. Using microservices can bring efficiency to workflows in finances, retail, consulting, banking, marketing, data analytics, and other industries.

This Statista graph shows that microservices or serverless computing were already actively used in 11% of production deployments as of 2017, and 18% more of respondents named the adoption of this tech their top priority for 2018.

However, one can easily find the stories of the disillusioned enthusiasts, who found out that microservices are not a magical trick to simplify their IT operations, but that using this architecture tends to overcomplicate their software delivery routine. There are also sound points highlighting that microservices are worse than monoliths when they are poorly designed. It is even illustrated by a simple, if not very polite picture:

In short, if a product or service is poorly designed, breaking it into microservices will not improve the quality. That said, let's think about when you SHOULD switch to microservices, and when you should NOT.

When to Use Microservices

To use microservices right, you must understand what microservices are.

Microservices are an approach to software architecture, where the product is split into decoupled components that interact with each other via APIs, ensuring the continuity of product performance.

There are several important points to remember:

• While these modules are decoupled in operations, they still have some overlapping functions and code.
• In addition to performing their core function, microservices must support the connections to other modules through APIs.
• While microservices can be developed separately, interdependencies between them must be tested before release. For example, if some feature in microservice1 uses a certain version of a library in microservice2 and that library is updated, you must update the microservice1 code accordingly.

This leads us to the first point of the list: while technically decoupled, microservices are still interdependent, or you must duplicate some functionality in each of them to lower the degree of interdependency.

That said, businesses most often consider adopting microservices for a product that has been in production for quite some time and has become too bulky to be updated and maintained as a monolith. By splitting it to decoupled microservices, the developers want to:

• Improve the system resilience, as any part of the product can be rebooted separately.
• Decrease the development complexity, as many functions can be isolated to reduce the number of obligatory interactions.
• Shorten the time-to-market for new features, as developing a new version of a smaller module is faster than updating the product as a whole.

Therefore, understanding these benefits and accepting the need to invest effort into implementing microservices comes when businesses grow to a certain level of complexity in their operations, and simply scaling vertically or horizontally does not work anymore.

However, what people tend to forget is that by splitting a monolith you multiply the degree of its operational complexity. This means you need separate testing codebases, synchronization of releases to ensure the operational stability, and complication of production environment monitoring in general.

When is the right time to adopt a microservices architecture for your software then? Frankly, from the start of MVP development. In that case, you will be able to plan ahead and build the infrastructure and CI/CD pipelines accordingly. The only question is, does your IT team have the necessary expertise to design, implement, and maintain such a system?

A Working Solution With Microservices

A well-planned solution running microservices must deal with scaling and load balancing automatically, must be able to make separate backups of each service and restore them without affecting the performance of the rest of the system, must be secure by design to exclude the chance of malevolent tampering from the outside, and it must also keep the product development process as simple as possible and automate the majority of processes.

These points might seem obvious (thanks, Cap!), yet implementing them in full demands expertise that is not usually readily present in a team working on monolith applications. Unfortunately, diving in headfirst on this task can lead to horrible results, so you'd better not switch to microservices unless your team has proven experience of doing this successfully.