One of the primary problems facing enterprises is the problem of moving from monolith to microservices. The larger the enterprise, the bigger are their monolithic applications. And harder it is to refactor them to a microservices architecture.
Everyone seems to agree to the benefits of microservices. We covered it at some length in this post. However, not many seem to agree on how to undertake the migration journey. Too often, the decision-making process turns into a chicken-and-egg problem. Bigger the monolith, more are the number of stakeholders and management footprint. Too much management often leads to decision paralysis and ultimately, the journey ends up as a mess.
However, many organizations have successfully managed to take this transition. Often, it is a mix of good leadership and well-defined strategy that determines success and failure.
Good leadership is often not in the hands of an architect or developer undertaking this journey. However, a strategy is. So, let’s look at some strategies that can help in this journey:
Implement new functionalities as services
I know it is hard. But if you’ve decided to transition from monolith to microservices, you’ve to follow this strategy. Think of the monolithic system as a hole in the ground. To get out of a hole, you don’t dig more. In other words, you don’t add to your problems.
The same is applicable for monolithic systems.
Often, organizations miss this part completely. They think about a grand migration strategy that will take years in the making. However, business requirements come thick and fast. Due to lack of budget or time, they end up implementing those requirements in the monolithic application. The grand migration strategy never starts for whatever reason. Also, each addition to the monolith makes the goal-post move further ahead.
In order to get around this, stop increasing the size of the monolith. Don’t implement new features in the monolithic code-base. Every new feature or functionality should be implemented as services. This, in turn, reduces the growth rate of the monolithic application. In other words, new features implemented as services creates inertia towards the migration. It also helps demonstrate value of the approach and ensures continuous investment.
Separate presentation layer from the backend
This is an extremely powerful strategy to migrate from monolith to microservices. A typical enterprise application usually has three layers:
- Presentation logic that consists of modules implementing the web UI. This tier of the system is responsible for handling HTTP requests and generate HTML pages. In any respectable application, this tier is a substantial amount of code.
- Business logic that consists of modules handling the business rules. Often, this can be quite complex in an enterprise application.
- Data access logic that consists of modules handling the persistence of data. In other words, it deals with databases.
Usually, there is a clean separation between presentation logic and the business logic. The business tier exposes a set of coarse-grained APIs. Basically, these APIs form an API Layer. In other words, this layer acts as a natural border based on which you can split the monolith. This approach is also known as horizontal-slicing.
If done successfully, you would end up with smaller applications. One application will handle the presentation. The other application will handle the business and data access logic. There are various data management patterns for microservices architecture that can be explored.
There are advantages to this approach:
- You can develop, deploy and scale both applications independently. In other words, the UI developers can rapidly introduce changes to the interface. They don’t have to worry about impact on the backend.
- You would also have a set of well-defined APIs. Also, these APIs will be remotely accessible for use in other microservices.
Extract business functionalities into services
This is the pinnacle of moving to microservices architecture. The previous two strategies will take you only so far. Even if you successfully implement them, you’ll still have a lot of monolithic code base. Basically, they can act only as a spring-board to the real deal.
If you want to take a significant move towards microservices, you need to break apart the monolithic code-base. The best way to do so is breaking up the monolith based on the business functionality. Each business functionality is handled by one microservice. Each of these microservices would be independently deployable and scalable. Communication between these services would be done using remote API calls or through message brokers.
By using this strategy, over time the number of business functions implemented as services grows. Your monolith gradually shrinks. This approach is also known as vertical-slicing. Basically, you are dividing your domain into vertical-slices or functionalities.
Conclusion
Moving from monolith to microservices is not easy. It requires significant investment and management buy-in. On top of all that, it requires incredible discipline and skill from the team actually developing it. However, the advantages are many.
Often, it is a good idea to start small on this journey. Rather than waiting for a big one-shot move, try to take incremental steps, learn from the mistakes, iterate, and try again. Also, don’t try to go for a perfect design from the get-go. Instead, be willing to iterate and improve.
Lastly, remember that microservices is not a destination but a journey. A journey of continuous improvement.
Let me know your thoughts and experiences about this in the comments section below.
0 Comments