 From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon North America 2020 virtual brought to you by Red Hat, the CloudNative Computing Foundation and Ecosystem Partners. Hi, and welcome back to theCUBE. I'm Jupp Piskach. I'm covering KubeCon, CloudNativeCon here remotely from the Netherlands. And I'm joined by Commvault Matthew Pearson. He's a senior product manager. As well as David Know, Vice President of Metallic Products and Engineering, to talk about the CloudNative space and data protection in the CloudNative space. So both welcome to the show. And I want to start off with kind of the why question, right? Why are we here, obviously, but also why are we talking about data protection? I thought we had that figured out. So David, can you shed some light on how data protection is totally different in the CloudNative container space? Sure. Absolutely. I think the thing to keep in mind is that containers are an evolution of, and a revolution actually in the virtualization space and the cloud space. What we're seeing is that customers are turning more and more to SaaS-based applications and infrastructure in order to modernize their data centers and their data state and their compute environments. And when they do that, they're looking for solutions that match how they deploy their applications. And SaaS for us is an important area of that space. So Metallic is Commvault's portfolio of SaaS-delivered and SaaS-native data protection capabilities and offerings to allow customers to take the advantage of the best SaaS. It's easy to try, easy to buy, easy to deploy, infrastructure required, and combine that with the technology and experience of Commvault. It'll build over the last 20 years, deliver an enterprise-grade data protection solution, deliver it as SaaS. And so with Kubernetes and deploying in the Cloud and modernizing applications, I think that's very appealing to customers to also be able to modernize their data protection. Yeah, so I get the SaaS part. I mean, SaaS is an important way of delivering services. It is, especially in the mid-market, something customers prefer. They want to have that simplicity, that easy onboarding, as well as the apex of paying a subscription fee instead of longer-term fees. So the delivery model makes sense. That fits into the paradigm of making it simple, getting started easily. I get that, but Metallic isn't a traditional backup solution in that sense. It's not backing up necessarily just physical machines or just virtual machines. It has relevance in the cloud-native space. And the way I understand it, and please, if you can shed some light on that, Matt, how is it different? What does it do that makes it stand apart? Yeah, look, what we've found is the application developer is in control now. So it's not like a traditional backup. That's what's changed. At this point, the application developer is free to create the infrastructure that he or she needs. And that freedom has meant that a bunch of stateful applications, the apps that we didn't think were going to live in Kubernetes, have made their way to Kubernetes, and they're making their way fast. So why is Metallic different? Because it's taking its lead from the developer. So it's using things like namespaces and label selectors to basically take input from the developer on what information is important and needs to be protected, and then protecting it. So it's your easy button to keep that Kubernetes development protected while you keep pace with the innovation within the organization. So you raise a valid point. Cloud-native has many advantages. It also has an extra challenge to account for, which is fragmentation. In the olden days, let's call it that, we had a virtual machine, maybe a couple dozen, that made up an application. And it was fairly easy to pinpoint the circumference of an application. This is my application. But now with Cloud-native, applications' data can basically live anywhere in a single cloud vendor, in many different cloud accounts, across different services, even across the public clouds themselves, like in a true multi-cloud scenario. And figuring out what is part of an application in that enormous fragmentation is a challenge I think is understated and underestimated in a lot of operational environments with customers, with their applications in production. And that's where I think a product needs to figure out how to make sure an application is still back-top, is still protected in the way that is necessary for that given application. So I wonder how that works with Metallic. How do you kind of figure out what part of that enormous fragmentation is part of a single application? Yeah, so Metallic effectively integrates and speaks natively with the Kube API server. So it's taking its lead from the system of truth, which is the orchestrator, which is Kubernetes itself. So, for example, if you say everything in your production namespace needs protection, every night or every four hours, whatever that may be, it steps out and asks Kubernetes what applications exist there. It then maps all of the associated API resources associated with that application including the persistent volumes and persistent volume claims, mounts those up and grabs the data from them as well. And that allows us to then replay or reschedule that application either back to that original cluster or to another one for application mobility or DR. So how do you make sure you... What's the central point where everything comes together for that given application? Is that something the developer does as part of their release process or as part of their CI-CD? How do you figure out what components are part of an application? That is definitely a big challenge in the industry today. So today we use label selectors predominantly. We find developers have been educating us on what works for them. And they've said, our CI-CD system is going to label everything associated with this app, both namespace and non-namespaced resources. So just here, take my label, grab everything under that and you will be good. The reality is that doesn't work for every business. Some businesses drop things into a specific namespace. And then you've got the added challenge that all of your data doesn't actually just live in Kubernetes. What about your image registries? What about its CD? What about your source code control and CI-CD systems? So we're finding that even VMs as well are playing a part in this ecosystem right now until applications can fully migrate. Yeah, and let's zoom out on that a little bit. I mean, I think it's great that developers now kind of have flipped the paradigm where backup and data protection used to be something squarely in the ops domain. It's now made its way into the dev domain where it's become fairly easy to tag resources as application X, application Y. And then it automatically gets pulled into the backup based on policies. I mean, that's great, but let's zoom out a little bit and figure out why is this happening, why are developers even being put in a position of backing up their applications? So David, do you want to shed some light on that for me? Sure, I think data protection is always going to be a requirement. You'll have persistent data, right? There are other elements of applications that will always need to be protected. And data protection is often something that is an afterthought, but it's something that needs to be considered from the beginning. And Metallic, in being able to support deployments not just in the cloud, but on-premises as well, we support any number of certified distributions of Kubernetes, gives you the flexibility to make sure that there was apps and that data is protected. No matter where it lives, being able to do that from a single pan of glass, being able to manage your Kubernetes deployments in different environments is very important there. So let's dive into that a little bit. I hear you say certified Kubernetes distributions. So what's kind of the common denominator we need to use Metallic in an environment? Because I hear on-prem, I hear public cloud. So it seems to me like this is a pretty broad product in terms of what it supports in its scope. But what's the lowest common denominator for instance in the on-prem environment? Sure. So we support all CNCF certified distributions of Kubernetes today. And in the cloud, we support Azure with AKS and AWS with EKS. So you can really use the one Metallic environment, the one interface, to be able to manage all of those environments. And so what about the storage underneath? Is that all through CSI? Yes. So we support CSI on the back end of the Kubernetes applications and we can then protect all the data stored there. And so how does this... I mean, you acquired Hedvig about a year ago, I want to say, but you're on the exact date, you acquired Hedvig a little while ago. So how does that come into play in the Metallic offering? Sure. The Hedvig storage, distributed storage platform is a fantastic platform on which to provision and scale Kubernetes applications and clusters. And that having full integration with Kubernetes on the storage side, we support that natively and really builds on the value that Comma can bring as a whole with all of its offerings as a platform to Kubernetes. All right. So zooming out just a little more, I want to get a feel for the kind of the portfolio of Commvault as we're ushering into this cloud native era, as we're helping customers make that move and make that transition. What's the positioning of Metallic in... Basically in the transformation customers are going through from on-prem to kind of lift and shift cloud into the cloud native space. Yeah. So with today's announcements, our hybrid cloud support and our hybrid cloud initiatives really help customers manage data wherever it lives, as I've mentioned earlier. Customers can start with workloads on-prem and start protecting workloads that they either have migrated or starting to build in the cloud natively and really cover the gamut of infrastructure and hypervisors and file systems and storage locations amongst all of these locations. So from our perspective, we think that hybrid is here to stay. There are very few customers who are either going to be all on-premises or all in the cloud. Most customers have some requirement that keeps them in a hybrid configuration, and we see that being prevalent for quite some time. So supporting customers in their transformation, where they are moving applications from on-premises to the cloud either refactoring or lift and shift or what have you, it's very important to them. It's very important for us to be able to support that motion and we look forward to helping them along the way. Awesome. So one last question for Matt. I mean Metallic is a service, right? That means you run it, you operate it, you build it. So I wonder, is Metallic itself cloud native? How does it scale? What are the big components that Metallic is made up of? So Metallic itself is absolutely cloud native. It is sitting inside Azure today. I won't go into all of the details. In fact, David could probably provide far more detail there, but I think Metallic is cloud native with respect to the fact that it's speaking natively to your applications, your cloud instances, your VMs, and then it's giving you the agility and the ability to move them where you need them to be. And that's assisting people in that migration. So in the past, we helped people get from P to V. Now that they're virtualized, applications like Metallic can protect you wherever you are and get you to wherever you need to be, especially into your next cloud of choice. And there's always another cloud. What I'm interested to see and what I'm hoping to see out of the QtCon is how are we doing with CubeVirt and Kubernetes becoming the orchestrator of the data center? And how are we doing with some of these other projects like application CRDs and hierarchical namespaces that are truly going to build a multi-tenanted software-defined distributed application ecosystem that Metallic can speak natively to via Kubernetes. Awesome. Well, thank you both for being with me today. I certainly learned a ton about Metallic. I learned a lot about the challenges in cloud native that'll certainly be an area of development in the next couple of years as the CNCF will continue to support projects in this space and vendors to work with us in that space as well. So that's it for now. I'm Juppie Skar. I'm covering for CubeCon here remotely from the Netherlands. I will see you next time. Thanks.