from monolith to microservices: a smooth transition
Hey everyone,
So, I’m kickstarting a project with a monolithic architecture and thinking ahead about shifting to microservices down the line. I wanna make sure this transition is as smooth as possible, you know?
From my research and some gyaan I got from friends, here’s the lowdown:
- Modular Design: Break down the monolith into well-defined modules. It makes it easier to extract services later.
- API Gateway: Even within a monolith, use an API gateway to manage and route traffic. It will come in handy when you start splitting services.
- Separation of Concerns: Keep different functionalities isolated. This way, when you split the monolith, you can turn each isolated function into a service.
What tools or strategies have you guys used to make sure your monolith doesn’t become a big, monstrous thing? Any tips or warnings from your own experiences?
Would love to hear your thoughts!
𝗪𝗵𝘆 𝘆𝗼𝘂 𝘀𝗵𝗼𝘂𝗹𝗱 𝗯𝘂𝗶𝗹𝗱 𝗮 (𝗺𝗼𝗱𝘂𝗹𝗮𝗿) 𝗺𝗼𝗻𝗼𝗹𝗶𝘁𝗵 𝗳𝗶𝗿𝘀𝘁?
In recent years we have seen a large increase in apps built by using a microservices architecture. The main reason why we select this approach is to have small teams that can work in isolation, without having them trip over each other. Yet, this is an organizational problem, not a technical one. We can also build each service in separate technology and scale indepenedently.
With the 𝗺𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵, we have a few disadvantages too, the system is becoming complex to maintain and diagnose issues (logging and tracing). And this is very important when dealing with microservices.
So, 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗺𝗼𝗻𝗼𝗹𝗶𝘁𝗵𝘀 𝗱𝗼𝗲𝘀𝗻'𝘁 𝗺𝗲𝗮𝗻 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗯𝗲𝘁𝘁𝗲𝗿 𝗽𝗲𝗿 𝘀𝗲. In the last years, we often saw the identification of monolith with a big ball of mud architecture or purely building legacy code, which doesn't mean to be. Yes, monoliths cannot scale-independent pieces of the system or release them separately, but those are mainly the biggest downsides. Still, you can create great and high-quality code inside. What monolith bring to us is much less complexity, reduced network calls, simpler logging, etc.
What could be one good solution, where we can still have separate modules and work on them, but maintain simplicity is to 𝗯𝘂𝗶𝗹𝗱 𝗮 𝗺𝗼𝗱𝘂𝗹𝗮𝗿 𝗺𝗼𝗻𝗼𝗹𝗶𝘁𝗵. A properly built modular monolith can be a good step that can be more or less transformed into a microservice solution tomorrow if needed.
When we want to build a modular monolith, it is crucial to 𝗳𝗶𝗿𝘀𝘁 𝗱𝗶𝘃𝗶𝗱𝗲 𝘁𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗶𝗻𝘁𝗼 𝗺𝗮𝗻𝗮𝗴𝗲𝗮𝗯𝗹𝗲 𝗺𝗼𝗱𝘂𝗹𝗲𝘀 before assembling those modules into a monolith for deployment. As all communication between the modules might result in a cross-network call, if you decide to break it into services in the future, high cohesion and low coupling are crucial in this situation. This means that all inter-module communication must be abstracted, asynchronous, or based on messaging in order for the modules to handle calls that travel across the network in the future.
How we can put in place such a concept? 𝗪𝗲 𝗰𝗿𝗲𝗮𝘁𝗲 𝘀𝗲𝗽𝗮𝗿𝗮𝘁𝗲 𝗺𝗼𝗱𝘂𝗹𝗲𝘀, 𝘄𝗵𝗲𝗿𝗲 𝗲𝗮𝗰𝗵 𝗼𝗻𝗲 𝗰𝗮𝗻 𝗵𝗮𝘃𝗲 𝗶𝘁𝘀 𝗼𝘄𝗻 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲, and those modules are pulled together into a single API gateway. This allows us to deploy the whole system as a monolith, but it allows us to pull out separate modules into services if needed in the future.
Good insights, anything else?
-
Ensure the long running tasks aren't assigned to a microservice in any way. AWS costs per time used and that will skyrocket your billing.
-
Kinda unrelated but ensure you follow best API practices.
-
If you are making really similar looking code in each serverless function, it's time to abstract that logic into its own service
Honestly the main thing comes down to cost. Yes microservices offer higher availability and better scalability but that can be done on a monolith as well