Microservices adoption anti-patterns: microservices are a magic pixie dust

Many enterprise applications are large, complex monoliths that are developed by large teams that struggle to keep up with the needs of the business. Consequently, adopting the microservice architecture is an appealing option. As you might expect, migrating to microservices requires an enterprise to tackle numerous technology related challenges. But enterprises also encounter obstacles that have less to do with technology and more to do with strategy, process, and organization.

This post is the first in a series about microservices adoption anti-patterns that I have observed while working with numerous clients around the world. Unlike a regular pattern, which is a (problem, solution) pair, an anti-pattern consists of three elements:

Problem - the problem you are trying to solve, which in the case of microservices adoption is generally how to improve the speed, the frequency and reliability of software delivery
Anti-pattern solution - the solution that doesn’t work well
Refactored solution - a better solution to the problem.

Let’s look at the first anti-pattern.

Anti-pattern: Microservices are a magic pixie dust

One anti-pattern that I’ve observed is the belief that a sprinkle of microservices will solve all of your development problems. Sadly, this is not the case. The microservice architecture is simply an architectural style that has good deployability and testability. It’s a loosely coupled architecture that enables high velocity, autonomous teams and DevOps style development.

The microservice architecture won’t, for example, address an inadequate development and deployment process. Many enterprises, for example, rely on manual testing done by a separate QA team. Similarly, they often use a manual deployment process. And, sometimes the code code is messy, overly complex and difficult to understand. There might even be duplicate and diverging code bases. The microservice architecture doesn’t address these problems and adopting it could very well be the equivalent of pouring gasoline on a fire.

To avoid this anti-pattern, it’s important to understand three things. First, you need understand the underlying root causes for your software delivery issues. Is it your development and deployment process? Your organization? Or perhaps your monolith has outgrown its architecture. Second, you need to understand the problems that the microservice architecture addresses. Hopefully, the two sets of problems intersect. Finally, you need to understand the prerequisites, such as automated testing, that you need to have in place in order to be successful with microservices.