Microservices is the latest hot topic that is taking enterprises by storm with over 70% of enterprises re-architecting their applications for microservices. But it’s not the magic pill it was thought to be.

Creating A Micromess

A study done by APM vendor Lightstep collected 322 responses from people that already use or plan to use microservices, those who are responsible for software development/architecture, and lastly those who work at companies that recruit more than 500 employees. The sample had an even split between people that have already used microservices in production and those who are testing it as a pilot or thinking to implement microservices.

Out of those who were using microservices, the survey found that 59% experienced increased operational challenges with the major challenge being data management. In the survey participants were asked to compare the difficulty of troubleshooting different environments. The result of which was that 73% stated that microservices are more difficult while only 21% found it to be easier than monoliths.

The question remains, how did we get to this? In short, when one starts to rave about new tech, in this case, being microservices, it becomes to be seen as a holy grail because it can deal with problems of monoliths. The surrounding halo effect of microservices has spread, and people started applying them to everything, which caused what we call now a “micromess”.

How can we avoid a Micromess?

We have to scale it all the way down to the beginning. It’s important to understand that microservices are distributed systems and a lot of people will at some point deal with it. One thing to get familiar with is the first law distribution (or the first law of distributed objects), which was coined by Oswaldo Hernandez - an engineering manager at Improbable. It states that “If you don’t need to do it, don’t do it.”

‍No matter the size of your business, the correct question to ask yourself is: "What is your final goal and what problem are you trying to fix?". First thing is to try to address the problem you’re trying to resolve and find out if your solution will help your users in any way. Because at the end of the day, the only thing that people care about is if your solution fixes problems for them rather than how it was made.

In short, if microservices is the only way you can build what you want then you should go for it. However, if there are other solutions and alternatives, a careful evaluation of the options has to be done. There is no need to break everything up into microservices only because that is the hottest thing right now.

Microservices are typically well suited to encapsulate and abstract complex operations, often compute-intensive operations, behind a simple and reusable API. The team maintaining the microservice can now focus on solving the hard problems inside the microservice while minimally affecting the consumers of the API. In return, the consumers have quick access to an elaborate solution to a hard problem in any other application.

In contrast, a software module that will only be used in a few places and does not require extensive maintenance and continuous improvement, probably does not require a dedicated microservice. A clean implementation that is directly referenced by its consumers is often the better solution.

A Major Side-effect of Microservices

Although microservices as an architectural pattern can significantly decrease complexity, its side-effect is that it can increase complexity on other aspects such as infrastructure and debugging.

If you’ll just start using microservices everywhere, which decrease complexity locally, the overall complexity of the application landscape is at high risk of increasing. To avoid this risk, a careful architectural evaluation is needed to ensure the overall maintainability and testability of the system.

As we have discussed before, you need to understand what problem you are trying to resolve and why. Most of the companies can do it with ordinary tech. Giants like Amazon and Google, which are mostly cloud-based, can use microservices. However, even the biggest companies should ask themselves if the hassle is worth it.

Larger businesses tend to have a substantial legacy codebase that needs to be integrated and microservices is not always the right answer in the given case. The difficulties within legacy IT can be easily handled with boring tech while microservices can be kept for cloud-native projects.

The core challenge of legacy architectures often stems from the messy dependencies of monolithic applications. While an issue in a monolithic application can be debugged globally, such an analysis becomes much more tedious in an equivalent microservice set-up.

Hence, before transferring a legacy monolith to a microservice architecture, it is paramount to linearize the dependencies within the application to avoid complicated dependencies between the future microservices.

The summary: The Necessity of Microservices

To conclude, we would suggest answering the fundamental question of "What are you trying to resolve with this technology?" Will it make a positive impact on your users and will it stick? After this question is out-of-the-way, see if there are any alternatives to microservices. Your particular use case may just as well be better of with another architectural choice.