Let’s face it. Organizations struggle with their legacy applications. Even when they still solve some of the business’ problems, they reach a point where they can no longer keep up with market and industry demands.
Even when they were smartly designed and well-built, they were often implemented as monolithic systems. Eventually, applications created by different departments or obtained through M&A aren’t communicating with each other, and are often implemented using different technologies stacks.
They are hard to update and grow – each small change requires thorough full application retest. Pushing new functionality into production also requires a full redeployment, which has to be well planned in advance and usually requires some downtime. Considering the disconnected nature of those apps, each new requirement has to be implemented in several apps, which substantially increases the level of effort and risk.
Operationally, it sounds like a headache. And then there are the cost considerations. So it’s understandable that you might decide it’s not worth the hassle. But don’t make that mistake.
Many organizations see a full rewrite as the only way to get rid of legacy systems, however, those are risky and costly projects that not every organization can afford. On the other side, your business needs new functionalities today, not years from now when all the apps will be implemented from scratch.
We know this because, in our experience, we’ve met these seemingly impossible challenges for our clients while saving them time and money. We utilized a different approach that allows modernizing legacy apps without rewriting them from scratch.
It’s not free, and it requires a significant level of effort – but it’s worth it.
In contrast to the “full rewrite” method, this distinctive approach uses the iterative improvements method – where every iteration immediately creates some measurable benefits. So, think of it as a rather large scale refactoring than a rewrite. And while this refactoring takes place, new functionality can be added to the applications. There are several key parts to this approach:
- Split your apps into microservices. This allows you to reuse functionality across applications, even if implemented in different languages and to modify and redeploy pieces separately from each other reducing risk of breaking something else. Don’t overdo it though. There’s no need to split your apps into thousands of microservices right away.
- Approach breaking your apps to microservices iteratively. Start from something that is easy to separate and reuse across other apps. That will allow you to go through the whole process, test your delivery pipeline, demonstrate that this approach works, and make your team feel more comfortable. Continue the process prioritizing separation of components based on risks, value delivered by this separation, and new functionality backlog.
- Use Docker containers. Containers are the most efficient way to deploy and run your microservices. They will also help you prepare for a proper DevOps implementation and with that an efficient rapid delivery. And with today’s technology, you can wrap any Linux or Windows software into a Docker in minutes.
- Use a DevOps-enabled hosting environment. Cluster management software, like Kubernetes, will sufficiently reduce the level of effort required to deploy and maintain your applications. Out-of-the-box, they provide a rich set of capabilities helping to keep your apps up and running, even when you redeploy a new version of them. Additionally, they will allow moving your load between data centers and clouds, if and when required.
- Establish a proper DevOps process. Use Continuous Delivery software like Spinnaker and Jenkins to automate your deployment and maintenance processes. Leverage automatic tests for non-UI pieces as you split your apps to microservices more. This will sufficiently reduce risks associated with pushing a new version to production and with that allow more often release cycles, probably several times a day, as Netflix and Uber do.
As I said, it requires some effort, but the ends justify the means. And don't think you have to eliminate your legacy systems to increase efficiency and performance. However, don’t just jump into new stacks or apps without doing an internal/external discovery, or at the very least a feasibility study. With a little homework and less hassle than you expected, you can get your systems up to date without leaving their parts behind.