Introduction to Containers

All backend or web developers probably hear the terms “Docker” and “containers” quite frequently. What do these terms mean? Before we get into what Docker is, let's try to understand containerization.

Containerization

So what do we mean by containerization? To understand that, let's first look into why it's needed in the first place.

What did we do before containerization?

Before containerization, in order to run an application on a machine, we had to make sure the machine had all the necessary software. This meant installing the language that the program uses along with all dependencies.

As you can guess, this was a cumbersome process. Apps would fail on some systems and not others because of a missing configuration, and debugging was a nightmare. Autoscaling and running multiple instances of an app exacerbated this problem further. Virtualization, i.e., using virtual machines (VMs), helped to some extent but still required manual setup.

The software world needed a uniform, quick, and easy way to deploy applications that would scale seamlessly. And this led to the creation of containerization.

What is containerization?

Containerization is the process of packaging the source code of the app along with all its dependencies, configuration files, and libraries into a neat little “container.” We can think of a this as the app running in isolation but sharing the same OS as other containers. Let's dive deep into it to get a better understanding.

Anatomy of containerization

As we can see in the diagram above, unlike virtualization, all the containers running on a host share the same OS kernel. This inevitably means that each application running on a host should be compatible with its OS.

Containerization is achieved through container engine software, like Docker Engine. This engine creates containers, which build and run an executable that encompasses the application source code along with its dependencies. The container engine is also responsible for sharing and managing the underlying OS resources efficiently, giving the illusion that the apps are running in isolation with their own copies of the OS.

What are the advantages?

Some of the major advantages of containerization are:

• Portability: Containers don't depend on the underlying OS and can pretty much run the same app on any of them. This makes the app highly portable and allows it to run on all kinds of platforms.

• Scalability: Since the containers run in isolation, we can actually run multiple containers on the same host machine. And since everything about the app is neatly packaged into one entity, it's easier to create new machine instances and run the app on them without much manual intervention.

• Security: The containers are not allowed to communicate with each other or any other machine unless explicitly configured to do so. This provides a layer of security to the app.

• Ease of deployment: Since the process of deploying and running an app in a container is limited to a few simple commands, the deployment process becomes super easy. It also facilitates automating this by simply including it as a stage in the CI/CD pipeline.

• Speed: Since the containers use the host machine OS, they are more efficient and have a very low boot-up time.

How do we achieve containerization?

There are many softwares available today to containerize our applications, like CoreOS rkt and Mesos Containerizer, but the most popular one is Docker.

Let's see how it works.

Containerizing software

We've already discussed container engines in an earlier section. They are pieces of software, mostly open source, and are responsible for managing the OS resources in the container running on the host.

These engines usually have a CLI and API endpoints that can be used to instruct them to perform certain actions, like creating a Docker image, deploying a container and running it, and tweaking configurations.

Orchestration

While most container engines do provide a user interface to manage the containers, it's prudent to delegate this operational task. This is especially true if the app has a very large scale or there are multiple services in the ecosystem, like in a microservices architecture.

That's where the orchestration software comes into the picture. It allows us to efficiently manage the lifecycle of a very high number of containers spread across multiple hosts and ecosystems. Let's look at some of the popular ones.

Kubernetes

Kubernetes also provides much better scaling and security than its peers, along with complex features like fault tolerance, automatic scaling, and self-healing. Due to this, it's quickly becoming the de facto choice of most companies in the industry.

Docker Swarm

Although not as feature rich as Kubernetes, Docker Swarm is low latency and lightweight and could be the right choice for apps that are straightforward and don't need features like automated scaling and out-of-the-box service discovery.

So what's the catch?

While containerization has some advantages, saying it's always the right choice would be not be correct.

Let's look at the downsides of using containers:

• May be slower: Since running containers requires more resources than simply running the application, applications run with containers may be a little slower than if they were run directly.

• Not persistent: Any data generated inside the container, like logs, is lost once that container is destroyed. There are ways of getting them onto the host machine and saving them, but it's still an added backup and recovery effort.

• Lack of seamless support for GUI: Containers were made keeping server applications in mind and don't offer the best support for graphical interfaces.

• Lack of cross-platform support: Images generated for one kind of platform can't be run on another. So an image created for Windows won't run on Linux. Docker has some cross-platform support for multiplatform images, but it's not ideal.

So should we Dockerize our apps?

That's the big question! If the apps are built keeping the tenets of microservices architecture in mind and are intended to be operated at a large scale, then containerizing would be beneficial. It's the same if the app is a server or a CLI. But if GUI is involved, it will probably do more harm than good.

The best approach is to understand what you are trying to build and then see where the advantages of containerization fit in.