Recently I finally found some time to catch up on containers and Docker basics and concepts and I glad that I went through some introductory information as with all this hype around containers it is sometimes difficult to wrap your head around basic premise/promise of containers technology. In fact there is even confusion if containers and Docker are the same thing or something that has to be distinguished from each other… 🙂 So I decided to jot down just basic idea of containers technology + a bit of related background info which is helpful for understanding it.
So classic IT services architecture with HW servers has been transformed by arrival of hyper-visors/virtualization technologies (which to many is synonymous with VMware) and containers is next stage of the same transformation/another chapter in the quest for efficient IT service delivery (which to many synonymous wit Docker).
What has been solved by virtualization is gross under-utilization of hardware – by placing multiple VMs we can have good load of existing hardware, higher density and reduced admin overhead thanks related with managing multiple hardware servers. After about fifteen years of evolution this technology produced a lot of extra benefits like live migration and snapshots. At the moment virtualization it is fully mature and production ready technology.
Containers attempts to attach some remaining source of admin overhead and CAPEX/OPEX which survived after we decimated number of HW servers in our environments thanks to virtualization. This is something we used to accept as normal state of things or maybe as necessary evil – we throw away HW servers and run VMs, but each VM requires OS on its own – which means administrative overhead, attack surface, licensing OPEX/CAPEX. Containers architecture tries to eliminate this layer of VMs OSs which solely exist to run applications we need to run. Just look at the conceptual picture of containers architecture and you will see that conceptually it is much more simpler (and in system design simple means better):
Image source: ZDNet
So we use one host OS and next docker engine provides containers which can be fired off much faster as you don’t need to fire off guest OS before your real app can be started – your base OS is already running and container starts somewhat as application. So concept is nice and simple, though any curious IT person would immediately come up with questions about quality of isolation of containers, stability of docker engine and how such architecture survives crash of base OS or docker engine. Is it production ready or not? This is the topic for separate blog post or two and in this one I just wanted to highlight basic promise/concept behind containers.