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!
Keywords
Assuming you are only used to zip deployments, let’s start with some keywords used in this post that are specific to containerized applications:
Image
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.
Container
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:
- A container orchestrator that can be installed on any machine, like k3s or Docker Desktop.
- A cloud product such as:
- Azure Web Apps For containers
- Azure Container Instances
- Azure Container Apps
- Azure Kubernetes Service
- or other solutions provided by other cloud vendors
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
Conclusion
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.
Cheers!
Subscribe to our RSS feed