Monolith to Microservices

Chapter 3. Splitting the Monolith

In Chapter 2, we explored how to think about migration to a microservice architecture. More specifically, we explored whether it was even a good idea, and if it was, then how you should go about it in terms of rolling out your new architecture and making sure you’re going in the right direction.

We’ve discussed what a good service looks like, and why smaller services may be better for us. But how do we handle the fact that we may already have a large number of applications lying about that don’t follow these patterns? How do we go about decomposing these monolithic applications without having to embark on a big bang rewrite?

Throughout the rest of this chapter, we’ll explore a variety of migration patterns and tips that can help you adopt a microservice architecture. We’ll look at patterns that will work for black-box vendor software, legacy systems, or monoliths that you plan to continue to maintain and evolve. For incremental rollout to work, though, we have to ensure that we can continue to work with, and make use of, the existing monolithic software.

Tip

Remember that we want to make our migration incremental. We want to migrate over to a microservice architecture in small steps, allowing us to learn from the process and change our minds if needed.

To Change the Monolith, or Not?

One of the first things you’re going to have to consider as part of your migration is whether or not you plan (or are able) to change the existing monolith.

If ...