My notes on Monolith to Cloud Native (Part 1)

In this multi-part series, I will share my understanding and thinking around decomposing an application from monolith to cloud native.?I will address some of the concerns and issues that, when appropriately tackled, helps us succeed in this endeavor. As software engineers, we often think it is a purely technical challenge, but that is not the case. It involves dealing with all three aspects: people, process, and technology.?In this article, I will address the people dimension.

From people, I mean various stakeholders for the project.?It includes folks from business and engineering teams within the organization.?Following are some of the considerations to keep in mind.

Why the decomposition?

Stakeholders first need to have a shared understanding and rationale about migrating an application from monolith to cloud native.?What are some of the objectives and goals??For example, it might be that our customers have outgrown our capacity.?We can no longer meet customers' demand by merely buying bigger machines or adding load balancers and running multiple instances of the monolith.?Another rationale could be that our monolith's deployment frequency is slowing us down.?It is taking much longer to deliver new features and functionality to our customers.?Other possible reasons could be team autonomy, app modernization, etc.?The clarity in goals and objectives will help teams learn about business urgency and offer us some criteria to measure our success.

Once we have the goals, it is prudent to pick one or two as the primary objectives.?It is counterproductive to try to achieve many diverse goals in this decomposition initiative.

Where to start?

The stakeholders next need to agree on the decomposition plan or strategy.?It is a complex problem, and we need an approach that will manage the software complexity.

I will repeat this statement a few times in this series - it has to be an incremental and iterative approach.?Following is a warning to pay attention to.

If you do a big bang rewrite, the only thing you're guaranteed is a big bang.

— Martin Fowler

It is essential to realize the significance of an incremental decomposition approach.?In the book (see reference [1] ), Sam Newman mentions that the extraction exercise is not complete until the code is in production and being actively used.?The incremental approach helps with quicker (and smaller) deployments to the production.?It also helps the team build up expertise in this area.?Deploying smaller work units to production also helps mitigate the risks and get faster feedback from our customers.

I firmly believe that Domain-Driven Design (DDD) offers us good tools and strategies for decomposition.?Next, I will present few DDD concepts that are essential in this matter. For a more detailed readings on DDD please see the reference [2].

Identify the Subdomains

The first order of business is to identify various subdomains for our application.?I realize that most of the monoliths we are dealing with are a decade or more old.?Probably written before the days of DDD.?The existing application state could be a modular monolith, a big ball of mud, or anything in between.?Note that we are not concerned with the ground reality of the monolith at this point.?Our eyes are set on the future.?We want our cloud native application to be loosely coupled and highly cohesive, attributes we care about deeply.?It should follow the best practices for a modern distributed application.?By focusing on subdomains, we ensure these objectives will be met.

To uncover the subdomains, we need to have a conversation with the domain experts.?You may find these experts in diverse teams such as business, customer support, and engineering.?One approach to conduct a few collaborative sessions among the experts is to run an Event Storming workshop (see reference [3]).

To make it more concrete for this article, I will pick a familiar domain such as an eCommerce application.?In such an application, the following are some subdomains: Products Catalog, Orders, Invoicing, Inventory, Shipping, and Notifications.?This is by no means an exhaustive list but enough to get the point across for this article.?We will move to the next step with the subdomains identified, i.e., create a context map.?

Create a Context Map

Context Map offers a way to visually realize the relationship between subdomains.?The figure below shows the context map for our example eCommerce application.

Context Map above depicts various subdomains as bubbles.?The line between them shows a relationship between the subdomains.?I will shortly explain this relationship.

It is important to note that Context Map is not a systems diagram.?It is not a communication diagram either.?That is, the line makes no assumption about sync, async, one-way, or two-way communication between the subdomains.?It is a relationship diagram between the subdomains.??

Context Map makes explicit which subdomains own the domain model.?For example, all product-related domain models are owned by the Product Catalog subdomain.?It is the source of truth for it.?Other subdomains could have a read-only copy of product-related domain models but no ownership.?As I mentioned before, the line between the subdomains depicts a relationship between the two.?DDD defines various kinds of relationships, but for our discussion, I will use the Customer-Supplier relationship.?In this relationship,?the two subdomains have an upstream (indicated by 'U') downstream (indicated by 'D') relationship.?The downstream subdomain has a dependency on the upstream subdomain. The upstream subdomain is independent but has to factor in downstream priorities.?During this exercise, it is important to mark these relationships correctly to reflect reality.?A team owns a subdomain, and it should understand its relationships with the other teams.

Once the context map is laid out, it is time for stakeholders to chime in.?Engineering folks need to estimate the level of difficulty in extracting a particular subdomain from the monolith.?Business folks need to weigh in on the benefit or value of a subdomain decomposition.?When the data is available, it is time to move to the next step of laying out a prioritization quadrant.

Layout a Prioritization Quadrant

I came across this neat idea from Sam Newman's book (see reference [1] ).?The basic idea is to put each candidate subdomain on a two-dimensional plane.?The x-axis represents the business value the decomposition will bring, and the y-axis represents the engineering effort involved in the decomposition. The figure below shows the prioritization quadrant for our example.???

The above diagram communicates that the Product Catalog has a high value for business and is relatively easy to decompose from the monolith.?Similarly, Orders has a high value for business and is somewhat tricky to decompose from the monolith.

This approach allows various stakeholders to get on the same page concerning the decomposition strategy. It enables them to make appropriate trade-offs.?For example,?Notifications has a high business value, but at the same time, it is a much-involved effort. If we are looking for quick wins and build confidence in our approach, the upper-right quadrant gives us a sweet spot to start.??

Summary

In this article, I covered the people dimension of the decomposition journey. For various stakeholders to get on the same page and have a shared understanding, the following is an essential part of the journey:

• Identify one or two primary goals for the decomposition
• Identify subdomains and draw a context map
• Draw a prioritization quadrant for a visual picture of the trade-offs
• Follow an incremental and iterative approach for the decomposition

References

[1] Monolith to Microservices by Sam Newman

[2] In DDD community, two well regarded references are:

• Domain-Driven Design by Eric Evans (aka the Blue Book)
• Implementing Domain-Driven Design by Vaughn Vernon (aka the Red Book)

[3] Introducing EventStorming by Alberto Brandolini