A Strategy for Container Adoption

“Are you switching to containers?” This question, which boils down to container adoption, is one I have been asked roughly every other week from engineers and other peers who are caught up in the buzz. The answer I often get is that containers don’t fulfill all the requirements of my stack, YET.

So where do they fit within the infrastructure?

The hype of containers is a great example of engineers prematurely assuming one technology would become the one-size fits all. Typical internet debate has tempered the hype of VC funded marketing campaigns, but containers look to pave the way for more efficient and scalable distributed architectures.

For those who haven’t dug into the details; here is a quick recap on containers and VMs and the pros and cons of each.

• Containers are virtualization at the operating system level:
• Containers only load the libraries for the applications they contain so they are light weight.
• Their efficiency translates to reduced costs as you can cram more containers on a server than you could VMs.
• Containers are portable across hardware and operating systems.
• Security is an issue as containers share the kernel with the underlying host so a compromised container effectively means a compromised server.

VMs are virtualization at the hardware level

• VMs are trusted to be secure as the hypervisor has been hardened over the past many years and a VM runs its own kernel, so a compromised VM is much less likely to mean a compromised host.
• Loading a full kernel means additional consumption of system resources relative to containers.
• VMs have all translation take place through the hypervisor to the underlying server and thus are not as fast or efficient as containers.

So what would I do for my infrastructure? Will I migrate everything to containers? My philosophy is simple and considers the cost/benefit analysis; apply the best tool for the job at hand. Ultimately it comes down to the type of workload you expect your infrastructure to handle and there are too many cases to cover here. However, the foundation of your infrastructure can inform your strategy.

VM-based IaaS (AWS)

My stack is on AWS and even with the release of ECS you lose out on any performance gains by running on a VM cluster. Chef and Vagrant, along with other similar technologies, provide sufficient flexibility and consistency in my stack. Isolation is ideal at the instance level for our applications and I can spool each of my microservices in separate appropriately sized instances capable of auto-scaling. No need to worry my services will compete for shared system resources. Many of our microservices are public facing so I can leverage tested methods of securing my environment. Ultimately I don’t need to add the additional layers of abstraction to my environment at this time and switching to containers would not provide sufficient cost-benefit right now .

Container-Based IaaS (Joyent, Google Compute Engine)

No contest, you should be using containers. These services aim to solve security concerns and aim to handle orchestration.

Hybrid Cloud (Cloud + On-Premise)

Consistency between the datacenter and on-premise installation can be achieved with the appropriate orchestration and configuration technologies with either VMs or containers. Containers provide the added benefits of reduced resource requirements relative to VMs and enhanced portability (as long as you don’t bind a required state to the host). Strict oversight and validation of container images will be necessary along with consideration for isolating private and sensitive container services from hosts running public-facing applications. If your cloud infrastructure is VM based you essentially lose performance gains from using containers, but that is a fair tradeoff for the benefits.

Private Data Center

Orchestration with containers is likely the direction you want to look forward to, plan for, and if you have the resources, start a POC. If you have a mature infrastructure comprised of VMs now may not be the time to move and will allow time for the technology to mature.

When adopting containers, take careful consideration of how narrowly you intend to abstract your environment. LXC containers are more akin to VMs in they are designed to contain multiple services in contrast to Docker containers which reduce containers to single processes. Additional abstraction leads to additional complexity and an engineer may find containers to be impressive in the development environment but take careful consideration of how that will scale and need to be supported by your team.

The container community is very active and continue to contribute security improvements and enhanced orchestration methods along with open source projects such as Kubernetes, Docker, LXD, and Centurion. Google, Canonical, Docker, Joyent, Red Hat, VMware, Parallels, and Microsoft have all participated in defining container standards making it clear how much investment is being put into the future of containers.