Docker vs binary packages

The other day I had a conversation with a Operations Engineer who made a bold statement: "Sending us a docker container is not different from sending us a .deb package"
I do not agree with that statement at all but didn't have the time to counter it, so instead I will write this blog post.

So what really is the difference between a deb package and a docker container?
Just a sidenote that .deb is just one example of a binary package, rpms and packages for other linux systems, could be another example. And I suppose the Windows term would be a msi package.

Well let me first quote our ops guy a bit more, he further said that if we need to monitor CPU usage for one application, we can just setup a vm for that application.

So the first thing to notice is that a docker container is not the same as a vm..
There are many differences between vms and docker containers, and I won't get into them all in this blogpost.
But one major difference is that a docker container is simply running on your computer (which is probably a vm by the way). And since it is running on your computer it does not have the overhead of a hypervisor and an operating system. These are pretty big overheads.
Furthermore a docker container does not really care which computer/vm it is running on, as long as it has a kernel that supports all the stuff it needs (such as cgroups, namespaces etc.)
This means that you are free to move your docker container around as you please and as you have resources available. This means you can use a container orchestration tool like AWS ECS or kubernetes, and hence use the resources on your servers more efficiently.
Hosting in a container orchestration also means that hosting a java or python app is basically the same, since your are 'just' shipping a container. Having big consistency on all your hosted applications means that hosting a new type of thing (be it language or external application) is not a big thing, since all it needs is a container, some configuration and some ports to expose.
It also means that the docker container is self containing (see a container is self containing) so all the configuration drift you get from long running vms should be gone.
Furthermore a docker container does not care if it is running on a developers computer, a test server or production - it just needs the correct configuration.
And since it is self containing it does not contaminate the computer on which it is running.
So a docker container will not have problems with applications wanting different dependencies (like java 7 and 8 or python 2 or 3), because everything is inside the container (<-- it is self containing).
If you start a docker container it will be fetched from the image repository and started. When you stop and delete the container and the image, it will be completely gone from the computer not leaving stuff behind that will mess up dependencies in the future.

There are many more differences, but these are just a few I choose to emphasize.