Databases are what I call "normal people IT." We don't want to edit YAML files or write scripts if we can possibly avoid it, and we care about the practical benefits. The containerization world is missing the mark here. I'm waiting for someone to take the vCenter approach to containerization. I want to buy myself a stack of x86 servers, install Linux or some other container-capable OS on them, and then bring them under management that delivers a vCenter-like experience. I want to look at my console and see start/start containers, change priorities and resources, migrate, clone, etc. I want point-and-click manageability.

That's what we need for virtualization to take the next step and bring containers to everybody. We need manageability. DBAs used to manage "a database on an OS on a server"; then with virtualization it was just "a database on an OS." With containerization, we can give everyone just "a database." That's what my Oracle container management code does. It's just a set of processes. The DBA can even SSH into the container and get the logs, adjust their Oracle configuration files, etc. It's the usual DBA experience, but we've removed everything except the database.
Containers for everyone

Yes, there will be some enterprises with massive, containerized environments that are dynamically reconfiguring themselves, and maybe one of them will gain self-awareness, name itself "Skynet," and start sending Terminators back in time. But that's an edge case The real value of containers is simply making IT better.

Let's take a step back and think of the everyday IT benefits we could achieve:

Instant startup times
More efficient use of hardware
Lighter-weight configuration requirements that are easier to set up
Less chance of user errors, which means more reliability
Simple portability to any x86 platform you like, including to/from the cloud
Simpler application upgrades
Fewer compatibility problems

These benefits apply to everything in IT, including databases. And they answer the DBA who asks "what's in it for me?" We just need to deal with the ease-of-use barrier.

That's where things start to get interesting. We saw the same thing happen with all-flash storage. In the early days, databases didn't need all-flash storage because nobody had developed a business need for all-flash storage because nobody could afford all-flash storage. Once it was available, customers started coming up with all sorts of interesting things to do. For example, why wait for the overnight report on sales trends? How about real-time alerts about changes in buying patterns so you can adjust your online advertising accordingly?

I expect the same thing to happen with containers. For example, if it's easy to move databases back and forth between on premises and clouds, perhaps developers will check entire databases in and out of the cloud for the day. If you need high-speed data access, check it out to your premises. When you're finished, check it back into the cloud. Maybe we'll make more use of cloudbursting, where once a day a single database is cloned 1,000 times for a few hours, some intensive I/O work is done, and then the containers are deleted. Yes, you could do that with VMs, but it's awkward, and the overhead of 1,000 complete kernels and 1,000 OSs is substantial.

Take a vendor like Oracle as an example. They could deliver a complete Oracle database installation via a container and erase all those OS prerequisites, configuration setting requirements, installation processes, etc. That also simplifies their support process because their support center would know precisely how a database is configured. They could even ship their own version of certain OS components in the container that are optimized for their software.
Value of containerization

My main point here is about looking at the value that containerization can deliver. We don't necessarily have to try to predict what customers will do with it. We know the benefits, we just have to make sure that those benefits are as easy to realize as possible and wait to see what the user base decides to do. We're the storage vendor; our job is to make sure that whatever someone does with containerization, our products integrate seamlessly into the plan. We were ahead of the game with the way NetApp® ONTAP® virtualizes storage before anyone ever said the word "Docker" or "Kubernetes." That's how we could bring a product like NetApp Trident to market so quickly to provide persistent, reliable, enterprise-grade container storage.

I'm convinced that containerization will take over eventually. I've been presenting on this topic at our NetApp INSIGHT® conference for 3 years now. I always tell the audience that if there are 3 or 4 people who know Python and can make a GUI, I'll quit my job at NetApp and we'll build that general-purpose container management platform the IT world is looking for. I wasn't kidding. I can live off savings for a couple of years. I'd do it.

If you'd like to see the sorts of practical things you can do with containerization, I've got a demo of simple Oracle database provisioning, backups, and cloning available here, and the presentation includes links to a deep-dive on the code and the github repo where you can get it.

More importantly just remember that containerization isn't just for the mad scientists and massive scale Cloud projects. Think of the everyday IT things you already do now and picture how packaging up those applications in containers could simplify operations. If any of those applications require high-availability, high-performance, enterprise-grade storage, make sure you check out Netapp Trident as well.

Attachments

  • Original document
  • Permalink

Disclaimer

NetApp Inc. published this content on 02 August 2021 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 04 August 2021 08:05:03 UTC.