With the constant changes in technology, the government agencies are also now trying to find ways to modernize their IT systems and provide better services. The biggest hurdle are the age old legacy systems which don’t just require a lot of downtime for maintenance but it’s also incredibly time consuming to add new functionalities to them.
One of the best ways to modernize legacy systems is by decomposing a monolithic core into microservices. You are able to break down the entire architecture into smaller services which then becomes much easier to manage and expand.
But before you dive into the modernization process and roll a transition, it’s important to consider all the factors.
Build DevOps capabilites first
One of the best advantages of microservices architecture is that it works well with continuous deployment and hence it’s crucial to ensure that you have an effective DevOps team in place to handle the transition since you will need to deploy multiple services quickly. If you only have a few people on the team that are skilled in development, then it may not take long for things to get out of hand.
That is why, you need developers who can handle every part of the code – from development, to deployment, and even monitoring, if needed. At the same time, the developers should also be prepared to handle worst case production scenario which could inevitably lead to a downtime. The DevOps team should be equipped to make sure the downtime is as minimum as possible.
Incremental transition reduces risk
When you first introduce the idea of transitioning the legacy systems to a microservices, the chances are, your team will be extremely excited about it. But, you shouldn’t go ahead of yourself and make a 2-week transition plan for the entire project. It could take you months or even years to transition the entire system into microservices.
It’s best to have a plan to break down the application into smaller pieces. Instead of handling it altogether, treat the application like a compost pile and slowly add the right ingredients to it so that it decomposes into a useful microservices application. Each piece of code that you extract should be planned out surgically in advance. Processing the transition too quickly could lead to errors and an even longer decomposition process.
Choose the right framework and language
One of the reasons why microservices is a preferred architecture by many organizations is because it gives developers the freedom to choose from a number of development languages and frameworks. Of course this means you will have to decide which framework and language you want to work on.
Learning new languages, tools, and frameworks is always exciting, and it may even work for a small project, but when you are planning to modernize a huge legacy system, there is no room for risks. It’s important to choose a framework and language that your IT team is comfortable with and that they can use seamlessly even for large scale projects.
What is the right transition strategy?
1- Use a glue code and don’t break the monolith
This strategy involves the idea that you shouldn’t make the entire monolith any bigger than it is. So, instead of breaking down the entire monolith, a standalone microservice is created and an extra code called the glue code is used to connect the microservice with the monolith.
Accessing data from the monolith, the glue code can reside in the microservice, monolith, or both and it’s main responsibility is data integration. The microservice uses this glue code to read and write data from the monolith. Operating as an anti-corruption layer, the glue code prevents the microservice from being corrupted by the concepts of the legacy monolith.
Since the new functionality is rather lightweight, it helps keep the monolith the same size and you still get the benefits of microservices with every new service that you create. However, since the monolith still exists, you don’t really address all the problems with this strategy.
This is a rather shortcut way which does not break the monolith, but if you plan to break it, then you should see other alternatives.
2- Split the frontend and backend
One way to decompose a monolithic application is by splitting its business and data access layers from the presentation layer. In most applications, there is a clear separation with the presentation layer on one side and business as well as data access layer on the other side.
The presentation layer is the part which handles HTTP requests and has a user interface. The business layer is the core of the application which implements business rules and data access layer includes the databases.
3- Break down the service and modules
An extensive and effective way of modernizing the legacy systems is by transforming the existing modules of the monolith into standalone microservices. Everytime you turn a module into a microservice, the monolith gets smaller. After sometime, either the monolith completely disappears or it becomes so small that it is just another microservice.
Though, decomposing a large monolithic application can mean turning hundreds of modules into microservices. It is a large process which starts by analysing which modules should be converted first. One way to approach the extraction process is by converting the easiest modules first to get an idea about the entire process. You can also use the course grain boundaries to find modules to extract.
To modernize legacy systems and convert monoliths into microservices can take a long time, but with the future benefits it provides, modernizing systems in government agencies is definitely worth the effort.