Top Three Strategies for Moving From a Monolith to Microservices
We take a look at why you may want to switch your architecture to be microservices-based and give some high-level advice on how to get there.
Join the DZone community and get the full member experience.Join For Free
One of the primary problems facing enterprises is the problem of moving from monolith to microservices. The larger the enterprise, the bigger their monolithic applications become, and it gets harder to refactor them into a microservices architecture.
Everyone seems to agree on the benefits of microservices. We covered this topic 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. The bigger the monolith, the bigger the stakeholders' and management's footprint becomes. Too much management often leads to decision paralysis and, ultimately, the journey ends up as a mess.
However, many organizations have successfully managed to make this transition. Often, it is a mix of good leadership and a well-defined strategy that determines success or 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 a monolith to microservices, you have 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.
Often, organizations miss this part completely. They think about a grand migration strategy that will take years. However, business requirements come fast. Due to the lack of budget or time, teams end up implementing those requirements into the monolithic application. The grand migration strategy never starts for whatever reason. And, 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 create inertia towards the migration. It also helps demonstrate the value of the approach and ensures continuous investment.
Separate Presentation Layer From the Backend
This is an extremely powerful strategy to migrate from a 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 generating HTML pages. In any respectable application, this tier has 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 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'll 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 that can be explored.
There are advantages to this approach:
- You can develop, deploy, and scale both applications independently. In other words, UI developers can rapidly introduce changes to the interface. They don't have to worry about the impact on the backend.
- You will 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 a microservices architecture. The previous two strategies will take you only so far. Even if you successfully implement them, you'll still have a very monolithic code base. Basically, they can act only as a spring-board to the real deal.
If you want to make a significant move towards microservices, you need to break apart the monolithic code base. The best way to do this is by breaking up the monolith based on business functionality. Each business functionality is handled by one microservice. Each of these microservices should be independently deployable and scalable. Communication between these services should be implemented using remote API calls or through message brokers.
By using this strategy, over time, the number of business functions implemented as services will grow and your monolith will gradually shrink. This approach is also known as vertical slicing. Basically, you are dividing your domain into vertical slices or functionalities.
Moving from a 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 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.
Published at DZone with permission of Saurabh Dashora. See the original article here.
Opinions expressed by DZone contributors are their own.