How to Get Started With Containerization

As part of my job, I regularly meet with DevOps people to discuss their container strategy. Most of the time, the people I talk to are eager to reap the many benefits containers offer, but they are new to working with them. They might have a container-based system or two on-premises or in the cloud, but no clear strategy.

Given how truly disruptive containers are, it’s easy to get excited and want to go all in. But I encourage people to clearly define their short and long-term objectives and build the runway needed to acclimate themselves to containers and the culture that surrounds them.

The main reasons DevOps teams want to start using containers are the following.

1. Speed Up Application Development and Deployment

Containers are lean, light, and fast — you can easily start developing containers using ready made boilerplate images, based on popular open-source projects. Once ready, you can package your work as a container image, ship it, and run in production environment exactly the same way you did in your development environment. If you add automation to the process, like CI/CD tools, then things can even get faster.

2. Move Applications to the Cloud

Another incredibly useful trait of containers is their portability. Containerizing an application abstracts it from the host operating system and the physical infrastructure. The same container can run on-premise or in the cloud (private or public) without the need to convert deployment formats or change a line of code.

3. Transition to Microservices

Each container is usually single-purpose, single-process, which aligns nicely with microservices architectures. Organizations are looking for better ways to develop and maintain their applications, moving away from big monolithic applications that are hard to maintain into microservices applications that are easier to develop and upgrade. Containers are the perfect platform for microservices, and the ecosystem that has sprung up around them enables even the largest organizations to scale a microservices strategy.

There are plenty of benefits with containerizing your applications — but the question is, where to start? Should you take your legacy monolithic application and refactor it into modern microservices containers, or maybe you should just containerize the “new stuff?”

Well, what about starting with another approach? Containerize an existing legacy application without refactoring it into microservices. When containerizing a legacy, monolithic application not built for containers, you lose some of the benefits that microservices apps have to offer — especially the ease of maintenance and update options, but there are still many benefits to consider.

Containerizing an app enables you to introduce containers into the environment and you can familiarize your team with them while structuring teams and establishing processes that will optimize their transition to a microservices-based approach.

At the end of the day, you’ll want to have one pipeline and toolchain — using containers, which can be used to package new microservices and manage legacy applications. This way, you can normalize all the processes around containers, even you’re running legacy monolithic apps within the containers. The beauty of this approach is that you can start bolting microservices onto the existing application so that any new functionality is microservices-based.

One hybrid approach that’s been generating a bit of buzz recently is a use case known in DevOps parlance as lift and shift. "Lift and shift" refers to the process of containerizing an on-premises, monolithic application to lift it (usually from an old data center) and shift it somewhere else (usually into a modern public or private cloud).

However, as one DockerCon attendee noted, lift and shift can and should be more than just a transport mechanism. It provides the underpinnings to transition to a microservices model and introduces containers into the environment in a manageable way. That’s why it’s quickly become a popular approach for familiarizing DevOps teams with containers. But even when used to deliver a more limited set of benefits, it might be a quick win for those wanting to show tangible forward motion on a container strategy.

If your goal is to rearchitect a legacy app using containers, a complete rewrite into microservices is a big step. There are many intermediate steps such as refactoring the app into several larger chunks — “macroservices,” if you will. It will also provide some benefits and allow you to gradually delve into true microservices.

As DevOps teams decide what to containerize first and why they might want to consider forging relationships with outside stakeholders that can help support further innovation. Given the name of my blog is “DevSecOps,” it should come as no surprise that I support putting security teams first on that list, as they have the potential to be an extremely strategic, useful partner to DevOps.  

Whatever barriers that may exist between security and DevOps (some of which I covered in my previous post), the collaborative spirit of DevOps can be a powerful lure to security folks. Not only can the security group be a strong ally, they might have insights into security/IT risk considerations that can strengthen a DevOps-driven business justification for containerizing a particular app.

At the end of the day, as common as the “rebuild or containerize the existing app?” dilemma is, there’s no one-size-fits-all solution. That’s why quick wins are so important — so whatever you decide to do, plan well, and create realistic success criteria.