Docker manages something called containers. In order for us to understand what containers are and when they can be of use in your IT infrastructure, we can take a look at the options a company has to deploy its applications. In a nutshell the 3 options are:
- Physical servers
- Virtual machines
- Containers
We only mention physical servers briefly for completeness.
Physical Servers
Imagine you want to get some products shipped over to you, these products are bananas, monkeys and trucks. You don’t want to put the bananas, monkeys and trucks all together, unstructured, on the boat, since the monkeys could eat the bananas, and in heavy weather the trucks could roll over the monkeys! You could get 3 boats though.
You’d have everything needed to get the products from A to B, but paying for 3 complete boats is a huge waste of resources. You know that all bananas, monkeys and trucks could fit on the same boat, they just need to be isolated from each other.
Of course nobody in their right mind would do that. Unfortunately the same cannot be said when deploying applications. In the past (and probably sometimes still today), applications would get deployed to dedicated physical servers. Since those IT departments had no idea how big/fast the servers had to be, they usually played it safe and got servers that are way too big/fast for their needs, which ended up wasting a lot of resources. Each server had 1 application running on it, since the applications needed to be isolated from each other due to dependency versioning and other conflicts that might occur.
Virtual Machines
A better option would be to put the monkeys, bananas and trucks in a separate storage room. This way they are isolated from each other so that the monkeys can’t eat the bananas and the trucks won’t roll over the monkeys. Sadly, every storage room is also fitted with windows, furniture and a bathroom, things only the monkeys might need. Even worse is, because the storage rooms have so much overhead, the ship only has 2 of them, which means you need to find another ship for your trucks.
Even though this is a better option, you’re still using more storage space than you need. This option can be compared to Virtual Machines. A VM emulates a server, and the main pro is that you can have multiple VM’s run on one server. This way you can have each VM run an application and have several VM’s on one server. A big con though is that a lot of overhead is added, a VM emulates a full blown server, with a complete OS and programs that you might not even need to run your applications.
Docker & containers
Then you think of the obvious choice, why can’t I just have my bananas, monkeys and trucks shipped in separate small shipping containers, fit with only the things each “product” needs? This way I’m only using the space I really need. Nobody on the ship even cares what’s inside the containers, all they care about is the space the container takes. Just like the storage rooms, everything is isolated from each other. Since containers use space much more efficiently, there’s even room for other containers on the ship. If someone wants to put his coconuts in a container, next to mine, that’s fine, my monkeys won’t eat them since they don’t even know that there’s a container full of coconuts standing next to them.
In the IT world this solution is also called a container. A container is a self-contained mini-server that only has the bare minimum amount of software installed on it in order to do its job. Docker is a piece of software that manages these containers. Another good thing about containers is that they’re “lift and shift”-able, this means that you can take your container, run it on any other docker host and it will behave exactly the same. You shouldn’t even care which server it runs on! Since containers only contain the bare metal, they’re also a lot smaller than VM’s. As you can see there are some similarities between containers and VMs, such as isolation and the fact that you don’t use up all the resources of the server for 1 application.
In other areas containers have some distinct advantages over a VM:
- They’re cheaper, since they’re using less resources
- They start faster, containers can usually start in under a second where a VM can take minutes
- They’re “lift and shift”-able, you shouldn’t even care on which server your containers run since they will look, feel and smell exactly the same.
Please note that while the use-cases for containers and VMs overlap, they’re not 100% the same.
Of course you don’t always have to create your containers from the ground up. That’s why there are online repositories. Repositories can be public or private and are the shopping market in the container world, only (almost) everything is free here! If you have an idea for a container, there’s a good chance someone has already put it out there so that all you have to do is download it. Once you’ve downloaded it you can use it you can tweak it if it doesn’t completely fit your needs and then upload and reshare it with the world through the repository. The most popular and “official” repository is Dockerhub, though there are many others out there, such as Google Container Registry, the container registry solution on GCP.
What if you want to have several different containers coordinating between each other? Well, for that you could use Kubernetes, but that’s a story for another time…
If you want to find out more about containers and what they could mean for yourself or your business, feel free to join us at the Google Cloud IaaS event on the 28th of March!
Written by Robin Hellemans
