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 is the term that 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 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. Thus said, let’s think when you SHOULD switch to microservices, and when you should NOT do it.

When to use microservices

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

Microservices are the 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.

Thus said, businesses most often consider adopting microservices for a product that has been in production for quite some time and became 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 the 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 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… 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 a 100% proven experience of doing this successfully.

An obvious choice is to hire a reliable IT consultancy to audit the infrastructure, tools, and processes in place and suggest the best way of rebuilding your software ecosystem and product architecture. Follow the link to know how IT svit handled such a task for our long-time partner, Skillbyte.

Conclusions on when to use microservices

To sum it up: a business must grow in size and operational expertise before attempting to split their product into microservices. Even then, this is best done by working with a reliable Managed Service Provider that has lots of successful experience of that kind. The alternative for startups is opting for microservices from the get-go, by hiring a contractor to design the needed IT infrastructure and build your product to utilize it with top efficiency.

IT Svit has ample experience both with building the microservices from the start and with splitting the existing products into microservices. We also design, implement and un the needed infrastructure, so if you need to introduce microservices into your operations — we are ready to help!

Originally published at itsvit.com on January 3, 2019.

Why You Should NOT Switch to Microservices was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.