What is a Container?
1.1. So let's get started, what is a container?​
A container is, in simple terms, the bundling of an application together with its dependencies, which share the operating system kernel of the host, that is, the machine (virtual or physical) where it is running. Got it?
Containers are quite similar to virtual machines, but lighter and more integrated with the host machine's operating system, since, as we mentioned, they share its kernel, which provides better performance due to unified resource management.
In most cases, a container image is quite lean, containing only what's necessary for the application to run, which, when executing, has a small overhead compared to the same application running natively on the operating system, largely due to resource sharing with the host machine.
When we use virtual machines, we emulate a new operating system and virtualize all its hardware using more resources from the host machine, which doesn't happen when we use containers, because resources are shared. The obvious advantage is the ability to run more containers on a single host, compared to the quantity achievable with virtual machines.
In the following figure, we can see the differences when we have applications running natively, on virtual machines, and finally in containers. Notice that it's not necessary to emulate a new operating system when using containers, unlike virtual machines.
Another interesting point about using containers is portability. It doesn't matter in which environment you created your container, it will run on any other that has, in our case, Docker installed, whether on Linux, MacOS, or Windows. You don't need to worry about dependencies, everything is inside the container. :D
A developer can, on their own machine, create an application in a container and then run it on a production server without any dependency issues or anything like that -- not even the good old "funny, it works on my machine" excuse applies here!
Remember: in a virtual machine you emulate a new operating system inside the host operating system. In a container, you emulate only the applications and their dependencies, making it portable.
1.2. And when did this all start without me noticing?​
Although the term has become hype in recent years, for decades we've been using containers in Unix systems through the chroot command. Yes, much more simplistic, it's true, as it was just a way to isolate the filesystem, but it was already the beginning!
Then came FreeBSD jails, which, in addition to filesystem isolation, also allowed process isolation, closely followed by Sun, which developed Solaris Zones, another container-based solution, but only for Solaris systems.
The big step toward the scenario we have today was the creation by Parallels of Virtuozzo, a panel that allowed easy container management and the release of the Virtuozzo core as open source under the name OpenVZ.
OpenVZ was a tool that gained significant prominence in container management and greatly helped popularize VPS (Virtual Private Server) and, consequently, the creation of hundreds of hosting companies around the world. The main downside of OpenVZ was the need to apply a patch to the Linux kernel.
Shortly after OpenVZ emerged, Google began developing CGroups for the Linux kernel and started using containers in its datacenters.
In 2008, developers from companies like Virtuozzo, IBM, and Google itself started the LXC project, which brought together CGroups, namespaces, and chroot to provide a complete and stable solution for creating and managing containers.
However, it was in 2013 that containers conquered the mainstream, emerged from the underground through massive adoption by internet companies and tech giants, and invaded the main technology events around the world, with talks about the success in using containers and better utilization of physical resources like CPU and memory, greater agility in deployment of new applications in fractions of seconds, and all of this with an ease that impresses. Friend, we're talking about the simply sensational Docker.