When it comes to legacy applications, “to containerize or not to containerize” – that is the question!

When it comes to legacy applications, “to containerize or not to containerize” – that is the question!

It is no secret that containers have entered mainstream and are here to stay. Every IT organization is exploring the use of containers. It is easy to make the case for using containers for new applications, especially the ones designed with a microservices style architecture. The benefits of containerizing microservices applications are immediate and well understood. But what about the hundreds or sometimes thousands of applications that enterprise IT teams are already supporting. Shouldn’t they get some ‘container’ love? Can ‘containerizing’ these applications ‘modernize’ them, extending their useful life? If your applications are running fine, does it even make sense to bother containerizing them all?

Well, the answer is: it depends!

In the next few sections I will discuss when it makes sense to containerize your legacy applications and present a simple framework to help make that decision.

For the purpose of this discussion, let’s assume that the applications under consideration are Linux based and that they will be actively used for at least next three years. If the useful life of an application is less than three years, the ROI will be less compelling so the effort to containerize may not be worth it. Perhaps the same framework could be applied to Windows applications when Windows containers are ready for prime time, probably in next 6-12 months.

Broadly speaking, there are two types of applications that IT teams manage:

  • Custom Developed Applications – these are applications that are built by the development team. e.g. supply chain application, inventory tracking application etc.
  • Third Party Applications or Commercial Off The Shelf (COTS) Applications – these applications purchased by the IT team from a vendor or these could be open source applications e.g. SugarCRM, WordPress etc.

Consider containerizing Custom Developed Applications:

  • With complex configurations
  • That are time-consuming to deploy
  • That have manual or semi-automated environment configurations
  • That can benefit from portability
  • That can be transformed from monoliths to stateless, microservices-style applications

Consider containerizing Third Party Applications (COTS):

  • That are mission critical
  • That can benefit from DevOps best practices and automation
  • That are consuming expensive resources
  • That require manual maintenance  and updates

Before creating a decision making framework, let’s recap key benefits of using containers:

  • Agility – Containers are fast to build and deploy! With the right automation, containers make it possible to deploy applications in seconds.
  • Portability – Containers enable application portability across platforms as well as clouds.
  • Consistency – Container images are immutable and can be used and across environments, eliminating “drift”.
  • Control – You can control what runs in the container, what services the container uses, and where each container runs.
  • Efficiency – Containers provide several options to manage, track, and control resource usage by an application.

Before spending any effort on containerizing your application, it is necessary to evaluate if you will be able to take advantage of one or more benefits listed above. Below is a simple framework that can help you make that decision.

Answering the questions above will lead you to your decision – to containerize or not to containerize! If you agree, the next step would be to figure out how..

I hope this post was useful and answered some questions you may have related to containerizing traditional applications. If you want to learn more about when and how to containerize traditional applications, download our ebook: Containerizing Traditional Applications.

Managing containers at scale!
Checklist for Selecting an Enterprise-Grade Container Management Solution
1 Comment

Post a Comment