The benefits of containerization of existing software projects

One of the early stages of working with a new partner is getting their software product ‘containerized’. Many teams have probably heard of Docker by now. Docker is not based on new technology, but their technology became very popular because they made it easy to take existing systems and move everyone from making just virtual servers into more virtual applications. Docker led the way in this new idea of containerization and is now just one of many technologies that support this new methodology.

The containerization is not just about running your application in a virtual server dedicated to that application, but running in a virtual server that only has exactly what is needed to run your application, and no more.

When taking a client’s software into these containers, there are many extra benefits that come out of the process that many don’t think about.

To get an idea of the containerization process, see this blog post by Rob on Dockerizing a Legacy Virtual Machine Such as Clarity LIMS. That is a worst-case scenario but gives an idea of the overall process.

Problem 1: “It Works For Me”

When a development environment is prepared in isolation, and used for many different projects, there can be a lot of cross-contamination. We will often find a situation where a developer has tested the code in his environment, it works just fine. But, when they package it up to go to production, it fails miserably.

This is usually met with “Works for me!”, the common “call to arms” in the old war of Dev vs. Ops. Almost every time, this happens because of a difference between the two environments. This eventually gets tracked down, after considerable effort, to a changed 3rd party library the codebase uses, or a change to some needed support component, a different database version, different language version, and so forth. Sometimes tooling will have upgraded these items, and the developer might not have been aware of the change. It might have happened days, weeks, or months ago depending on how fast the features to production pipeline flows.

Containerization helps with this because it provides a known fixed environment that is the same for production, QA, staging, and the developer. The developer is often not doing the development work inside this container, but he/she has easy quick access to one of these environments. Breaking changes will still happen, but the ability to fail fast allows the changes to be caught early and put into the base containers, instead of days or weeks later when what was done is forgotten.

Couple this with good in-code unit tests, good integration testing, and automation on a CI/CD pipeline, and those breaking changes can be caught in minutes or hours, automatically, without the developer having to go out of his/her way make the test happen.

Problem 2: “Barnacles”

Quite often, the environment where the developers are working, and the environment where the production code run, have become different. Sometimes, the developers working on the product have inherited a large product base as well as development configuration with limited documentation. The production systems might also have been something worked on by others, and also undocumented. Development and Production can be a collection of lore, and long-lost remnants from by-gone development experiments.

These are the barnacles in your system, and just like the ones on ships, they could be slowing down your systems and use up other costly resources. They can also open up your systems on unknown security issues if not maintained, and larger attack surfaces that simply doesn’t need to be there.

With the containerization process, we start with the bare minimum needed to run the type of product that matches your code stack, and then slowly add in the required components to fully run your application as it exists today. Once all the barnacles are removed, we have a better understanding of how your “ship” is built, so we can better help you through all the other parts of your development to production life-cycle.