Containers and Docker – What are they anyway?
Starting with the development community, the terms Mircoservices, Containers and Dockers are spilling through the IT world. We try to provide an understandable, abstract overview for IT management. Reading time 10 minutes.
When we speak of the three terms above, we find ourselves in the domain of software development. The central motivation behind these three words is to make software development more efficient and flexible.
But let’s start from scratch: If you see an entire application as a sum of small code packages that have a predefined sub-function, we call that a Mircoservice. In that way, a modern application is not so much a giant code block but much rather the orchestrator of its microservices.
Imagine that the development units of a car factory did not focus on the development of a complete car, but instead only designed components of the car; such as gearshift and brakes.
These modules could be reused in new models, saving time and dev costs.
These microservices are then packed into a container, either alone or in a group. As the name suggests containers form a self-contained IT ecosystem which guarantees the service’s executability in all environmens.
Let’s have a look at the following metaphor: The picturesque harbour hotel “Dock 12” has several rooms, but only provides a bathroom and a kitchen. The guests, however, are mixed bunch ranging from international, posh bankers to rough sailors. These guests do not only have different demands, there is also little interest in sharing the same bathroom.
Now let’s get back to our microservices: They also need their own bathroom and kitchen and are not eager to share. The services require different libraries and a certain framework, e. g. a certain Ruby on Rails version, to run flawlessly.
Containers solve this issue. We provide a container for each mircoservice including the specific libraries and frameworks necessary to execute the service. That is to say, every guest gets a bathroom and a kitchen according to their needs.
The more microservices we have, the more confusing it gets and thus harder for the developer to align the services with the bigger picture. This is where the management tool Docker comes in. With Docker, application developers can quickly organize and execute their container fleet.
As a final metaphor, you may think of the harbor crane, installed in walking distance from the hotel “Dock 12”. The supervisor has the various shipping containers he requires loaded onto the waiting cargo ship.
At the top level we have the application that uses the containers and the services stored in them.
The technical corner
The technology-side of things
Enough with the comparisons. How does the actual deployment of containers with Docker work? There are three central components: the Docker Host, the Docker Client and the Docker Registry.
The Docker Host is the runtime environment in which the containers are executed. The user can create, execute and schedule containers using the client. In addition, the client allows you to define a network for containers and set up persistent storage. The latter is necessary because the storage of a container is ephemeral and is released when the lifecycle of the container ends. In order to store data in the long term, it is necessary to make use of permanent volumes.
With the help of the last components, the Docker Registry, you can create a library for images. Using the client images stored in the library can be mounted in a container environment or, conversely, you can save a snapshot of an existing container to use as necessary.
Containers and VMs
A frequently asked question is the difference between containers and VMs. Both seem to be based on the same idea: abstracting the software regardless of the hardware and thereby enabling several users to share physical ressources.
But there is a striking difference: while VMs running on the same hypervisor have their own OS, the containers share an operating system. Only the libraries and frameworks are different. This leads to two advantages: Firstly, the provision of containers is faster than that of VMs, and secondly – and this is part of why containers exist in the first place – containers are more space-saving. While it would not be efficient to provide a complete operating system to run a single application, a container may very well be deployed.
So let’s sum it up again: Mircoservices perform sub-tasks of an application and can be packed into containers and run independently of the environment. Docker in turn manages and orchestrates the containers. Above it all is the actual application.