Microservices adoption anti-pattern: scattershot adoption

microservices adoption   anti-patterns  

---

---

So far in this series I’ve covered the following anti-patterns

• Microservices are a magic pixie dust anti-pattern
• Microservices as the goal

Another anti-pattern that I’ve encountered is Scattershot adoption which occurs when multiple application development teams attempt to adopt the microservice architecture without any coordination. Several teams might, for example, simultaneously develop the development infrastructure, such as automated deployment pipelines, and setup runtime infrastructure, such as Kubernetes. A common reason for this anti-pattern is that a leader of the organization made the adoption of microservices everyone’s goal.

Consequences

On the one hand, it’s great that there is a growing grassroots effort within the organization to adopt the microservice architecture. But on the other hand, having multiple teams simultaneously investigate microservices without any coordination is inefficient. There is likely to be duplication of effort, e.g. multiple teams figuring out how to develop microservices, build infrastructure for deployment pipelines and set up runtime environments. Moreover, development teams might not have the skills or the time to build and management development and runtime infrastructure.

A better approach

A better approach is for the organization to define and execute a microservices migration roadmap. The roadmap consists of numerous activities including:

1. Leadership should define and communicate the strategy
2. Baseline key delivery metrics (lead time, and deployment frequency, etc.)
3. Establish an infrastructure team responsible for creating the development and runtime infrastructure
4. Select a candidate monolithic application
5. Iteratively extract services from the monolith (Strangle the monolith):
   1. Establish team responsible developing, testing and deploying the service
   2. Extract service from monolith
   3. Hold a retrospective, implement lessons learned including approach and infrastructure
   4. Document and share lessons learned
6. Expand to other applications

• 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 including how I can help you create a microservices migration roadmap for your organization
• Learn more about microservices at adopt.microservices.io