Using Microservices for Legacy Software Modernization
Legacy software modernization is the process of revamping a dated application by rewriting it in a new programming language, migrating it to a new database (a physical or a cloud one), and/or redesigning its architecture.
One of the approaches to redesigning legacy software lies in breaking up an old “monolithic” app into a set of lightweight microservices. Sometimes it makes sense to pursue this approach, and sometimes it doesn’t. It’s worth remembering that service-oriented apps are not a be-all and end-all solution. Many developers set out to create a microservice architecture, but end up with what Google’s Kelsey Hightower calls “a distributed monolith”.
In this article, we will talk about the pros and cons of using microservices to modernize legacy software and consider the pitfalls such a move may entail. A lot of the information in this post comes from experience, because we have worked on creating service-based architectures for our clients here at ObjectStyle quite a lot.
Making a case for microservices
As it was said before, sometimes it makes sense to go with a service-oriented architecture, and sometimes it does not. Not all modern apps have microservice architectures.
There is nothing inherently wrong with the monolith – the type of app that is usually contrasted with microservices. It has its place and use cases. All in all, monoliths are better suited for small applications. If your app has few components that are easy to keep in sync, it may as well stay a monolith.
Both monolith and microservice architectures have their pros and cons.
| ??? | ❌❌❌ | |
| Monolith | + you only have one code base. + it’s pretty clear how apps interact (if there aren’t too many of them.) |
– when you release a new version, you need to deploy the entire app. – you can’t scale apps individually. – any code changes affect the entire system. |
| Microservices | + apps can be built using different programming languages/tools. + you can scale each service individually. + services can be run and updated independently. |
– it’s a distributed system and hard to get right. – you have to deal with lots of different types of servers and databases. |
Even if you have legacy software which is a monolith, this doesn’t automatically make it a candidate for being converted to microservices. When do monolithic applications become “toxic”? They do, when the following three conditions are met: there is complexity at scale (enterprise), some legacy is involved, and it’s a monolithic setup.
Complexity at scale multiplied by interconnectedness multiplied by insupportability equals a problem.
When you have realized you are dealing with a “toxic” monolith, this only means that you can’t leave it as is – it does not mean that your only option is to redesign it as microservices. Here is when your business analysts should get to work. Do the inventory of all business problems your legacy solution solves: some of them may no longer be valid, while others could be better solved with out-of-the-box software.
If you find enough functionality areas that each could be mapped to a simple, lightweight in-house app, then you have a good reason to redesign your monolith as a group of microservice applications.
Pitfalls of microservice architectures
Microservices increase the system’s complexity, but your system doesn’t have to be complicated at that – at least not if you do it the right way. The problem is there are many nuances to microservice architectures, especially when it comes to delivering service-oriented apps.
For a full list of microservice-related pitfalls and their solutions, please read DevOps in the Age of Microservices. The article provides detailed recipes for avoiding common mistakes.
In short, the common DevOps issues associated with microservices are:
- Communication issues. Reason: tight compiling of services and shared DBs.
- Limited observability. Reason: network complexity.
- Difficulty scaling individual services. Reason: poorly-designed system.
- Difficulty achieving consistency across the system. See above mentioned three reasons.
- Difficulty keeping the APIs updated. Reason: poor API configuration & maintenance.
However, if you follow service-oriented architecture best practices, that should significantly mitigate the risk of you running into the above-specified problems.
ObjectStyle’s legacy modernization case study
ObjectStyle has a lot of experience with redesigning monolithic applications by converting them into microservices.
During one of the projects we did for a client, a big enterprise organization, we rewrote a monolithic legacy app as a group of individual services, while creating an efficient service-oriented architecture.
The Problem
When the client first partnered with ObjectStyle, their digital infrastructure consisted of heterogeneous software solutions patchworked into a single platform (running on top of IBM Lotus Notes – a popular “spreadsheet platform” of the early 2000’s). The platform had been created over a long period of time. Hence, it had a lot of legacy code, which was causing compatibility and scalability issues.
The client wanted to gradually port different parts of the legacy platform, module by module, into a new environment, upon which they could build and innovate. Each piece of functionality was to become a separate web application (essentially, a module within the “umbrella” of services) that would be relatively independent. This way, if the client decided to replace, remove, or add an app in the future, they could do it with minimum consequences to the infrastructure.
The Solution
It’s important to note that the transformation did not occur overnight. We gradually “chipped away” at the monolith, until we converted selected apps to microservices. One can single out two main phases in this process:
During phase two, we introduced orchestration, because the system was becoming too complex to manage.
The Result
Eventually, all necessary apps were ported into the new infrastructure. In this infrastructure, each application serves its own purpose. They do not overlap, and data is transferred between the services with the help of an extract-transform-load (ETL) solution, which we purpose-built for this project in cooperation with the client.
The new system consists of interconnected microservices and has many advantages over the old legacy platform.
| Before (the monolith) | After (microservices) |
|---|---|
| Each app had its own UI (user interface). | All apps have a uniform look-and-feel. |
| Each new layer was making the monolith more complex. | You can add, remove, or scale microservices quickly and easily. |
| Each app had its own IAM (ID and Access Management) system. | All apps use one IAM system. No sensitive data is stored in apps. |
| Integrations were handled differently for each app, which was insecure. | Thanks to orchestration, app relationships are handled in a centralized/uniform way. |
In conclusion
Rewriting an old app as microservices is considered one of the solutions for software modernization. At the same time, it is not a silver bullet. There are a number of pitfalls associated specifically with microservices, mostly around DevOps.
If you use best practices for building service-oriented software architectures and get help from a knowledgeable partner, you can successfully redesign your old system and future-proof your IT assets.
Related Blogs
How to write a request for proposal (RFP) for IT vendors
Read Article
7 red flags to watch out for in a potential software vendor
Read Article
