What is containerisation and what’s so great about it anyway? You may work with container-based applications every day at work, but there comes a time when an intern or a fresh graduate new joiner (or perhaps a non-IT colleague) in your team ask you these questions and you find yourself stopped in your track thinking: “where should I start?”.
This article presents the two key points about containerisation you need to know by heart:
- Isolation of Process
and how other benefits can be derived from these points.
Start with the background story
Every great story starts with the introduction of a primary conflict. First, you should start with what happens in a traditional deployment activity. Software applications commonly have dependencies on other libraries, configuration files, or services on the runtime environment.
In a traditional set-up, these application dependencies are installed as part of the host. The downside of this set-up is that the deployed application’s dependencies are highly connected with the host operating system (OS). For example, changes on the host OS such as updates and patches may break the deployed application.
Such a situation is normally overcome by running a full set of tests to ensure that the OS updates and patches do not affect the application’s stability. Additionally, when this process happens, the application deployed on a traditional set-up is stopped while the dependencies are being updated. This causes downtime for the application.
Furthermore, such activities are frequent operations activities as a part of maintaining the host’s OS. The cumbersome nature of such traditional operational activities implies a high cost of engineers’ time and capacity since engineers cannot easily predict the environment stability of traditionally deployed applications.
Enter Containerisation: The Isolation of Process
The first main concept of containerisation you need to keep in mind is the isolation of the process. Containerisation technology redesigned the way of packaging and deploying an application that solves the aforementioned issues. In the containerisation concept, all the dependencies of an application are packaged together with the application (in a container). Hence, the application and its dependencies are decoupled from the host OS. This concept allows the following advantages:
1. A quicker deployment activity
As previously mentioned, traditional deployment requires a heavy work of dependencies installation on the host. The isolation of all the dependencies in a container means that engineers are released from the work of installing the dependencies in the host. For a container-based application, all the application’s dependencies are pre-defined as a code in yaml files and deployed together with the application. (Read also the following topics: deployment, configmaps/secrets, and volumes)
Additionally, traditional deployment might also require a full OS restart, even for a simple update. This is a downside, as it means stopping services on the host OS. With containerisation, a new creation of an (application) container does not require stopping any other services on the host OS. (Read also the following topics: Best practices for creating dockerfiles: Create (ephemeral) containers, Twelve-factor app: Processes)
2. More predictable deployment activity (and more control of deployment)
One other benefit that’s rarely talked about when talking about containerisation is that it provides a more predictable deployment activity. The aforementioned benefit of having a container-based application implies that engineers are released from the cumbersome nature of a traditional deployment activity. This activity normally creates unpredictability which takes a lot of engineers’ time. With containerisation, engineers can focus more on important works and can plan their deployment activity better.
Moreover, containerisation also provides engineers more control of the deployment environment. Because containerisation requires a definition of the desired state of the deployment environment as a code (yaml files), it enables engineers to debug. Additionally, it also enables engineers to record and track the changes of the resource files (version control). Therefore, containerisation also contributes to higher IT engineers’ productivity.
There’s a saying that consistency is the key to success, this also applies when talking about containerisation. The main concept of isolation of processes allows another important key point of containerisation: the consistent nature of the container-based application deployment. The consistent nature of a container-based application deployment enables:
1. Multiple environment deployments
Because the application is packaged together with all its dependencies, it guarantees a consistent deployment, no matter where the environment is (and no matter what the host operating system is!). It means engineers can be more productive, as they spend less time on debugging and diagnosing differences in different environments. Engineers can also make assumptions in the Dev and Test environments that the same situation can be expected in the Production environment.
Containerisation also offers the ability to create templates for your deployment and resource files. This is highly beneficial because it means engineers can reuse the templates across different deployments, thus creating consistency of deployment.
In conclusion, this article describes the two key points of containerisation you need to know by heart: isolation of process and consistency. These two key points are useful to remember, especially when you need to describe it to the layman.
This is because the many benefits of containerisation can be derived from these two key points. The article also tries to highlight the benefits of containerisation that does not only imply technical advantage, but it also implies more efficient and productive engineers work.
Finally, I hope this article can help you explain the next time someone asks “What is containerisation and what’s so great about it anyway?”.
Level up your reading game by joining Hacker Noon now!