Monoliths: Our position
We believe monoliths are an appropriate early stage choice, but once more developers and others start using the same code base, problems start. Developers report the portfolio is complicated, documentation is limited, and resources are too tightly coupled—and that they aren’t learning new skills because they have to maintain legacy apps and infrastructure. A new approach is required.
Microservices: How to get there
The key to gleaning microservices from a monolith is to find out the “seams” of an application—so you know the bounded contexts.
A level deeper
How do you take the bounded context out of the application. The key thing to find out who is calling is to put a fence around the bounded context and then figure out who is calling inbound and outbound. What are the dependences? What are the constraints? This will give you an understanding of the coupling and what events are attached to it. Then, you can put an API fence around the bounded context and start pulling out the bounded context into its own application.
The Mikado Method
This is another scientific approach to refactoring code. It proposes that for each change, you find the dependencies that create errors, fix them, find more, then fix them again. It’s a depth-first way of tackling refactoring, understanding the outcome at each point.
The Mikado Method and other decomposition patterns, including leveraging the anti-corruption layer, strangling the monolith, smart routing, and dark launching, are effective for pulling a monolith apart. Teams also have to migrate ESB composite and provider services to effectively transition to microservices. Watch the complete video to learn more.