On today’s episode of things they didn’t teach us during our CS degrees: Docker
I can’t speak for every compsci program, but I can tell you that docker or even the concept of it, wasn’t mentioned once in my 4 years of computer science undergrad. And so of course on the very first day of my Software Engineering internship, I was required to use Docker. Although it’s primarily used in Software Engineering, I think it’s important for every compsci student planning to enter the tech work force to at least have a basic understanding of how docker works.
Luckily, it’s not too difficult to understand…
Before we get into Docker, it’s important to understand the concept of containers. This concept was created years and years ago as a standardized and efficient way to save space while transporting things on a boat. In software, the same idea applies: a container is a standardized unit of software. These ‘containers’ are light-weight, standalone packages, that include everything needed to run an application.
So, it makes sense how real life containers on a ship are helpful, but how do software containers benefit us? The answer is: ‘virtualization’
So what is virtualization?
- Bare-Metal Servers: Let’s start with a typical Bare-metal server. Which this structure, we have essentially 4 levels. Starting from the top we have: Applications, Libraries, Operating System, and the Server Hardware. This structure has no virtualization and is extremely inefficient for a multitude of reasons. First, the hardware costs are going to be the same for 0% utilization, or 100% utilization. And applications A, B, and C are constantly fighting for the same resources. Additionally, with this structure, the libraries must constantly all be in sync with the same versions for all the apps.
- Virtual Machines: To overcome some of these issues, we bring in a virtualization platform, and create a Virtual Machine. With this structure, we can increase the agility and utilization of our system by isolating applications with their own libraries and their own operating systems (OS). This reduces the physical hardware footprint, and solves several issues from the previous approach. However, this solution still isn’t perfect. Due to having separate libraries and OS’s per application, this results in more patching and more updates, thus more space is being used. Furthermore as you can see in the diagram, there is also quite a lot of redundancy.
- Containers: So let’s enter the world of containers. Containers provide better utilization of the underlying hardware, they are lightweight, efficient, and fast. Additionally, they can share libraries when needed, or have isolated libraries. And probably the most important concept: the runtime of these containers share the OS’s kernel, enabling you to create container images using file system layers. These container images are key to Docker.
To create an Image, we package applications their dependencies into single, immutable artifacts (the image). These images give us the ability to run different application versions with different dependencies simultaneously and provide faster development and deployment cycles.
You can think if images as the templates for containers. They are essentially a blueprint with all the instructions needed to create a container. This is where Docker comes in.
Docker is a service that uses these images (docker files ), to ‘spin-up’ and instance of the desired container. With this approach, each of these applications acts as an individual component. Multiple components can then work with each other and communicate via API operations.
The benefits of this are enormous. By isolating these components, individual parts of your overall service can be updated, deployed, and scaled independently. Additionally, this structure is designed to handle failure. If one component fails, it doesn’t affect the functionality of the others. And a new replacement instance can be easy spun-up extremely fast.
I hope this gives you a better understanding of Docker, and the concept of containers!
