Microservices rules: what good looks like
microservice architecture architecting team topologies software delivery metrics microservices rulesThe microservice architecture has become increasingly popular over the past decade. Its key benefits include significantly improving the developer experience and accelerating software delivery. Sadly, however, microservices have often been widely misunderstood and used inappropriately. As a result, many organizations have struggled to benefit from their adoption. I’ve had numerous conversations where developers have complained that their new microservices-based applications are difficult to change.
In this presentation, I describe 11 development and architecture rules (a.k.a. best practices) that should prevent an organization from making a mess of its microservice architecture. I say should because given semantic diffusion and incredible ability of many organizations to misinterpret and misapply rules, there are no guarantees. However, I believe that if an organization follows these rules when adopting microservices, it will increase their chance of success.
The rules
Here are the rules:
- Practice continuous delivery/deployment
- Implement fast, automated deployment pipelines
- Organize into small, cross-functional, loosely coupled teams
- Provide a great developer experience (DevEx)
- Use a deliberative design process
- Design independently deployable services
- Design loosely coupled services
- Design testable services
- Develop observable services
- Incrementally migrate from a monolith to microservices
- Track and improve software metrics and KPIs
To learn more please see related articles.
Premium content and office hours is now available for paid subscribers at 
