Containerisation in the enterprise - Persistent Systems: The 'spectrum' of legacy containerisation
As businesses continue to modernise their server estate and move towards cloud-native architectures, the elephant in the room is the monolithic core business application that cannot easily be rehosted without significant risk and disruption.
These days, it is more efficient to deploy an application in a container than use a virtual machine. Computer Weekly now examines the modern trends, dynamics and challenges faced by organisations now migrating to the micro-engineered world of software containerisation.
As all good software architects know, a container is defined as a ‘logical’ computing environment where code is engineered to allow a guest application to run in a state where it is abstracted away from the underlying host system’s hardware and software infrastructure resources.
So, what do enterprises need to think about when it comes to architecting, developing, deploying and maintaining software containers?
This post is written by Jiani Zhang in her role as president of the Alliance and Industrial Business Unit at Persistent Systems — a Pune (India) and Santa Clara headquartered company that describes itself as a specialist in digital business acceleration, enterprise modernization and next-generation product engineering.
Zhang writes as follows…
A common concern about containers is that they can have trouble syncing with legacy applications that don’t naturally support API connections. While a cloud-native application can be easily containerised from the get-go, legacy applications often require significant augmentation to adopt the run-as-a-container concept.
This can sound like a daunting prospect, but only when you look at it in its totality. If you break down these augmentations into their component pieces, you arrive at a spectrum of necessary changes. Some applications might require only a few, slight modifications to the legacy code. You might even be able to package the application as-is into one or several containers. Others, however, might require entirely refactoring the application so that it runs as if it were cloud-native, which can be a technically complex and time-consuming process.
Jiani Zhang: She knows code, connectivity and containers.
Here’s a breakdown of the spectrum and how it can help you prioritise what applications you should shift to the cloud via containers and in what order.
The quick wins of rehosting
Focus here first.
Look to apply the simplest containerisation technique possible to get quick wins early. Rehosting, otherwise known as the lift-and-shift method, is the easiest way to containerise your legacy application and move it to the cloud. Rehosting can dramatically increase ROI in just a short amount of time.
Not all applications can be rehosted, but the earlier you start, the longer you can enjoy the benefits while you spend time on the more difficult tasks.
You don’t have to refactor everything
Refactoring is certainly more time-consuming than rehosting, but by isolating individual pieces of legacy applications into containerised microservices, you can get the benefits of moving the most important aspects of the application without having to refactor the entire codebase.
From a time and effort standpoint, it often makes sense to only move the most important components, rather than the entire application.
One practical example of this is by refactoring a legacy application’s storage mechanism such as the logs or user files. This will allow you to run the application in the container without losing any data, but also without moving everything into the container.
Understand when to rebuild
Finally, sometimes you have to cut your losses and rebuild an application that has passed its shelf life.
Though this is time-consuming, these are often the most expensive and least productive applications running on your system, and the work can pay off in the long run.
A spectrum of choice
By breaking the containerisation process into manageable pieces sorted out by complexity, you can begin to prioritise quick wins and create a longer-term strategy for time-consuming rebuilds.
Sometimes you have to move quickly in a lift and shift, but sometimes refactoring certain elements of a legacy application can future-proof it much more efficiently without requiring an entirely new codebase. Weigh the benefits and risks of each approach to determine the right containerisation strategy for you.
