Containerization in mainstream IT - Part 1

How this can work: A container starts with a single process that is spawned in its own private namespace. Guess what else runs as a single process? KVM virtual machines. If a container won't do, you can run an entire VM as a container. I'm picturing an end state where I log onto my data center management console and I see a collection of containers. Most of them are just those ultra-lightweight containers with a few processes. Some of them are KVM containers running Linux or even Windows.

I want to manage them all exactly like VMs. When I go to the Microsoft website, I want to be able to download Microsoft SQL Server and install it on an OS; or I can download the Microsoft SQL Server container image. Once I hit that critical mass, more and more applications should be available as container downloads and my virtualization footprint will slowly change from 'applications on an OS' to just 'applications,' The look and feel will be the same.

Until someone makes the move toward IT-centric manageability, as opposed to coder-centric features, containerization will be limited to the larger institutions willing to make the investment. It can be worth it. I've seen some fairly small customers who nevertheless need to host 1,000 databases for various clients, and it's well worth their time to understand how to containerize a database. As stated previously, it's not really changing anything, it's just streamlining operations. Conceptually, it's still virtualization, but you can start and stop your databases instantly, clone them, back them up, and restore them. Upgrades are easier - you detach data from your Oracle 19.3 container and reattach it to Oracle 19.8. You have to invest in someone who really understands Kubernetes and writing those configuration files, but once you get past that it's very much IT as usual.

I know that containerization can deliver all these wonderful capabilities. Why hasn't it completely taken over IT? The answer is manageability.