Decomposing monoliths into microservices - AWS Prescriptive Guidance

Decomposing monoliths into microservices

Hari Ohm Prasath Rajagopal, Tabby Ward, and Dmitry Gulin, Amazon Web Services (AWS)

January 2021 (document history)

A migration to the Amazon Web Services (AWS) Cloud has many advantages, including technical and business agility, new revenue opportunities, and reduced costs. To fully benefit from these advantages, you should continuously modernize your organization’s software by refactoring your monolithic applications into microservices. This process consists of three main steps:

One of the first steps in your application modernization journey is to decompose the monoliths in your portfolio into microservices. Most applications begin as monoliths that represent a specific business use case, and if the monolith's architecture doesn’t enforce modular design, a monolith can remain a valid choice for applications that don’t have well-established domain knowledge. The central characteristic of a monolith as a single unit of deployment can also help mitigate design flaws, such as tight coupling or a lack of internal structure.

Although a monolith can be a valid option for some use cases, it is typically not suitable for a modern application. The poorly defined internal structures of a monolith can make it difficult to maintain code, which creates a steep learning curve for new developers and causes additional support costs. High coupling and low cohesion can significantly increase the time it takes to add new features, and you might be unable to scale individual components based on traffic patterns. Monoliths also require multiple teams to coordinate for one large release, which increases the collaboration and knowledge transfer burden. Finally, you can find that adding new features or building new user experiences becomes difficult when your business grows or user numbers increase.

To avoid this, you can use decomposition patterns to break down monolithic applications, convert them into several microservices, and migrate them to a microservices architecture. Before you begin the decomposition process, you should evaluate which monoliths to decompose, and make sure to include those with reliability or performance issues, or those that include multiple components in a tightly coupled architecture. We also recommend that you fully understand the monolith’s business use case, technology, and its interdependencies with other applications.

This guide is for application owners, business owners, architects, technical leads, and project managers. It discusses the following four cloud-native patterns that are used to decompose monoliths, and describes the advantages and disadvantages of each one:

The guide is part of a content series that covers the application modernization approach recommended by AWS. The series also includes:

Targeted business outcomes

You should expect the following outcomes after you decompose your monoliths into microservices:

  • An efficient transition of your monolithic application into a microservices architecture.

  • Rapid adjustments to fluctuating business demand but without interrupting core activities, such as high scalability, improved resiliency, continuous delivery, and failure isolation.

  • Faster innovation because each microservice can be individually tested and deployed.