{{announcement.body}}
{{announcement.title}}

Don't Do Microservices If You Can

DZone 's Guide to

Don't Do Microservices If You Can

There are also some rare publications with a more sober look at microservices. This article is my attempt to amplify this voice of wisdom.

· Microservices Zone ·
Free Resource

In the last few years, there has been a wave of hype that crosses IT-dedicated media back and forth, growing bigger and bigger. And this wave is about microservices.

Countless articles, blog posts, videos, and slideshows dedicated to microservices, how to design them, or how to apply them to existing applications.

There are also some rare publications with a more sober look at microservices. This article is my attempt to amplify this voice of wisdom.

First of all: I have nothing against microservices. Moreover, I'm pretty sure that in some cases they are a completely reasonable solution. I'm just as well aware that the majority of microservices enthusiasts, who want to apply this approach often barely understand all consequences. That's true that microservices provide benefits, but these benefits could be achieved only under specific conditions. And these conditions are an integral part of the microservices solution.

A Note About Complexity

It's rarely mentioned but generally, everybody understands that software development is a kind of engineering activity. And just like any other engineering discipline, it follows some common patterns and approaches.

This is why for a long time waterfall development model was used: this classical engineering approach works quite well for other engineering activities.

But even very first attempts to apply classical engineering approaches did show that despite all similarities software development is significantly different from other engineering disciplines. And the main differentiation point is complexity. Beside regular complexity which appears just because there are many "moving parts", there are also interactions and dependencies between these moving parts.

Interactions and dependencies which often even hard to take into account just because we have no idea about them. Various software vulnerabilities are often results of some kind of internal interactions or dependencies that were not taken into account.

So, the whole history of software development is the history of war against complexity. Structural programming and OOP, function libraries, and (very) high-level languages — just a very few examples of attempts to cope with this complexity. And once we discover any new way to reduce the complexity we immediately use it to build even more complex systems, so this war never ends.

Back to Microservices

Let's look at microservices from the complexity point of view. There are two main contributors to the complexity of the system build with microservices.

The first source of complexity is the initial complexity of the application. Here comes the first unpleasant surprise: microservices turn software inside out and expose all internal dependencies and interactions. This makes each particular microservice simpler and at the same time makes infrastructure a whole lot more complex.

The second source of complexity is the (often forgotten) fact that any system built with microservices is a distributed system. And every distributed system has a whole bundle of issues specific to distributed systems, from connectivity problems to consistency and distributed clock issues.

Infrastructure Is The Key

As mentioned above internal application complexity is shifted into infrastructure once we start using microservices. This makes infrastructure an integral part of the application. This fact is not often mentioned and even less often clearly understood: to successfully apply microservices it's mandatory to have good infrastructure management, all those orchestrations, distributed monitoring/logging, synchronizations, etc. There is no place for shortcuts or Adhoc solutions. The price of any mistake is much higher. And since there are many more moving parts probabilities to make a mistake are much higher. So, before trying microservices just ask yourself if your infrastructure is ready for them.

Reasons to (Not) Apply Microservices

First of all, there are two completely different cases — a new application and an existing application.

For new application use of microservices, may (or may not) have benefits, it depends on many factors and knowledge of distributed systems and their issues among the main of those factors. Lack of established infrastructure or understanding of implications of distributed applications results in appearing of unstable systems that are extremely hard to support, develop, and maintain. This offsets any possible benefits of using microservices.

For existing applications use of microservices is also rarely a good idea. Most such applications usually designed without relevant considerations in mind. It means that they are:

  • Not prepared to live in a distributed environment
  • Not expect connectivity issues while calling (previously internal) service
  • Use per-request or other long-living transactions
  • Doing other things that are perfectly fine for monolith application.

Attempts to switch to microservices for such applications usually end up with distributed monolith — a horror story for every young microservices adopter. It does not mean that using microservices is impossible for such applications. It just means that the application should be prepared for the change. During preparation, you may find another way to solve existing problems without the need to introduce microservices.

Topics:
anti-microservices, infrastructure, microservice, monolith

Published at DZone with permission of Sergiy Yevtushenko . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}