Chris Richardson has helped numerous clients around the world adopt the microservices architecture.
As well as helping clients with the technical aspects of the microservice architecture, Chris also helps them avoid other pitfalls of adopting microservices including those related to process, organization and adoption strategy.
For more, see his keynote at the O'Reilly Software Architecture conference Potholes in the road from monolithic hell
Monolith to Microservices migration
Through a combination of consulting and training, we work with you to develop the skills and the strategy for incrementally refactoring your monolithic application to a microservice-based architecture. During the engagement we work with you to define the initial microservice architecture and teach you what you need to know in order to to successfully migrate to a microservice architecture.
An engagement typically consists of the following steps:
- Engagement kickoff:
- Discuss key metrics:
- Development: lead time, deployment frequency, …
- Operational: change failure rate, availability, mean time to recover, …
- Conduct retrospective: what’s working well, what needs to be improved
- Review how to document architecture
- Discuss key metrics:
- Review requirements
- Understand the domain, for example, by using event storming
- Identify architecturally significant stories/scenarios including those that are complex, latency/availability sensitive, etc.
- Review AS-IS monolithic application architecture:
- Key elements of the architecture
- Technical architecture
- How architecturally significant stories/scenarios flow through the architecture
- Review development and delivery organization’s structure
- Review development and delivery practices including
- Code quality
- The flow from development to production including automated deployment pipeline
- Automated testing strategy
- Identify training needs and deliver training, such as:
- Microservice architecture design principles
- Strategies for refactoring a monolith to microservices
- Brainstorm TO-BE:
- Perform build-vs-buy analysis to identify system components that should use 3rd party products and services
- Service decomposition, define responsibilities, APIs, and collaborations
- Technical architecture to support services including: inter-process communication mechanisms, deployment infrastructure, etc.
- Development and delivery organization’s structure
- Development and delivery practices
- Create plan for refactoring from AS-IS to TO-BE based on effort/impact
Estimated duration: 5-7 days in-person or remote equivalent
After the initial engagement, we periodically provide any needed technical review and guidance.