Containers: Deploy with Ease

In our latest Writer's Room blog - articles created by Andela Community members - Michael Mekuleyi shares his thoughts in "a short article with a couple of puns about containers and why you should use them!"

Every time I see a picture of Spongebob, I always remember containers!

I'm sure you have heard of containers one way or the other, either when you were listening to the devops guys talk about shipping software, or maybe you even wrote the container file yourself. Or, maybe, you're just involved in shipping goods via the sea.

A container is a piece of software that lets you package code and its dependencies, so your application runs smoothly and quickly across different environments.

Google has been using container technology since 2004, and engineers at Google confirm that Google starts an approximate 3000 containers per second (2 billion per week) to run its many services. Containers are deployed in containers that are run by other containers to ensure your software works and is properly deployed. Let's take a dive!

Containers Run the World

Every piece of software you deploy is either run in Virtual Machines or in Containers. Containers are the backbone of a lot of software deployed in production, and in day-to-day use. Whether you are running a fully managed service or you are handling auto-healing and scaling by yourself, containers are always involved in the build because if you are not deploying with a container, then your build process most likely involves a container.

Why Containers?

Containers allow you to package your software and all its dependencies in one ready-to-go deploy file. They make for a great way to ensure that what works on your laptop, works on the laptop of your Technical Product Manager or on a remote server. What containers actually do is set up a stationary build of your software and deploy that software as it is with a managed package.

Before containers, if you wanted to share a stationary build of software with your Engineering manager, or a technical product manager, you would have to set up a virtual machine, port your code to that virtual machine, build software on that virtual machine, and then spread the static image across to anyone would need that build. The obvious problem with this was version control, the stress of maintaining builds, and then God help you, there was an error in the codebase you shared earlier.

Containers nowadays make it easy for you to ship software (without handing out many images that you cannot track), update software remotely and iterate quickly. Containers built with the docker run time can support versioning with DockerHub, this meaning that you can easily share, update and delete containers with humans or an engineering resource e.g a remote server.

As with code and infrastructure, the security of your containers is your responsibility. Anyone that gets access to your containers, gets access to the code available on those containers and subsequently secrets used in building that container. So it is best practice to keep your containers private and restrict access.

Containers are Heavy

Containers are generally known to be heavy and a little compute-intensive, but to understand why containers are compute-intensive, you must understand what runs underneath the hood. The core reason containers are heavy is the size of their base images. When a container runs, it mimics the features of that operating system and tries to build its dependencies, this means that it is computing actual OS code and wrapping it in a binder before going ahead to build your software.

The container runtime is downloading OS code, computing the build, running it, then computing your software. This takes time and a reasonable amount of computing resources, however with the growth of computing hardware and the increased speed of internet access building containers have become easier and easier. Trust me this uses fewer computing resources than building a virtual machine.

You can also use multi-stage builds to drastically decrease the size of your containers and the amount of time your containers take to run.

Container Runtimes

There are many types of container runtimes, below are the ones I advise you use

• Docker
• dOCKer
• DockER

How to use containers

Containers not only run web applications, but they can also be used to serve databases, batch one-time operations, or streaming operations. I even used docker to build a machine-learning application last year!

Want to be part of a vibrant tech community?

Then join the Andela Talent Network!

Find Work

If you found this blog useful, check out our other blog posts for more essential insights!