30 September 2022 - 9 min. read
In the first article of our 3 part journey on how to break down a Monolithic application we have started talking about the advantages of a distributed application composed of microservices over a monolithic one. In this second part, we will start approaching techniques and tips to help you overcome the migration process in a more secure and aware way
CLEARLY DEFINE YOUR BUSINESS LOGIC’S DOMAINThis is by far the most important step as it states clearly if your knowledge of your logic’s domain is complete. In fact, one possible way to find which part of your application can be converted to a microservice is to check if you have a complete understanding of its domain, which means that it will be easier for your dev team to isolate and migrate the logic.Understanding the domain of a feature also means that, probably, it’s entanglement with the rest of the application is very low, ideally null, thus facilitating the separation from the main application.Knowing your domain means that you can define with clarity which services are vertical to the application, or in other words, which services are most important and target specific needs of a user base (thus defining the goal of your application) or are strategic for your company.Vertical services are by no means made of easy code and can be very big, but as said before, we are not referring to microservices by the quantity of code contained, but by definition of scopes and context boundaries.
DEFINE YOUR TECHNOLOGICAL TARGETCome to this point is important to clearly define our technological target, in the sense that we want to understand what kind of platform or framework we want to use for development and procedures of CD/CI (e.g Serverless Framework and AWS Lambda as a development environment) and what kind of programming language is best suited for migrating that precise part of your business logic. Having clear this part is very crucial as it helps thinking about the feasibility of that particular migration. Also, we have to understand that, even if migrating to microservices is, in general, a good behavior, it doesn’t mean that for your particular application, or part of it, it’s a good choice, but we will analyze this aspect later.In general, during the brainstorming involved in this step, we need to verify the costs in terms of code migration and infrastructure migration and the strategic value compared to developing new features.
WHERE TO START TO BREAK A MONOLITH: THE STRANGLER PATTERNUp to this point we have talked about preparations, let’s start to explain how to effectively break our monolithic infrastructure and what characteristics a microservice must have to be considered one once it has been extracted successfully.When we think about going from a monolithic approach to a microservice ecosystem we can think of two possible choices: a) to rewrite your code from scratch using the new paradigm or b) to migrate from the old one.Starting fresh on rewriting the entire application in one go is generally not a good choice because:
- It consumes a lot of time.
- It can bring technical debt along during the rewriting process.
- It can’t be used until all the rewriting is complete.
- We can’t really focus on new features as they need the application logic to be entirely ported as well causing delays for the business team.
- It requires a flexible time effort that can be adapted to the current development situation of your teams.
- The application can still be used because you are migrating only a small part of it at a time.
- You can continue developing new features making them as new microservices.
- A clear domain, a precise scope
- No data stored or data that can easily live on its own data source
- No sticky coupling with the rest of your application code
- If there is a component that has good test coverage and less technical debt associated with it, this is a good candidate (if the domain’s logic is clear enough).
- If a component has scalability requirements, go for it.
- If there is a component that has frequent business requirements and needs to be deployed a lot more regularly, you can start with that component.