Grey Beards on Systems - 131: GreyBeards talk native K8s data protection using Veritas NetBackup with Reneé Carlisle

Episode Date: April 12, 2022

The GreyBeards have been discussing K8s storage services a lot over the last year or so and it was time to understand how container apps and data could be protected. Recently, we saw an article about a Veritas funded survey, discussing the need for data protection in K8s. As such, it seemed a good time … Continue reading "131: GreyBeards talk native K8s data protection using Veritas NetBackup with Reneé Carlisle"

Hey everybody, Ray Lucchese here with Keith Townsend. Welcome to another sponsored episode of the Greybeards on Storage podcast, a show where we get Greybeards bloggers together with storage assistant vendors to discuss upcoming products, technologies, and trends affecting the data center today. And now it's my pleasure to introduce Renee Carlisle, Staff Product Manager at NetBackup Veritas. So Renee, why don't you tell us a little bit about yourself and what Veritas is doing to protect Kubernetes data?

Sure, Ray. I've been with Veritas for about 11 years now. Before that, I was a customer working a lot with our virtualization technologies. As part of that, I just started to see about three years ago, this Kubernetes technology and platform really start to pick up and just realized there was a trend there that was going to start accelerating fast. It became a passion project of mine and really started to drive the strategy of NetBackup with Kubernetes. So we started about two, two and a half years ago. We just took an initial step of containerizing our client,

just to start having those conversations with customers, analysts, going to KubeCon, seeing where this was going. And it quickly became apparent that this was going to be the next big thing, if you will. This is going to be something very critical to our customers, right? So about a year ago, we released our first integrative native built from the ground up data center protection for Kubernetes. Really wanted to focus two things that we saw we were struggling with with customers or that they were telling us was a struggle as they were trying to figure this out and go into a enterprise ready application. They wanted something that was Kubernetes native. We realized that transition, you know, back with the virtualization days, you couldn't back up VMs the same way you backed up physical machines, different animal. We saw the same thing with Kubernetes.

Kubernetes is so different from typical VMs. We needed a new way to protect those. It needed to be native, but we didn't want to lose that framework that we had for our other applications, all the advanced capabilities we had, the ease of use for the backup admins to wrap their minds around this new technology. So, you know, so we had to build this from the ground up, but we had to do it in a native Kubernetes way. So we launched our first integration about eight months ago. second integration to take it to the next level to overcome some shortcomings that we saw within native Kubernetes technology. The biggest one of that is Kubernetes doesn't have a native

data mover and we needed to be able to offer that. I mean, ransomware is already starting to hit Kubernetes. Data protection is becoming increasingly important for all of our customers, the industry. Was it ever not important? I mean, how can data protection not be important to customers? You know, it was a couple of years ago when we first started this journey. Kubernetes. Yeah. For Kubernetes with customers. Most of my conversations with customers back then was, hey, this thing's ephemeral. Do we even need to protect it? You know, and that was kind of the early journey of Kubernetes. Right.

I rarely, if ever, have that conversation anymore. Yeah. As people are moving to production, persistent storage is, you know, more important. Yeah. PVC, persistent volumes are becoming the rigor for Kubernetes containers and stuff like that. Well, let's start getting into this stuff. So you mentioned native at least four times here. So what is Kubernetes native?

The client, I understand, because you have to go in and do scanning and stuff like that. But the backup server is running on Kubernetes as containers? We do that as well. That wasn't what I was referring to, but we do have our infrastructure that can run on containers as well. But what I was mainly referring to are things like you can't just stick a net backup client, this big monolithic thing, put it in the infrastructure and say, hey, we have a solution, right? So we had to write something that was native to Kubernetes. So we actually even, our programmers even picked up native Kubernetes programming languages to write it, but we have a custom operator that sits inside of Kubernetes. Our data mover is an elastic data mover specifically

designed for cloud environments that will scale up, scale down as needed. Containerized effectively. Everything goes through the API server for communication. Right. It was really, and we also, the big flip for data protection, I think, is with virtual machines, even with standalone clients, you protect a client or you protect a VM. There's this one-for-one relationship. That's not the same with Kubernetes.

There can be, you know, 50 different components that make up an application. Pods, containers, all that other stuff. Yeah, yeah, yeah. Right. Custom resources, PVs, PVCs. So it was really taking Veritas' DNA of understanding complicated multi-part applications, how to associate all of them, protect them as a single entity, recover them as a single entity. So there was a lot of things that we had to look at differently. So you're saying you can actually protect, let's say I deploy a Kubernetes application across, you know, four or five pods, a cluster with persistent volumes, et

cetera, et cetera, you can not only protect the data, but protect the application itself? Absolutely. And so what we do is we take the entire application, everything that makes up, at its basic form, everything that makes up a namespace, all the persistent volumes, the claims, the metadata, we can protect it all as an entity. Yeah, we'll file the ledger. Yeah. They can tweak that a little bit if they want to.

So with include or exclude or, you know, custom labels, they can even say a namespace isn't exactly right for us. We want to tweak it. We let them do that. And then we protect it all. And then not only can we recover it all back to the same environment we can recover it to a different cluster that cluster can be in a different data center it can even be a different distribution so that was the other big thing about kubernetes is the portability nature yeah we didn't want to get away in the get in the way of the portability aks versus eks or gke whatever and maybe even openShift kind of thing?

Absolutely. It was the first of its kind for net backup. We've always been heterogeneous. I wanted to take it to the next level. So now if a customer wants to backup and say OpenShift and recover it into GKE, they have the full freedom to do that. So any distribution to any distribution. And the backup storage is your standard net backup backup storage anything anywhere any place it is yeah so i have a ton

of questions i think the first question is well before question comment, kind of like, I'm surprised Ray is as surprised that, you know, you can take something from a set of Kubernetes containers from OpenShift and restore them into something like AKS or whatever. I think that was the promise. Yes, it is the promise of Kubernetes. But OpenShift and Kubernetes, OpenShift is a superset of Kubernetes. And we have this problem with virtualization to some extent. We have this problem with other solutions. Now, when you start playing with a superset, you start taking advantage of those functionality. If you're an OpenShift customer and you're playing the pure Kubernetes solution, yeah, fine.

But now you're taking OpenShift applications and moving them to Google Cloud. It's a little different game. So, Renee, are you saying that NetBackup solves that logic problem? Renee? From one platform to another? Because that would be- Yeah, we take all the data. So we could take it within the constraint of a namespace.

So all the metadata and everything that makes up that namespace, we'll grab all that and the persistent volume and the storage. As long as this, the biggest challenge has always been the storage. As long as the storage type is the same. So block to block, you can't go block to files. But as long as we have some consistency in the type of storage, we can take and recover it from one platform to another platform or one distribution to another distribution. So you guys are taking a pure storage perspective of it. needs logic change to take advantage of an OpenShift environment versus an AKS or EKS or an Anthos environment.

You have to account for that in the app migration itself. So if there's a custom call or process or operator that Google has, that AWS doesn't have, that OpenShift has, you have to account for that in the movement of the data. We'll grab all the metadata associated with the namespace itself. Which is pure Kubernetes wherever it runs, right? But if the application uses an API, let's say that's OpenShift specific and you're moving over to Google GKE or something like that, it's not going to work.

It has to change the API. So let's talk about a practical challenge as we take kind of these traditional data protection ideas and concepts that are fundamental to IT operations and combine them with this prevalence of CI, CD pipelines, configuration management tools, state management of applications. And we revert back from one version of the app to, or data, or in this case, app, because now we're not just talking about the data. We're talking about the app itself. How do we do version control and integration

with something like a net backup for containers? So if you were to take, let's say, an application and you wanted to update it, you were in the process of updating and the backup started to take place, and then you decided later, oops, I don't think we want to do that. We want to revert. So what happens to that backup to some extent? Or we just say we want to revert back.

Yeah, because we didn't realize we were making a big mistake. And we choose, instead of using our CICD process, our data. And this happens practically where our data and app are so tightly coupled that it's almost impossible to revert back without reverting back the data. That is a common challenge and impediment to move into containers. How do you guys help with that operation? I think just being able to provide customers with a lot of the flexibility there. So when we grab all the data that makes up that application and you can keep as many copies of that as you want. Like I said, you can store that.

We can either roll back from a quick snapshot or they can store that off to some kind of external storage to further protect from ransomware and take advantage of deduplications and all the optimizations. But when they go to do the recovery, they can tell exactly what was in that backup image down to here's all the metadata we grabbed. And here is the version of every single one of those components.

So before they come back or need to pull something back, if they're in that kind of state, they know exactly what those components are, what versions they are. If they decide that there's some component that's not the right version they need to pull back, they can do more of a granular recovery and say, I don't want that component, or I just want this component, and be able to do more of a precise recovery if they get into those kind of scenarios. So I guess what you're saying is if you're reverting the application and it wasn't dependent on changing the data, then there was no problem. You could all do it through CICD kinds of things. But if you're reverting the application and it did require a different format of the data, let's say, then they would have to go back through their backup list and say, okay, this is the last backup we have of the data in that format, and that's what we need to recover from. So it would be less of a, let's call it

automated reversion, than something that operations would have to get involved in selecting that stuff. Is that how it would play out? Right. Or maybe they just want to recreate the application. They just need their data back so they can recover just the persistent volumes to that new application so they can get just the data. If they want, granularity-wise. We just want the data. We don't even want the persistent volume claims. We don't want anything else. We just want to recover our data back to this new application that's on a new version.

They can do that as well. So lots of flexibility for the granularity and complexities to solve for different use cases. It's almost like, yeah, I will, I will love to talk to a user to talk through how they then get back into their main tree and CICD process. You know, I've reverted back outside of my system, kind of my configuration and CICD chain. I reverted the system. That is a accepted change, kind of the governance around that. And then we kind of pick up day two and we have our CICD process without it breaking. I love to see how customers are solving that practical problem. Yes, we recovered from ransomware, we're back up and

running, but now we're continuing our development chain with this kind of gap in history between the systems of record, which is my net backup is one system of record or versioning. And then I don't, this is where I'm getting to the limit of my knowledge of CICD. But Jenkins or Ansible or whatever my tool is I'm using for CICD and tracking, versioning, et cetera. So the NetBackup, I'm not even sure what the terminology is. Is NetBackup Kubernetes? Is that what you'd call it? I mean, is there a buzzword for this?

Or is it just NetBackup Kubernetes, is that what you'd call it? I mean, is there a buzzword for this? Is there just NetBackup? It's just NetBackup, and Kubernetes is a platform that we protect. We like to tell people they're charting a better course with NetBackup. Okay. So you fully support API solutions? I mean, so you're all in on anything you can do over, let's say, an operator console, you can do via APIs? Absolutely. Everything is RESTful API enabled that comes out. And it also, whether you're through RUI or through RESTful APIs, we have role-based access control for the self-service.

So our users can get down to either a namespace level as the smallest granularity of we only want this user to have access to just this namespace. Oh, that's nice. And here's what we're going to allow them to do. Or they can give them a group of namespaces. Maybe they have, you know, a cluster of things that they are responsible for. So Keith can't control my namespace and I can't control Keith's namespace. And that's this level of granularity and stuff like that. But if it's all API driven, then it's possible that the automation could take advantage of that, go in and look at, let's say, the directory, identify the backups that have the proper

versions of the application slash data and recover those. Absolutely. Yeah, I think what I would do, sounds like it's capable based on this conversation, is just say, I wouldn't make the call from NetBackup directly. I wouldn't say, oh, my data's kind of how we do in the VM world, which, oh, I had a

breach and I need to revert back and I just go to the NetBackup console, select my source target and then version and hit restore. What I would probably do is have that integrated into my CI CD pipeline and say that, oh, I need to revert back to a previous version of the app. And this is just, you know, I continue that pipeline logic to say that this recovery is the next version of my app.

And that's how I think I would do it. Absolutely, Keith. And we really, it depends on some of our customers' environments is who in the organization is responsible for the recovery and what kind of recovery. So the beauty of having the APIs fully enabled can tie into CIZD pipelines. All backups can be driven just by a label.

DevOps teams don't have to ever touch or know about NetBackup in order to be able to provide protection and do recovery. It can be all scripted. They can throw a label on whatever they want to protect, and they're done. Life is good. But we know that in the enterprise world, especially in ransomware, auditing, security, having a centralized process.

And let's face it, I've spent more time educating backup admins on what Kubernetes is than anything else. It can be complicated for them. within their processes, not have to learn another tool, say, oh, I can just create a gold protection plan. And now all my Kubernetes namespaces are just going to automatically be protected. And I don't have to worry about that. It makes it easier for them as well. So we really, I kind of like to describe it as two sides of one coin. So we wanted to be really native for the Kubernetes admin so they could use their own processes, CI, CD pipelines, labels, things they know, not interfere with their Kubernetes environment.

But we needed to give that same level to the backup admin that they didn't have to learn new tools, processes. They could take all the advanced technology and apply it and be comfortable in their space. So being able to achieve both of those within one product was my goal. technology and apply it and be comfortable in their space. So being able to achieve both of those within one product was my goal. And we were able to reach achieve that. In fact, a lot of the analyst reports on this and one of the surveys we did is said a lot of people would love to have one solution to be able to protect their enterprise space, including Kubernetes.

Most people don't know it's out there. So that's one of the things we're trying to tell people is it is out there. We've designed it that way. Right, right. So let's talk a little bit about that nuance, because I really love what you folks have been able to do. And one of the biggest challenges I see is that gap. So unless you have something like a platform group, and the platform group and you know, the platform group has, has morphed over the past few years to mean something very different when with across every organization, but let's generically say this group that writes the,

the, the policies and translates the, the backup, the net back, the traditional net backup admin speak into developer speak and create these profiles, if you don't have that, it's a lot of luck. Missing that gap and backup folks,

even with the transition to VMs, we had this notion of there's an app and this app is connected to a number of VMs. And if I need to restore this app, then these underlying VMs will be restored. To your point, Kubernetes isn't that straightforward always or that simple. I can have a shared microservice, let's say credit card processing that's shared across five different apps. And restoring that one microprocess may break another set of apps. So the backup admin or backup process has to have that intelligence. How is that education process?

Before we go down that path, do you think that there's a single microservice credit card processing that's operating in this pod across five different applications? Or is it more likely that there are five instances of this credit card service running across multiple pods, one pod per each application kind of thing? That's a fair question, Ray, and I think it depends on the organization. If there's a app team or platform team responsible for this infrastructure credit card processing, then it's one version. If it's, hey, here's the credit card processing container or package, pull it down for your app. It all depends on just how it's made. I think it's also changing. That's one of the things I'm trying to really keep an eye on with our customers is Kubernetes is being adopted more rapidly than any platform I've ever seen. As a result, there's still some- Are you listening, Keith? Are you listening, Keith? I'm sorry. Go ahead. So we talked a little bit about this before we hit record, is that my argument is that Kubernetes

and what I've seen in my audience, they love the content and they absorb it more than any other stuff, but the other stuff just isn't going away. Not at the same rate, you know, VMs kind of cannibalize containers. I don't see that happening yet for Kubernetes and monolithic applications.

We're not cannibalizing. Kubernetes is just growing. Right, and I didn't say those were mutually exclusive, right? The adoption of Kubernetes is faster than any trend I've ever seen. But you're right, it doesn't necessarily mean that. It can be a tough transition too. So it doesn't necessarily mean that it's it can be a tough transition, too. So it doesn't mean that all the traditional applications are going away either.

It's just moving fast and they're growing fast and customers are adopting it very rapidly, especially as they're moving towards the cloud. We know the pandemic didn't help people working from home. They're needing to adopt new platforms to absorb that. So I think there's just a lot of things in the world today that has caused Kubernetes to explode faster than anything I've seen before. Transition from this application into Kubernetes, that's a different story. That's a harder shift. But the explosion of Kubernetes is just rapid. So what Keith is... I guess that goes back to the original question

before we kind of get off on the tangent about adoption. How is the traditional net backup admin handling this change of... It's a paradigm shift because they still have the monolithic applications they have to support. And they have this thing that's become incredibly important. Right. Thanks, Keith. I forgot where we were going with that.

I didn't get down that track. Yeah. And that is, I think, one of the things we've seen as far as customers struggle. It's becoming more adopted in production. They're having to deal with this. They don't necessarily, some of the backup admins are just drinking from the fire hose. So I think that's where us being able to provide a ability for them to just bring it into their

known framework. They don't have to have as much education. They don't have to be experts in Kubernetes to now protect it. They can go into their NetBackup UI, create the same protection plans that they've always created. There's something called a namespace kind of thing. Yeah. They don't even really have to know that it's necessarily this namespace. They can just set up, here's my parameters. I want to be able to do a gold, silver, bronze. I want to be able to back something up, a snapshot. And then I want to store it into optimized storage for six months. And this is my framework.

Any new Kubernetes namespace that comes up just automatically starts populating into these frameworks that I've created. And now I have this autonomous data protection. I never have to touch it again. I don't have to know that my DevOps teams are spinning up new namespaces. They just are automatically protected. we provide for other workloads. It was bringing it into the NetBackup framework that allows us to move faster on applying those concepts to Kubernetes as just another platform. So a dev team would say, I'm creating this namespace or this application and in my YAML file, I would say I want data protection equals silver or something like that for this application.

Is that how it would play out? And all of a sudden, silver is there, it's tagged, and it's done whatever the silver protection scheme is. Absolutely. And then when the silver protection plan kicks off next, it goes out and does a discovery and says, tell me anything that's silver.

And all those workloads that are tagged with that automatically get protected based on the framework that the people responsible for how much of our attention, you know, what's our offsite, what's our, you know, how long do we have to keep the data? They can define those frameworks because that's typically a company standard that they're responsible for. So they just define that framework and then anything that shows up just automatically gets protected based on that framework. So from let's take this to like a DR process. If I'm designing DR in a traditional environment, I typically design that VR based on the number of VMs and the amount of data. I can't do that in Kubernetes where I hear what I would do in this environment and say, okay, how much gold versus silver versus platinum policy do I have? And do I have the equivalent capacity in DR to recover this much gold, this much silver,

this much platinum? Is that the approach or a approach? It could be. I haven't seen that as much as customers saying, these are my critical applications. So I need to make sure that I can recover them rapidly with a snapshot. And then I have some retention that I'm responsible. I don't want to keep that on any kind of primary storage. I'm going to put that off to optimize storage and I'm going to keep that for

a year or two years so that I know I can recover from that. But the fact that you're capable of running the application in any Kubernetes environment must lend credence to disaster recovery. So if I've got the infrastructure to run a Kubernetes environment, whether it's in the cloud or on-prem or something like that, and I have access to this secondary storage that these backups exist on, then I can instantiate it, I can recover it, I can bring that application and run it in that environment, I guess. Correct. Yeah, and I guess my challenge is I think through like practical challenges from what I've seen in DR environments, even where we did this hybrid recovery where we could recover into the cloud.

There's a couple of costs and limiting factors that we never consider until we have a DR event or test. One of them, which is super important in this conversation is cost. So capacity may not be an issue. Is there enough compute or storage on the target platform? It's simply, can I afford to run it? So have I oversubscribed in traditional environments? I can oversubscribe the amount of compute and still run and stay within my cost parameters. but in this new environment, I can oversubscribe cost, and now I'm in

trouble in the event. Great key if you're able to recover, but it wasn't as they say. If it's a true disaster, does cost really matter as much? Number one. Number two, those costs that you had for the non- Kubernetes environment, because you had the infrastructure, you understand its constraints, you understand what it costs. I would say you could do something similar from a Kubernetes perspective. Renee, I'll let Renee talk. Yeah, for data protection, it can be slightly different as well, because we're talking about typically our gold, silver prawns for the data protection side, not the orchestrated recovery side would be, hey, I need to keep so many snapshots.

I need to keep so many backup images. I need to keep those, right? What's the retention? Let's optimize the storage. Let's put that on deduplication or on a cloud storage target with optimizations just so that we have the savings there. Veritas even has a scalable appliance for our backups if you want to put it there. Veritas even has a scalable appliance for our backup. So if you want to put

it there and then as your data grows, that would scale out. So it's more, how many copies do I need? How long do I keep those copies? How often am I going to do recoveries? What kind of retention? We can solve for all of that with now backup and that's all automated so they don't have to think about it or worry about that. Yeah, I don't disagree with the concept and the initial thoughts until you get the surprise AWS. That is on paper is great until you realize that I've oversubscribed what I thought my egress charge budget would be.

And I'm not talking about egress from hybrid whatever. I'm talking about when I instantiate the workloads and I'm hitting the data and I didn't design for it. And that's when, and it sounds like you're giving us the parameters to do it as just a thought in which people, architects really need to consider because you can easily outrun your target without, you know, when it's not a fixed. Absolutely.

And you got to think about that anytime you're going into the cloud, right? We make the storage of the backup as cheap as possible by being able to leverage, you know, those longer term cloud storage like Glacier and those kinds of things. We can use that and deduplication and optimizations there so we can save as much as possible in storage. In fact, Veritas even has a recovery vault. So a SaaS based storage that makes it simpler if you just want to use our storage and has all kinds of ransomware detection and anomaly detection and stuff. So we make that as easy and safe and optimized as possible for the customers. The cost, biggest cost usually does come when

you're recovering out of that. So that's where you obviously have to design for that and think about that of how often will I do the recoveries? Where is that? And what's that going to cost me? Absolutely. So somewhere back in this discussion, you mentioned that the current version two of the solution, you added things like data movers. Why did you feel you had to add data movers to the solution? Maybe you could explain a little of that yeah there is there was not a enterprise grade data mover that we felt like our customers were comfortable with what is an enterprise grade data mover mean to you renee so yeah so some of the data movers that are out there like the rustics and

some of the um some of the third-party components didn't scale as much as our customers needed. We protect very, very large environments. We protect the largest environments in the world. We needed to make sure that it would scale. A lot of our customers were even resistant to having to install, manage, upgrade a separate component that wasn't native and included in the solution. Having that ability to scale up and scale down, having deduplication, having data encryption, being able to tie into any net backup storage with all of our ransomware protection with

detection anomaly. We didn't find any of that with going to a third party component and our customers weren't comfortable with that said, we really want this, but we want to be able to know that we can scale it, perform, have protection, have ransomware resiliency, all that. So in a typical configuration, multiple namespaces and that sort of stuff, would you have a data mover per namespace? Is that how you'd see this to be deployed or would be a separate namespace

just for backup data moving services? I'm just trying to understand how this thing works. Sure. So that's where the elasticity comes in, right? So we have our Kubernetes operator that sits within typically best practices and it's a net backup namespace. It doesn't have to be, but that's kind of what we recommend. And then as we need to do data movement for either backup or recovery, we will go out and look and say, how many data movers do we need to spin up to do that backup or recovery? And typically, we'll spin up one data mover for the namespace and one data mover for each of the persistent volumes. And those

data mover pods that we spin up are contained within our namespace. So we're not taking resources from the backup namespace, the namespace that we're protecting. And then as that data movement is done for that persistent volume, for that namespace, then that data mover pod will spin down and go away. But we also have threshold control.

So depending on how many namespaces, how many persistent volumes, that's one thing we've learned in our long history of data protection. You don't want data protection to just run amok amongst the platform. You could take it over if you don't have constraint controls. So we have threshold controls that says, hey, if you have, you know, so many resources that spinning up these data mover pods might impact your operations, you can set a threshold and limit how many data mover pods will spin up and spin down to protect the infrastructure. Yeah, this is super critical. I can't tell you how many times I've seen people make the transition from cloud to read from private data to the cloud where these restraints was inherent to the environment. And you go into an environment like cloud where you don't have those restraints and you haven't calculated. So a process that's completely not value add goes amok and you get us again, the surprise, you know, insert cloud provider

deal here because it wasn't. These are those things when I say the reason why we wanted to build our own and not say go out and buy a startup or, or use our past technology for this is because of being able to take all this history of how do you run extremely large enterprise backup in different platforms. We can take all that history of these advanced capabilities and make sure we bring all of those to Kubernetes as well in the same way. So customers aren't having to learn anything new there. They just expect that those kinds of capabilities are going to come with our product. And we wanted to make sure we delivered that.

Yeah, this is very complimentary to the talk track that I've had for the past probably year, which has been the legacy, quote unquote, stuff isn't going anywhere. And those resources, my most difficult resource to change is my people. And if I can't integrate my data protection strategy in the resources and processes that I have today, then the chances for adoption are slim to none. DBA who to this day refuses to not do a zero backup. And you have to make the agent aware that the DBA is doing something that's probably not a modern activity or action and kind of fake them out and say, yes, I did do a zero backup, but it's just a snapshot. Absolutely. I mean, this is Kubernetes isn't for the faint of heart in a lot of times. So the easier we can make it for customers to be able to use known processes, the more successful.

Okay, we talked about the operator. The easier transition is. The operator, I'll call it application. I have data mover containers, I guess. You mentioned client as well as backup server being native to the solution. Are the clients running in the namespaces? Or again, it's just running in the backup namespace? That was just kind of an initial offering just to kind of get to know what we needed to do. So we don't really use our client anymore. So once we did full native integration with just

deploying a Kubernetes operator, that model just kind of went away, right? So the native integration, we just deploy a Kubernetes operator. So you've got a few of these multi-tier models, right? Multi, you know, three-tier, two-tier kinds of backup solutions. And in the Kubernetes, you're saying that pretty much it's gone away? We still have our media server and our primary server that can be multiple or they can be, you know, all in one. But then our Kubernetes operator, we have one per Kubernetes cluster, so we can scale that communicates back to the primary server and we can use our media server to be able to provide the storage,

communicates with the operator data mover to move all the data. So you can still scale those operations. But that's even morphing and changing. So in our latest release, we also just released our first containerized infrastructure. So NetBackup itself is especially for our customers that are really heavily invested in cloud, they can now deploy NetBackup in a containerized fashion. So we are going through

that conversion of a, the transition ourselves of taking a, you know, on-prem all-in-one, kind of more monolithic application and moving that into a collection of services deployed into a Kubernetes environment. So you're saying that, does that mean the primary server is moving into containers and the media server is moving into containers? Correct. Oh. It is, and we're continuing that evolution

to make it more and more extensible and more and more elastic. And they've become much more scalable because of all this, right? Absolutely. So eventually there is no such thing as a primary server or media servers anymore. It's just a collection of services. And as we need more of one type of service, that will scale up and that will scale down. That's all started in our DNA years ago with our appliances, started using containers within our appliances years ago. And so this is just kind of an evolution next step of that model of just getting more and more containerized to where there won't eventually even be a server anymore. It'll just be a bunch of services.

Yeah, so I love the stories behind these transitions because I have a love telling or asking the anti-Kubernetes stories, which is what if I don't care anything about Kubernetes? Now my ISV is shipping what used to be packaged software that I ran on a VM as a container image. So does that customer start running containers in his environment in order to run that packaged software? He's got to, right? Yeah. Do I need to know anything about Kubernetes to run my backup software? You don't. No.

Nope, you don't. So today, and we're continuing to invest here, but today you could just go out to like the Azure Marketplace, answer a couple of questions about what you need for your environment, and that's all obfuscated for you. You don't have to worry about Kubernetes. You don't have to know Kubernetes. You just tell us what your goals are, what you need, and we will spin the infrastructure up for you. So in that case, you're running the containerized version of your infrastructure.

Correct. Even though it's under the covers. Correct. And we're the first company to be able to provide that. Yeah. So one of the things that as we're making this transition, you can't see me, I'm doing air quotes from VMs to containers. One of the things that people usually skip over is this in-between space. Like we're at the point that a lot of companies have a lot of cloud debt. We've built services on that. I don't know if I would call them a monolithic application. Maybe they're microservices based. They just I'm just not using containers as the building block for my environment. So as we're looking at a platform team or DevOps team that has to support everything from bare metal, and I get that this is somewhat of a softball, from bare metal to VMs to cloud native in the legacy sense to cloud native in the Kubernetes sense, how does NetBackup help me take a holistic view of my large enterprise

that has just been cutting edge for the past 25 years? So there's two ways that we can do it. So we can protect any of those applications, any of those platforms, all with the same tool sets, same UI, same basic framework. So you don't need to learn anything new in order to be able to protect all of those infrastructures from one source. Truly one source. All of those were built from the ground up. So everything will be exactly the same user experience. And then we also, for our infrastructure, can provide NetBackup as an infrastructure in any of those components. So if you need to make a transition and you want to use,

you know, you want to bring your infrastructure on a virtual machine on your on-premises, you can do that. But if you want to put NetBackup into a containerized version for your cloud data center, you could do that as well. So we kind of, both angles are covered as you're making that transition or adoption of new platforms. Yeah. Yeah. I have to ask the question. VMware is Tanzu and that sort of stuff. You guys, do you have support for Tanzu in your infrastructure?

We do. We can support any CNCF certified Kubernetes distribution and any CSI-based storage. So we try to make it very agnostic. Any CSI-based storage. So we tried to make it very agnostic. Any CSI-based storage. There's got to be 12 dozen of them out there now. Yeah. By going with this, you know, we wanted to make sure we kept it at the standards. So by using CSI as a standard, it allowed us to really be agnostic on our storage. On our HCL, we kind of, the way we kind of negate the, the way we help with the storage, because there are a lot of startups, can't always make sure they're conformed to the standard.

So for storage, we kind of do a limit that limit that to anybody that's part of our Veritas Technology Alliance partner platform, which is every major storage vendor in the market. That way, if somebody does something that doesn't work quite like we expected, we can handle that in the back channels with support. But it's all based on CSI compliance and using CSI drivers and don't have to worry about any of that. And again, with the kubernetes we go all in on the kubernetes apis cncf has already taken care of like standardizing that um so we we can work with any cncf certified we're still going through our own validation right all the major platforms because you never want to be caught off guard right you want to do your own due diligence. So we continue to validate all of our major platforms, but it's all CNCF's APIs at the Kubernetes layer. So we haven't had any issues with any version we've

tested so far. So Renee, now that I'm looking at this at an operator level, as opposed to a client level, like I remember licensing net backup per client. An operator is not equal to a client level. Like I remember licensing net backup per client. An operator is not equal to a client. It may be equal to a client like in the interface, but from a size of what I'm backing up, an operator can obviously be, you know, a client can be huge, but an operator is more likely a bigger purview

as a whole cluster. How is the operator licensed as opposed to the client or is there a kind of single key for uh from a licensing licensing cost for the yeah pretty much our majority of our base unless for the most part is all switched over to front-end terabyte based protection or cost and or subscription based so you can purchase it as a subscription model which is where most people want to go now and that's the kind of path forward where most people are trending to is using a subscription based model and so that's where we see probably most people purchasing this or you can do a, now I'm losing my words here. You could do a term license, right, with front-end terabyte as well.

But we're seeing most people's appetite is more going towards subscription-based. So both options are available. And that's not just for Kubernetes. So again, because it's built in a net backup, if you have your capacity licenses or your subscription licenses for net backup, you're licensed for Kubernetes. If your environment grows and you need more capacity, you can add more capacity, but it's not like you have to buy a specific license to do this. So it makes it really easy for our customers that are on the early adopter stage to say, we just want to test this out. We want to play with this. We want to look at it. I don't have to worry about going out and, you know, adding new software or new capabilities or new licensing. I already have it. Yeah. So just test it. Oh, this is, this is great. Works awesome. Now let's just extend it.

Okay. Keith, any last questions for Renee before we close? No, this has been one of the better Kubernetes. I love to hear that. That's our goal. God. All right, Renee, anything you'd like to say to our listening audience before we close? Just make sure you know that there are solutions out there we're we're here to help we know it can be complicated our goal is to make it as easy as possible for our customers to use that's great well this has been great renee thanks for being on our show today thank you it was great talking to you guys that's it for now bye renee

bye ray bye keith, Keith. Until next time. Next time, we will talk to another system storage technology person. Any questions you want us to ask, please let us know. And if you enjoy our podcast, tell your friends about it. Please review us on Apple Podcasts, Google Play, and Spotify, as this will help get the word out. Thank you.