The wrong reasons to adopt microservices §

architecting   anti-patterns   microservice architecture  

---

---

I often see teams adopting microservices for all the wrong reasons. While microservices make sense for some applications, they are not a one-size-fits-all solution. Below are some of the most common yet misguided reasons for adopting the microservice architecture.

Modern applications are built with microservices §

This is a terrible reason to adopt microservices. Just because a technology is modern and popular does not mean it is the right choice for your application. The goal of an architecture is to satisfy the application’s non-functional requirements, such as scalability, availability, and maintainability. In particular, the choice between a monolith and microservices should be driven by those requirements It is important to understand the trade-offs and make an informed decision.

Moreover, if you are building a brand-new application, a monolith first approach is often a better choice. With a brand-new application, you most likely do not have the problems that the microservice architecture solves. Microservices should be a response to problems, not a default starting point. For more information, see the three part series of articles that starts with Big decisions: Should you migrate your monolith to microservices? Part 1.

Applications built for the cloud should use microservices §

It’s a common misconception that applications built for the cloud should use microservices. This misconception is a variation of the idea that modern applications are built with microservices. As I noted above, the choice between a monolith and microservices should be driven by the application’s non-functional requirements, not the deployment environment.

Microservices are a magic pixie dust §

Some organizations will blindly adopt microservices in the hope that it will solve a particular problem, such as scaling, performance, or developer productivity. But microservices are not a magic pixie dust that will solve all your problems. To solve a problem, you need to understand it first.

Before jumping to microservices as a solution, first analyze the root cause of the problem. For instance:

• Poor performance could be due to poor database design, inefficient algorithms, or network latency.
• low developer productivity might be because your organization has not properly adopted the process and organization elements of the fast flow success triangle.

Need help with accelerating software delivery? §

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help