all Technical posts

5 Key Reasons to Containerize Your Applications

Containerization is becoming more and more important for those working in the cloud. Many of us are familiar with zip deployments for applications, but what is the added value in moving towards a containerized way of working? We'll cover this in today's blog.

One of the first questions you might ask yourself when starting on a containerized application is “Why should I go through all of that extra effort to just let my application run? We could equally be doing a normal *.zip deployment.”

In this blog post, I’ll explain why you should do it, and how it’s not as disruptive as you might think!


Assuming you are only used to zip deployments, let’s start with some keywords used in this post that are specific to containerized applications:


When you build your docker image, you make instructions to run your docker container. In the world of containerization, you are building small VMs, all with their own (but very lightweight) operating systems. There are built-in OS’ that can be used as a base image for your application, and you have base images in every different flavor to match the needs of your application. You can also create your own or extend the ones that are already available.


When your application is running in an environment, it is considered to be a container.

So here are your five reasons:

1. Run Everywhere

When creating a Docker Image, you can use that image on all container orchestrators, such as:

  1. A container orchestrator that can be installed on any machine, like k3s or Docker Desktop.
  2. A cloud product such as:

This makes you flexible enough to run at any location, while you are mostly restricted to Windows with zip files. The first step is to become more cloud-native/cloud agnostic with your developments.

2. Standardization

Docker images have a standardized structure, which makes them consistent and easy to configure.

In *.zip files you only have the contents of your application. How to configure and deploy it can be chosen and because of that, vary depending on the application developer.

In the containerized world it is simple: you only need to specify the environment variables and you are done. The application you provide is a solid piece of software and with minimal configuration, all of your customers can be ready to go.

3. Isolation

When running in your own container, you have control over your dependencies, and you don’t need to worry about other applications’ dependencies on that machine. Unlike zip deployments, running isolated gives you the benefit of the operator being able to run your application in seconds, instead of going through a whole set of installations/configurations on the VM. As an application developer, you’ll also have more confidence that your application will actually run in the customer’s environment. So it’s a win-win-win!

4. Security

When running everything on machines, you might be concerned about the fact that other people could watch with you. This can be on IaaS or any *aaS for that manner. But when you run your application containerized, you as an application only have access to what you have inside your container by design! This means that others can also only see inside their container. This automatically gives you a more secure context to work in.

As you are in full control of your application, you are also in control of the base image. Therefore you have the opportunity to immediately react to base image vulnerabilities or breaches.

5. Distributed via a centralized location

When you pass on your application to your customers, you no longer have control over what is happening with your code. With containers, you expose your application via ‘container registries’. This is a centralized location where you keep control over your code. When there are new versions of your app, you can make them available on the container registry and deprecate older versions. You can set up an authentication mechanism to define who can access this container repository and who can’t. This all contributes to a more controlled, safer & more mature product. All things zip deployments cannot provide!

Containerized applications are built from the ground-up, based on the base image. So you can rely on these (public) container registries to fetch the latest & best base image for your application too.

There are two big players we tend to use for our base images: DockerHub & Microsoft Artifact Registry


As you see, there are many reasons why you should consider deployments via containers over zip deployments!

The maturity of the containerization concept is already very high and more than ready to run in your production environment.

Plus, as a tip: always try to use Linux base-imaged containers! These provide you with maximum flexibility.


Subscribe to our RSS feed

Thanks, we've sent the link to your inbox

Invalid email address


Your download should start shortly!

Stay in Touch - Subscribe to Our Newsletter

Keep up to date with industry trends, events and the latest customer stories

Invalid email address


Great you’re on the list!