As a Technical Account Manager, or TAM for short, I am fortunate to work with some large clients. Most all of them are in some state of increasing their usage of containerization. There are a number of reasons for this, but let’s explore a few of the biggest reasons.
Why Containers?
Almost everyone has deployed Virtual Machines (VMs) for years. Certainly, the benefits of virtualization are obvious, but what about containers? I still hear the phrase “Databases do not belong in containers!” quite often, but is it valid? That is hard to say and likely falls back to the quintessential statement of “It depends…” Containers, as you likely know, is a more lightweight implementation of virtualization than VMs.
Containers provide multi-tenancy application options on physical hosts and are especially useful for implementing immutable applications that can be deployed and destroyed at will. They can be run in isolation of other services with packaged libraries and dependencies, all in one container. In a nutshell, containers virtualize the host operating system whereas traditional VMs virtualize the hardware.
Another huge benefit of containerization is in automation. Containers make it easy to deploy containerized databases that are pre-configured and ready for use. Then, when the packaged container is no longer needed, it can be easily destroyed. No mess, no fuss!
Need to work with lower environments but want to push changes up through to production? No problem. Containers allow you to automate deployment in a consistent manner and ensure there are no differences between environments. Add to this the fact that you can incorporate a CI/CD (Continuous Integration/Continuous Delivery) pipeline into the process and you have a home run!
Using Containers with Cloud Providers
Compatibility with multiple cloud providers is another bonus. When enterprise leadership wants to migrate from one cloud provider to another, or even wants to move to or from on-premises cloud hosting, it is hard to beat containers. Containers are portable and can be moved as needed. This avoids vendor lock-in.
Scalability is also a huge reason I hear from clients. The ability to scale up or scale down is critical, especially given the rapidly evolving situation the world is currently facing and its ever-changing demands on information technology. Containers, paired with automation, make it easy to deploy additional servers as demand increases and then scale back down once it subsides.
Cost is another major factor. Since containers can share infrastructure, there are often substantial cost savings to be had with them versus VMs.
As to why many companies are not all-in yet with containers, there are few reasons that I have heard. One thing mentioned often is performance, especially in the networking stack. This is something that is improving with time but can be a potential bottleneck in heavy applications. Depending upon which components of your application are deployed within the container, and whether the container has to do a lot of communication outside itself, this may or may not be an issue. Again, the “It depends…” mantra applies.
Security, due to a lack of isolation, is another concern as multiple containers most likely are deployed on a particular host. If the host machine is breached, the containers are in jeopardy of being breached as well.
Moreover, since containers on a physical host must share the same Operating System, there is a lack of flexibility in choosing a different OS. For those administering the OS, this could well be considered a perk since there will be fewer installations of the OS to manage.
Performance tuning is another concern I often hear, but that is the same with VMs. The problem of multi-tenancy on a physical host is a challenge to performance tuning for either approach of virtualization. Unless you have the luxury of physical machines, you will face the dilemma either way.
Probably one of the biggest hurdles for containerization is resistance to progress. Many are simply resistant to change. It is new and therefore scares a lot of people.
With all of the above said, I lean towards the conservative end of the spectrum. I think containers are fantastic for deployment to Dev, QA, Staging, and other non-production environments. Although I am not at all opposed to deployment in Production (and work with large scale enterprises already doing so), I do think that caution is still warranted and as always, you should thoroughly test all deployments before they go into production with workloads simulating expected production levels.
Still not convinced databases should be in containers? I doubt you will have the luxury to avoid them much longer. As the technology advances, container usage is on the rise and nothing I have seen suggests otherwise!
