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!
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.”