Monolith to Microservices
We might be starting from an existing monolithic application that we want to move to a microservices architecture. This can even be the result of a decision to start with a monolith that we would eventually move to a microservices architecture. Regardless of how we ended up with a monolith, we now want to refactor this monolithic application into a microservices architecture because the benefits outweigh the costs of moving and managing a microservices application. There are a number of different ways to approach this, and we discuss some of those in this section. We have the benefit that we have a fairly well-established business model, and data to help define our service boundaries.
The challenges we often face when breaking down a monolith into a microservices is the tight coupling within the system that contains all kinds of unrelated code that is intertwined throughout the application. It can be very difficult to untangle the pieces of functionality we wish to break out of the application into separate services.
We should first determine the motivations for refactoring a monolithic application into microservices, as this will affect the approach and priorities. If it’s because we want to be able to add new features using a different technology, then maybe we don’t need to refactor the monolith, and instead can add the feature alongside the monolith. If there’s a feature causing some pain or the rest of the monolith is holding back the capability of implementing some feature, then maybe we need to start with moving that one feature first.
Refactoring a monolith is often a process of breaking out one microservice at a time. Parts of the monolith’s functionality are replaced with a microservice, and over time the entire monolith has been completely decomposed into a microservices architecture. As the monolith is reduced in size, it will eventually become easier to work through those last few challenging items at the end. Where to start and what to slice off first is something we need to think about very carefully.
Collect Data
Adequate logging and telemetry from a monolith can be extremely useful information when approaching the task of breaking it down into a microservices architecture. This information can be especially useful when we need to partition for scale, or with identifying coupling in a data store. We might want to ensure our monolith has instruments to gather additional information that will help identify the boundaries for its decomposition into microservices.
We can start by identifying the business capabilities and bounded contexts within the application’s domain, then begin analyzing the code. We can find seams in the code, making it easier to decouple one feature easier than another. Dependency tools and profilers can be useful in better understanding the structure and behavior of the application. A feature might exist that has a particular need that is satisfied by a microservices architecture today, like the need to release very quickly; or maybe this feature is fragile and breaks often because of releases to the monolith. It might even be that we want to start with easier-to-partition features and experiment with microservices. Below is a list of things we need to consider and think about when we approach partitioning a monolith.
Considerations for partitioning and prioritization:
• Rate of changes: Features that are changing and need to be released often, or those that are very stable and never change.
• Scale: Features that require very different scale requirements than the rest of the application.
• Technology: A feature can leverage a new technology, making it a good candidate to be partitioned out of the monolith.
• Organizational structure: A team working on a feature could be located in a different region.
• Ease: There can be some seams and features in the monolith that are easier to partition out and experiment with.
• Security: There can be features in the application that deal with very sensitive information and require additional security.
• Availability: A feature can have different availability requirements and it can be easier to meet these requirements by breaking it out into its own service. This enables us to more effectively isolate costs to targeted areas of the solution.
• Compliance: Certain aspects of the application can fall under compliance regulations and would benefit from being separated from the rest of the application so that the rest of the application is not subject to the compliance rules.
Also consider the fact that we don’t have to break out every feature into microservices. It might be better to divide and conquer only if it makes sense for the application. Break up the monolith into some coarse-grained services, and then continue to chip away at one or two large services in parallel.
In addition to splitting out the code into another service, we also have to think about data migration and consider data consistency as we decentralize the data and place it in separate data stores. There will often be some coupling between components and features in the database. The database can be full of challenges like shared data and tables, transactions, foreign key constraints, and reporting needs. We might want to break out the behavior as a first step and enable the monolith and our new service to share the database for some time.
As services are broken out from the monolith, they need to continue to collaborate and integrate with the monolith. A proxy can be placed in front of the monolith to route traffic to the new services as they are broken out. Features partitioned out of the monolith might need to be replaced with client proxies used to call the new service. Also, where services need to interact with the existing monolithic application, consider adding an anti-corruption layer. The anti-corruption layer is introduced in Domain-Driven Design (DDD), by Eric Evans. This approach creates a façade over the monolithic application and ensures the domain model of the monolith does not corrupt the microservices we are building.