[Web] Divide a Monolith Application Into Microservices

Using the Strangler Pattern

 

First write the Dependency Graph. For example:

It would be a good idea start `C` module or `A`.

It would be a bad idea starting from `B` or `D`.

 

Monolith Application

Step 1: Strangle the Shopping Cart into a Microservice

Step 2: Strangle the Catalog into a Microservice

Step 3: Strangle the Front End into a Microservice

 

Map Your Dependencies

• It's important to understand the application you're working with before breaking it apart.
• One strategy is to map out the modules and their dependencies as a directed graph to understand the downstream impact of your changes.

Where to Start?

• There’s no hard rule: choose the part of the application that makes the most sense to you.
• Dependency graph serves merely as a guideline on risk based on the number of dependencies.
• A module with the least dependencies will potentially have the downstream effects meaning less risk.

How to Start?

• The Strangler pattern is a common and effective way to migrate legacy applications.
• Rather than replacing your code with a new version, you can gradually replace components of your application.

Shared Code

• Code duplication can be abstracted into common libraries used across projects.

---

 

 

Let's plan for how we can refactor a hypothetical e-commerce monolith application.

Build a dependency graph of the system below. Then, using the graph and business context, decide what parts of the application would make the most sense to begin refactoring using the strangler pattern.

(Hint: there’s no “correct” answer for the dependency graph -- use your intuition to draw the relationships. In practice, we may have to also read through code to build these out!)

 

Dependency Graph

• Dependency graphs are one way to help us visualize and make an informed decision
• We often have to use additional context with regards to business functionality to weigh decisions
• Database complexity should also be considered for refactors. Services that seem simple may have complicated refactor strategies with their databases.