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