It’s safe to say that we’ve reached the point of cloud adoption where no one is asking what containers and Kubernetes are. The ubiquitous nature of these platforms has shifted the conversation away from on-premises data center deployments and firmly entrenched the discussions in public cloud for the foreseeable future. Enterprises that are looking to the cloud are planning for Kubernetes in a big way. Net-new application development and deployment are container-focused. Existing virtual machine (VM) deployments are being refreshed as well but they are also receiving attention as containers allow them to be augmented and extended in new ways.
Moving to Containers
Kubernetes smooths the transition between writing legacy code and creating cloud applications. Instead of worrying about the specifics of how a given environment operates you can just write your application to use Kubernetes and be sure that it will run on any flavor of cloud. This kind of portability makes the decision makers in your organization happy because it means they can move without worrying about anything breaking along the way. Sure, there’s a lot of consider when writing that code but knowing you could redeploy from Cloud A to Cloud G whenever you wanted is a very appealing thought.
Does that mean that containers are the answer to all our infrastructure woes? Does the nature of microservices development mean we can finally do away with protecting the infrastructure stack and just wing it? No doubt you’re already shaking your head in disagreement. No matter how transient and abstracted the layers are we still have important information that needs to be protected. Whether it’s the critical data that our organization creates or relies upon for decisions or the way our infrastructure is created there’s far too many things that can cause problems should they just disappear.
When you look back at the history of Kubernetes adoption you don’t see the all-in mentality of deployment. No enterprise woke up one day and decided to shift everything to containers. Instead, they took a measured approach. They deployed non-critical applications using containers and worked through the bugs. Enterprises are very risk averse and they don’t want to risk going out of business because of a bad bet. IT knowledge workers are also risk averse in the enterprise, since one major issue could lead to them creating a new resume container and deploying it on the job market.
Like any new technology, containers and Kubernetes needed to mature before the enterprise was ready to embrace it. Sure, DevOps loved to deploy things on this new platform. However, the mantra of moving fast and fixing broken things along the way doesn’t resonate with the decision makers. They’re not ready to make the move until they can be sure that this new bet isn’t going to sink the company and their stock price. How can decision makers feel more comfortable about joining exciting new tech to a risk averse mentality?
Commvault Means Protection
When you think of Commvault you think of protection. You probably think of a program that backs up your user data and stores it somewhere safe in case disaster strikes. You may even know them for their new focus on ransomware protection. But do you think of them when you think of Kubernetes? Did you even know they worked with it?
Commvault can back up your Kubernetes workloads. Not only can they protect individual workloads but they can protect your namespaces as well. Maybe you want to protect your production environment without backing up the chaos that exists in your development namespace. Commvault has the tools to make sure only the namespaces you want to protect are taken care of. However, the decision makers are going to tell you that you need to protect everything. Thankfully Commvault allows you to protect the entire cluster all at once. That includes the configurations that allow your containers to be deployed quickly. It’s not enough to just get the data in the container. You’ve got to get the container itself too!
All of this comes in a familiar interface. One of the key negatives about the early days of container deployment was the relative immaturity of the toolset. When you’re breaking new ground you build the tool you need at the time and worry about the rest later. User interface? Who has time for that? Just hack a script together and go! Sadly for the enterprise this perspective doesn’t reassure the decision makers. On the other hand, telling them that the tried-and-true data protection platform that they’ve been using for years also supports backing up that new thing the developers are playing around with? That’s a much better way to approach the executives.
If Kubernetes represents the new frontier of cloud application deployment, Commvault represents the reliable way to keep it all safe. Your decision makers are going to feel much more comfortable making new deployment decisions on Kubernetes knowing they can rely on Commvault to back up as much or as little as they need. The reliability of the platform means assurance that it’s not going to fail because of bad infrastructure protection. That’s the kind of confidence that everyone in your enterprise wants to see.
