General

Code that works everywhere - Containers Explained

Imagine a standardized environment across your macOS developers, Windows developers, your test and production servers. Introducing Containers.

Lim Xing Zhi

04 Oct 2019 — 3 min read

This is the last post I queue. If you are seeing this, that means there wouldn't be new blog posts for a while and I will be concentrating on my studies. And now, about containers.

Imagine a standardized environment across your macOS developers, Windows developers, your test and production servers. Introducing Containers.

I will not dive into the implementation and deployment of containers, this post will serve as a short introduction to explain what containers are.

It works fine on my machine

Let's talk about development teams. If you ever worked in a team with different operating systems, you could understand the pain of working on different platforms. Different environment variables, runtime versions, library and packages, managing it all can be nerve-wracking. As this xkcd comic captures perfectly.

xkcd comic

A solution is to use a Virtual Machine (VM). By having an identical Virtual Machine in each of the developer's physical machine, we could replicate the environment and provide a consistent platform for everyone regardless of their operating system. But running an entire operating system will require tons of computing resources. Thus, it is a good idea to use the host operating system while providing a sandbox on each development environment.

Introducing Containers

A container is a sandbox at your application level. It bundles your source code and all its libraries alongside other containers and applications in your operating system. As compared to Virtual Machines, Containers are significantly smaller since they only contain application code and platform configuration. Containers are much lighter and faster since they do not run an entire virtual operating system.

Not just for developers

I will be using docker as a prime example since it is pretty popular during the Stack Overflow Survey 2019.

Since the entire application is packaged into one single file, testing and deployment teams can pull the single image work on it with minimal configuration. The non-development teams also don't have to fiddle around with VMs to make sure that they are using the correct runtime versions. Deployment is also simpler since it is just a matter of spinning up the correct container with the correct parameters.

Docker has this service called Docker Hub. It is a repository that allows you to pull docker container images and deploy them on your own with minimal configuration.

How to do that: https://docs.docker.com/get-started/

Drawbacks

Once again, referencing to Docker.

In Docker, your data is non-persistent. Meaning when you restart the service or restart the physical machine, all of your data and changes made will disappear unless you use a volume. I don't want to get too deep into volumes, but to use persistent storage, you will have to write your data into a path and that path will be mapped to your physical hard drive.

The deployment stack can be more confusing. In a traditional environment, you just need to deploy a VM for each of your services or run it all on bare metal (on the physical machine). But with containers, it is an additional layer of abstraction to manage. Your entire team from deployment to quality control to development will have to adopt this new strategy and be comfortable with it for it to be successful.

Tl;DR

Containers are good for both developers and non-development IT personnel. As more of us adopt a more micro-systems based architecture, faster deployment times and shorter product sprints will be expected. Let's move towards a faster, more predictable deployment and development workflow.