Three Things to Consider When Thinking About Containers

Containers like Docker and Rocket are getting more popular every day. In my conversations with customers, they consistently ask what containers are and how they can use them in their environment. If you’re as curious as most people, read on. . .

How did this happen?

From what I understand, containers grew out of Google’s (and others’) need for massive horizontal scale. Now, this is hardly a unique problem. At the time there were several different solutions out there that could help deploy and orchestrate the applications and infrastructure necessary to scale — namely virtual machines (VMs) and their orchestration services (like Vmware’s vCenter). At the uber-massive scale that companies like Google were pushing, however, server virtualization had some serious drawbacks. Enter containers. . .

What is a container?

Essentially, the main difference between a container and a virtual machine is the amount of overhead involved in each unit.

A virtual machine is literally the components of an entire server, minus the physical hardware. Simplified, it’s the operating system and all additional components required to run the application. That’s a great way to separate applications for mobility, but it also requires a large amount of redundancy (and overhead).

A container is your application and all of its dependencies that run on top of the operating system, but not the operating system (OS) itself. The OS kernel is shared among all the containers on the system. This approach reduces the CPU, memory and disk overhead that virtual machines introduce by running a separate OS instance on every VM. At single system scale, this is not much of a consideration. But when you are talking about scale in the millions, it can lead to an incredible amount of savings without much of a reduction in functionality.

When you get down to the key differences, it essentially amounts to “at what level the hypervisor runs,” or if that’s too technical, the level at which the two technologies provide abstraction from their underlying components (take a look at the image below). For VMs, it abstracts the hardware from the OS. For containers, it abstracts the OS from the applications that interface with it. This is where the benefit comes from: containers allow applications to have isolation without requiring every application to have an additional copy of the operating system. Operating systems take up a great deal of a computer’s resources, so the ability to share that overhead — while getting isolation — can be extremely efficient. Google reported that they spin up roughly two billion containers per week. At that type of scale, you can see the necessity for efficiency!


Image courtesy of

How do I decide between VMs and containers?

This is the million dollar question. Currently, the two are often used together. If you’re running containers on an AWS EC2 instance, then you are running containers inside a VM. However, the are important differences to note:


Security = VMs

Whenever you are consolidating resource, regardless of whether it’s with VMs or containers, security should be top of mind. This is because the process that controls access to resources presents a single, high-value target for attack. If you can compromise that process, you can potentially gain control of all resources that are using it. Scary, right?


Cost reduction = Containers

As I said before, you can use both. However, containers have great potential to reduce the number of physical servers you rely on or your spend in any cloud environment. Especially now that there are orchestration solutions like Kubernetes and Swarm to help you manage your environment.

The only other thing that you should consider before deciding what to put in a container is the next point. . .


Performance = Depends

If you have services (applications) that have very spiky workloads or require a great deal of resources, you have to make very careful decisions about what services you pair together. This is true of both VMs and containers. The reason being that there are a finite amount of resources on the physical machine that is supporting the services. The closer that machine gets to 100%, the slower it responds to the service, and the slower your application runs.

The wrap up . . .

The container space is still maturing. There are sure to be many exciting announcements to come. One thing is certain: this isn’t a fad! While you don’t have to go and start “containerizing” everything in your environment, I would suggest that you start conversations regarding where they’re a good fit in your environment. After all, someone much smarter than I said “you’re either planning for success or failure. The only difference is deliberation.”


Share this post

Comments (2)

  • Darrell Breeden

    I think you’re over simplifying the concept of security in containers for the sake of this argument. Docker can be secured via TLS such that clients require a valid certificate to even access it. If you do that and disable socket level access, the only way to access the swarm cluster or host would be via a valid, signed certificate.

    Also, there are way more pros when it comes to security from containerization dealing with segregated networks, not having to expose ports for services due to container links and more. CGroups can also be defined to mitigate noisy neighbor syndrome.

    On top of that, most patches or security flaws could be fixed by simply rebuilding your image since they’ll normally include package update and install operations. I want to make sure people have all the information available on this subject before some upper level exec decides not to use containers since they saw that “VMs are better for security” on a post somewhere.

    October 21, 2016 at 6:00 pm
  • Jon Tobin

    You make a valid point about the ability for your configuration to limit access to your containers. It’s obvious that you have a high degree of expertise in systems and that can help make containers more secure. Please don’t misunderstand my intentions here. It is not to discourage anyone from the use of containers, but to have an honest discussion about it. To that point, thank you for taking the time to leave a thoughtful comment! This type of discourse makes us all better.

    Now, let me make a simple point about my perspective on the topic. Everything you’ve said is also true of VMs, and in most cases, doubly true. Furthermore, the main reason for my high level recommendation on VMs for security is the amount of DEFAULT isolation bare-metal virtualization provides; to quote the ITWorld article from below “containers do not contain.” If used in the same manner as containers, then there would be a much, much lower attack surface (like for like). Furthermore, the need perform a high level of customization and configuration to get a secure container only increases the likelihood that a mistake will be made. Based on the conversations I’ve had with Executives, this is a paramount concern. Efficiency is great, but security is mandatory.

    All this being said, if someone would like to learn more about the subject, here are a few good articles:
    ITWorld Article:

    October 24, 2016 at 10:35 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.