Blog
Roadmap:
From Monolithic Architecture to Microservices
- Part 3 -
Mijail Espadas
“If you do a bing-bang rewrite, the only thing you’re guaranteed of is a bing bang”
Diagnosis and Technological Strategy
In the first sections of this article, we talked about the importance of carrying out a technological diagnosis before modernizing any solution or portfolio towards microservices (in fact, towards any architecture).
The technological diagnosis gives us an X-ray of the underlying problems that we want to solve; it is important to remember that implementing a microservices architecture is not the end goal, no matter how trendy it may be.
Once the diagnosis has been made, the proposed roadmap leads us to define the technological strategy to be implemented, defining the project portfolio, software and data architecture, and infrastructure. If the technical basis is established, we then move on to the implementation strategy.
Figure 1. After the Technological Strategy
Implementation Strategy
This strategy will define some elements with which we’ll be able to carry out modernization projects without affecting the operation of the business. As in many cases in software development, it isn’t all about reinventing the wheel. We have patterns for this that have already been used when migrating legacy systems.
Migration and Decomposition Patterns
The migration and decomposition patterns establish practices for refactoring our monoliths. Their objective is to minimize risk and increase the percentage of success with the eventual possibility of returning to a consistent state of the solution (rollback) in the event of any problem in the implementation. We’ll continue discussing the 2 most common patterns: Strangler Fig and Sidecar.
“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.”
The Strangler Fig Pattern
The Strangler Fig pattern, or simply Strangler, establishes those components or services with null (or very little) dependency on the others, migrating monolithically. The strategy consists of “disintegrating” the monolithic application until its complete disappearance.
Figure 2. “Killing the monolith” using the Strangler Fig pattern
Using this pattern minimizes the risk of migrating the entire system and releasing everything “at once”. It also allows you to prorate the development effort over the time of the migration. In the implementation of this pattern, using the Facade pattern is recommended to encapsulate the changes, allowing the components that call the microservices to be somewhat transparent or having fewer changes.
Identifying the components most likely to migrate is one of the main tasks for this pattern to be implemented correctly. An analysis of the component architecture of our monolithic must be carried out, in order to identify said components, seeking to also separate them by domain (we discussed the Bounded Context in the second part of this article).
Modeling our components, and specifying their dependencies can help us better identify the sub-systems, projects, libraries or classes that we can encapsulate in new microservices.
Figure 3. Determine first components to migrate.
The Strangler Fig Pattern
The Sidecar pattern (also known as Parallel Run) is an approach used to migrate legacy systems to new technologies. Similar to the Strangler Fig, the strategy is to evolve processes while the system continues to function. In the analysis we must identify components that can be separated to be implemented and executed in parallel that in some way replace complete functionalities through the microservices architecture.
Figure 4. Sidecar pattern for encapsulating and migrating components
One of the impacts of this pattern is that certain loads are balanced from the client components. For this purpose, some integration patterns must be considered, such as an API Gateway or a Proxy to be able to segment the calls.
Typically, we begin to migrate components or services that are transversal in the applications, such as logging, monitoring, security components, monolithic APIs, integrations to third-party services, among others.
Other migration and decomposition patterns
There are other patterns or practices that can help us successfully migrate from monolithic systems to microservices, including:
– UI Decomposition
– Separation by abstraction
– Collaborator / Decorator
An excellent source to delve into these patterns is the book “Monolith to Microservices” by Sam Newman.
Processes, Government and Operation
Suffice it to say that for a successful migration to microservices, we must have the correct methodology. The success of this architecture is underpinned by agile development methodologies, being able to have high-performance teams focused on a single business domain.
Figure 5. High performance methodology (Ensitech 2022)
The governance of this methodology is of the utmost importance, that is, that the processes are carried out correctly is the core of migration projects. Having risk management mechanisms, quality assurance, agile work plans and checkpoints allow key migration indicators to be evaluated.
The use of DevOps processes and tools is also key to a successful modernization. Optimizing development processes is an objective of the microservices architecture, but so is being able to use processes and tools that allow the continuous integration and release of our products, delivering greater value in less time.
Conclusion
We have talked about the migration roadmap from a monolithic architecture to microservices. In the first part, we talked about technical diagnosis, and why it is important to really analyze our technological architecture in order to make the right decisions.
In the second part, we talk about the technology strategy to consider, starting with the portfolio of projects to migrate and their corresponding technology stack.
In this last part, we describe some implementation strategies such as some migration and decomposition patterns, as well as the importance that modernization projects must always be executed with a robust and agile methodology, with processes and governance that increase the probability of success for these extremely important investments.
This article was originally posted in spanish on Mijail’s LinkedIn.
USA
- 28 W Flagler St Ste 300b Office 2281 Miami, Fl 33130
- Phone: +1 (512) 717.7455
MONTERREY
- Ave. Juárez #1102, Local Nivel 5A Col. Centro Monterrey, Nuevo León, México.
- Phone: +52 (81) 2140.8840
MEXICO CITY
- Paseo de la Reforma 222 Torre 1, Piso 18, Suite 1823 Col. Juárez, Mexico City
- Phone: +52 (55) 8789.4678
HERMOSILLO
- Edificio Sonora - Oficina 24 2do Nivel insurgente Pedro Moreno #24, Hermosillo, Sonora.
- Phone: +52 (66) 2259.2388
MERIDA
- Calle 47 No. 331, Piso 3 Interior 300 Col. Benito Juárez, Mérida, Yucatán.
