Moving beyond the virtualization tool with DevOps containers

Containerization as a concept, and Docker in particular, has received a great deal of attention in the virtualization tools and cloud computing space recently, yet the promise of this lightweight, highly portable technology has yet to be proven to the larger enterprise user base. But proponents of DevOps containers are definitely excited about the potential. This might be the next step beyond the VM. At the very least, it could make the VM less of a virtual monster to wrestle with when it comes to resource management.

According to Arun Gupta, Java Champion and VP of Developer Advocacy at Couchbase, containerization could almost be viewed as a different kind of virtualization. "You can set up a big VM and on that you can run a few processes. Yet that doesn't cover how you package those processes, isolate those dependencies, and so on. The gaps were being filled with configuration management tools like Salt, Chef, Puppet, and Ansible that help to create provisioning scripts. But how do you set up the OS, and what about libraries and dependencies? That was still undetermined." Docker attempts to answer those questions, filling in the blanks with a Linux based solution.

PODA: The new WORA

With Docker’s run anywhere approach, the solution is baked in from development through testing, staging, and production.

Arun Gupta, Java Champion

If Java was Write Once, Run Anywhere, Docker is Package Once, Deploy Anywhere. Gupta explained that the portability is baked in. "You've got this standard Docker image and you can run it wherever you want. The Docker engine understands the image and runs it." Instead of spinning up an entire VM, a process which can take some time, various functions can be spun up in a fraction of a second in tiny containers that share the host OS and enjoy virtually the same speed as bare metal. Modularity and isolation inherent to the container model offer additional benefits for speedy and reliable app performance in today's cloud environments.

The containerization movement is of particular interest in that it meshes well with the current push toward microservices architecture. GitLab CEO Sid Sijbrandij pointed out that, once a new idea in this space catches on and begins to prove its value in the development community, it can move fast. "There is a microservices revolution happening. People are splitting up more and more applications into microservices. You can argue whether that's a good thing or a bad thing, but the fact is that it's happening."

It would certainly be simplest for enterprises to start their experimentation with containers in a microservices-oriented architecture. The idea of a self-contained mini-application is the underlying concept of the microservice, and it is easy to insert one into a Docker container for deployment. This may be how containers finally start making inroads into big business in sectors that are traditionally resistant to change.

At this time, most enterprises are not embracing containers with the same alacrity as microservices. Time will tell whether the trend will take off or fizzle. Security and resource management are current concerns, yet both of these issues can be addressed with time, ingenuity, and sufficient resources. They aren't inherent to the container, and third party tools and solutions are already emerging to address known shortcomings.

Arun held out hope for a significant shift once the container movement starts to pick up steam. "I see this as a significant disruption to the market. But it will take some time to blow people's minds. More attention is being paid to containers in development than production right now."

Container for DevOps

Containerization has the potential to improve the DevOps process by relieving pressure on Ops while making it easier for Dev to simplify the overall workflow. According to Gupta, "It actually reduces the disconnect between development and staging. Right now, you may have something that works on a laptop but fails in Ops. It's not uncommon for Development to say, 'That's not my problem. Ops has to fix it.' But with Docker's run anywhere approach, the solution is baked in from development through testing, staging, and production."

Developers who familiarize themselves with containers have the opportunity to reuse and refactor code from one project to the next, easing their own workload as well. Version control provides good visibility into how containers change over time and makes it simple to roll back to previous stable versions if issues arise. With the thriving Docker development community, programmers can also make use of substantial repositories and share their knowledge with others.

On the Operations side, it's true that system engineers aren't necessarily sold yet. Puppet and Chef can provision scripts as needed in the moment. But who really wants to handle infrastructure and packaging manually when these tasks can be eliminated?

Containers are designed to reduce these labor intensive aspects of maintenance and ensure all application dependencies are met every time with no extra effort required. With Operations being asked to manage application portfolios across multiple cloud environments, containerization may turn out to be the rainbow in the cloud.

Has containerization changed the way you do DevOps? Let us know.