What Are Containers?
Learn about containers, and the difference between containers and virtual machines.
When you hear the term “containers,” what comes to mind? Packaging, right? Either for items traveling through the sea or gathering items in your homes or office. So, when the containers are mentioned in the context of the software development world, the purpose is still the same, but now for a different reason.
Why use containers in software development
Containers are software units that package code and dependencies to enable applications to run efficiently and fast in various computing environments. Before containers were used or came into existence, applications were built in a monolithic pattern. The features and functionalities of the application were shared on the same interface, from the frontend and backend to the database.
Here are the challenges developers usually faced when working with monolithic applications:
Deployment: With a large codebase, deploying new functionalities was an issue within the application.
Scaling: Improving the application’s strength with more users was inefficient due to its structure.
Testing: Carrying out unit testing was time consuming, considering a large codebase.
Debugging: Deploying a large codebase was challenging with monoliths and more difficult when there was a bug to fix; and redeploying the entire application just for it.
How containers solved the monolith issues
We’ve seen the issues of deploying or running an application without containers. Now, let’s take a look at the benefits of running applications on containers:
Portability: Containers create packages that are easily executable and not tied to an operating system, enabling them to efficiently run across multiple environments.
Decoupling issues: Various containers for a single application can operate isolated from others, meaning that the failure of one container doesn’t affect the operation of other containers.
Ease of management for application: With containers, we have what we call container orchestration. This enables installation, scaling, and managing of workloads on the containers, also providing monitoring and quickly carrying out debugging issues.
Security: With applications isolated by the function of containers, it’s difficult for hackers to attack the whole codebase, unlike when everything is hosted in the same environment.
Speed and efficiency: Containers are considered light or paperweight (when the application has been packed within). This enables servers to perform efficiently.
Containers and microservices
Containers and microservices are a cloud-native architectural approach to deploying loosely coupled and independent applications into minor services. Unlike a monolithic model that has its whole application, and database on the same platform, microservices have their application split into various services, deployed with containers. These services communicate amongst themselves with APIs. With the birth of containerization came the ease of deploying microservices.
With microservices, there’s less likelihood of having issues with an arm of an application that’s deployed in a container breaking the whole application. Microservices are then deployed and scaled in containers with a container orchestration tool that we’ll discuss later in the course, Kubernetes.
Containers and virtual machines
Containers and virtual machines are known to be similar, but they function differently. We’ll be highlighting their differences below:
Containers | Virtual Machines |
They virtualize the operating system and can handle more applications with fewer operating systems and virtual machines. | They virtualize the hardware and require the aid of hypervisors to run multiple virtual machines. |
They make an application layer that packages code and their dependencies together. | They are a generalization of physical hardware modifying from one server to many servers. |
They take up less space because many container images are in megabytes and are more portable and efficient. | They take up so much space, as much as gigabytes which makes them slow to boot. |
Below is a pictorial illustration of the difference between containerized application architecture and virtual machines.
Components of containers
We’ve discussed much on containers and the benefits they offer. Next, we’ll take a look at what makes up containers—engine and orchestration.
Engine
When we consider engines within containers, there’s only one term that comes to mind, and that’s Docker. While Docker is most known in this area, we still have others like rkt from Cent Os and OCI containerd (which are container runtime). The container engine is responsible for running the process regarding our application on various environments (servers) in which our application would be running.
It’s also good to note that there’s a difference between container engine, container image, and container runtime:
Container engine is responsible for the running process.
Container image is the script in which the application will run.
Container runtime manages the container’s lifecycle on the virtual machine.
The container runtime is also responsible for creating, starting, and stopping containers, and handles network enablement within the container, pulling container images, and mounting storage.
Orchestration
Container orchestration engines are tools that work with our container and Docker images to deploy, host, and scale our application. They run our containers in servers (known as nodes) that carry the application’s workload.
The orchestrator determines the task to be performed and ensures it’s performed optimally based on node availability and health.
There are many orchestration tools like Docker Swarm, Mesos, and Kubernetes but we’ll focus more on Kubernetes because it’s the most popular, preferable, and largely used container orchestration engine in the software development community.