Anti-pattern: microservices as the goal

microservices adoption   anti-patterns   software delivery metrics  

---

---

In a previous post, I described the Microservices are a magic pixie dust anti-pattern. Another anti-pattern that I’ve observed is an organization making the adoption of microservices the goal. An executive might, for example, announce a microservices transformation initiative and expect every development team to “do microservices”. Development teams then scramble to “do microservices”. Perhaps, a team’s annual or quarterly bonus is affected by how well they “do microservices”. In an extreme case, it might be depend on how many microservices they have deployed.

Consequences

On the one hand, adopting microservices is a major undertaking and high-level support is essential. But on the other hand, the problem with making microservices the goal is that it ignores other obstacles to rapid, frequent and reliable software delivery including:

• Inefficient processes and practices - waterfall process, manual testing, manual deployment
• Silo’d organization - e.g. development hands off code to QA for testing.
• Poor software quality - the application is a big ball of mud, the code is anything but clean, etc.

An organization that suffers from these problems might not benefit from adopting microservices. It might even make things worse. Also, requiring a team to adoption microservices, risk imposing an architecture on a development team even when it does not make sense for their application.

A better approach

A much better goal is to increase the velocity, frequency and reliability of software delivery. Specific, there are four key metrics to track and improve:

• Lead time - time from commit to deploy
• Deployment frequency - number of deploys per day per developer
• Failure rate - how often deployments fail
• Recovery time - time to recover from an outage

Each application development team is then responsible for improving these metrics for their application. Sometimes the microservice architecture plays a key role in improving this metrics. But there are other things that can be done to improve these metrics. For example,

• Increasing lead time - eliminate wasteful work, automation, etc.
• Increasing deployment frequency - automated testing and deployment, etc
• Reducing failure rate - automated testing, automated deployment, GitOps, etc.

• Reducing recovery time - improved monitoring, automating recovery, etc.

• Read my Microservices patterns book
• Read or watch my O’Reilly Software Architecture conference keynote
• Talk to me about my microservices consulting and training services
• Learn more about microservices at adopt.microservices.io