(calm music) >> Hi everybody. We're here at VeeamON 2022. This is day two of the CUBE's continuous coverage. I'm Dave Vellante. My co-host is Dave Nicholson. A ton of energy. The keynotes, day two keynotes are all about products at Veeam. Veeam, the color of green, same color as money. And so, and it flows in this ecosystem. I'll tell you right now, Michael Cade is here. He's the senior technologist for product strategy at Veeam. Michael, fresh off the keynotes. >> Yeah, yeah. >> Welcome. Danny Allen's keynote was fantastic. I mean, that story he told blew me away. I can't wait to have him back. Stay tuned for that one. But we're going to talk about protecting containers, Kasten. You guys got announcements of Kasten by Veeam, you call it K10 version five, I think? >> Yeah. So just rolled into 5.0 release this week. Now, it's a bit different to what we see from a VBR release cycle kind of thing, cause we're constantly working on a two week sprint cycle. So as much as 5.0's been launched and announced, we're going to see that trickling out over the next couple of months until we get round to Cube (indistinct) and we do all of this again, right? >> So let's back up. I first bumped into Kasten, gosh, it was several years ago at VeeamON. Like, wow this is a really interesting company. I had deep conversations with them. They had a sheer, sheer cat grin, like something was going on and okay finally you acquire them, but go back a little bit of history. Like why the need for this? Containers used to be ephemeral. You know, you didn't have to persist them. That changed, but you guys are way ahead of that trend. Talk a little bit more about the history there and then we'll get into current day. >> Yeah, I think the need for stateful workloads within Kubernetes is absolutely grown. I think we just saw 1.24 of Kubernetes get released last week or a couple of weeks ago now. And really the focus there, you can see, at least three of the big ticket items in that release are focused around storage and data. So it just encourages that the community is wanting to put these data services within that. But it's also common, right? It's great to think about a stateless... If you've got stateless application but even a web server's got some state, right? There's always going to be some data associated to an application. And if there isn't then like, great but that doesn't really work- >> You're right. Where'd they click, where'd they go? I mean little things like that, right? >> Yeah. Yeah, exactly. So one of the things that we are seeing from that is like obviously the requirement to back up and put in a lot of data services in there, and taking full like exposure of the Kubernetes ecosystem, HA, and very tiny containers versus these large like virtual machines that we've always had the story at Veeam around the portability and being able to move them left, right, here, there, and everywhere. But from a K10 point of view, the ability to not only protect them, but also move those applications or move that data wherever they need to be. >> Okay. So, and Kubernetes of course has evolved. I mean the early days of Kubernetes, they kept it simple, kind of like Veeam actually. Right? >> Yeah. >> And then, you know, even though Mesosphere and even Docker Swarm, they were trying to do more sophisticated cluster management. Kubernetes has now got projects getting much more complicated. So more complicated workloads mean more data, more critical data means more protection. Okay, so you acquire Kasten, we know that's a small part of your business today but it's going to be growing. We know this cause everybody's developing applications. So what's different about protecting containers? Danny talks about modern data protection. Okay, when I first heard that, I'm like, eh, nice tagline, but then he peel the onion. He explains how in virtualization, you went from agents to backing up of VMware instance, a virtual instance. What's different about containers? What constitutes modern data protection for containers? >> Yeah, so I think the story that Danny tells as well, is so when we had our physical agents and virtualization came along and a lot of... And this is really where Veeam was born, right, we went into the virtualization API, the VMware API, and we started leveraging that to be more storage efficient. The admin overhead around those agents weren't there then, we could just back up using the API. Whereas obviously a lot of our competition would use agents still and put that resource overhead on top of that. So that's where Veeam initially got the kickstart in that world. I think it's very similar to when it comes to Kubernetes because K10 is deployed within the Kubernetes cluster and it leverages the Kubernetes API to pull out that data in a more efficient way. You could use image based backups or traditional NAS based backups to protect some of the data, and backup's kind of the... It's only one of the ticks in the boxes, right? You have to be able to restore and know what that data is. >> But wait, your competitors aren't as fat, dumb and happy today as they were back then, right? So it can't... They use the same APIs and- >> Yeah. >> So what makes you guys different? >> So I think that's testament to the Kubernetes and the community behind that and things like the CSI driver, which enables the storage vendors to take that CSI abstraction layer and then integrate their storage components, their snapshot technologies, and other efficiency models in there, and be able to leverage that as part of a universal data protection API. So really that's one tick in the box and you're absolutely right, there's open source tools that can do exactly what we're doing to a degree on that backup and recovery. Where it gets really interesting is the mobility of data and how we're protecting that. Because as much as stateful workloads are seen within the Kubernetes environments now, they're also seen outside. So things like Amazon RDS, but the front end lives in Kubernetes going to that stateless point. But being able to protect the whole application and being very application aware means that we can capture everything and restore wherever we want that to go as well. Like, so the demo that I just did was actually a Postgres database in AWS, and us being able to clone or migrate that out into an EKS cluster as a staple set. So again, we're not leveraging RDS at that point, but it gives us the freedom of movement of that data. >> Yeah, I want to talk about that, what you actually demoed. One of the interesting things, we were talking earlier, I didn't see any CLI when you were going through the integration of K10 V5 and V12. >> Yeah. >> That was very interesting, but I'm more skeptical of this concept, of the single pane of glass and how useful that is. Who is this integration targeting? Are you targeting the sort of traditional Veeam user who is now adding as a responsibility, the management of protecting these Kubernetes environments? Or are you at the same time targeting the current owners of those environments? Cause I know you talk about shift left and- >> Yeah. >> You know, nobody needs Kubernetes if you only have one container and one thing you're doing. So at some point it's all about automation, it's about blueprints, it's about getting those things in early. So you get up, you talk about this integration, who cares about that kind of integration? >> Yeah, so I think it's a bit of both, right? So we're definitely focused around the DevOps focused engineer. Let's just call it that. And under an umbrella, the cloud engineer that's looking after Kubernetes, from an application delivery perspective. But I think more and more as we get further up the mountain, CIS admin, obviously who we speak to the tech decision makers, the solutions architects systems engineers, they're going to inherit and be that platform operator around the Kubernetes clusters. And they're probably going to land with the requirement around data management as well. So the specific VBR centralized management is very much for the backup admin, the infrastructure admin or the cloud based engineer that's looking after the Kubernetes cluster and the data within that. Still we speak to app developers who are conscious of what their database looks like, because that's an external data service. And the biggest question that we have or the biggest conversation we have with them is that the source code, the GitHub or the source repository, that's fine, that will get your... That'll get some of the way back up and running, but when it comes to a Postgres database or some sort of data service, oh, that's out of the CI/CD pipeline. So it's whether they're interested in that or whether that gets farmed out into another pre-operations, the traditional operations team. >> So I want to unpack your press release a little bit. It's full of all the acronyms, so maybe you can help us- >> Sure. >> Cipher. You got security everywhere enhance platform hardening, including KMS. That's key- >> Yeah, key management service, yeah. >> System, okay. With AWS, KMS and HashiCorp vault. Awesome, love to see HashiCorp company. >> Yeah. >> RBAC objects in UI dashboards, ransomware attacks, AWS S3. So anyway, security everywhere. What do you mean by that? >> So I think traditionally at Veeam, and continue that, right? From a security perspective, if you think about the failure scenario and ransomware's, the hot topic, right, when it comes to security, but we can think about security as, if we think about that as the bang, right, the bang is something bad's happen, fire, flood, blood, type stuff. And we tend to be that right hand side of that, we tend to be the remediation. We're definitely the one, the last line of defense to get stuff back when something really bad happens. And I think what we've done from a K10 point of view, is not only enhance that, so with the likes of being able to... We're not going to reinvent the wheel, let's use the services that HashiCorp have done from a HashiCorp vault point of view and integrate from a key management system. But then also things like S3 or ransomware prevention. So I want to know if something bad's happened and Kasten actually did something more generic from a Veeam ONE perspective, but one of the pieces that we've seen since we've then started to send our backups to an immutable object storage, is let's be more of that left as well and start looking at the preventative tasks that we can help with. Now, we're not going to be a security company, but you heard all the way through Danny's like keynote, and probably when he is been on here, is that it's always, we're always mindful of that security focus. >> On that point, what was being looked for? A spike in CPU utilization that would be associated with encryption? >> Yeah, exactly that. >> Is that what was being looked- >> That could be... Yeah, exactly that. So that could be from a virtual machine point of view but from a K10, and it specifically is that we're going to look at the S3 bucket or the object storage, we're going to see if there's a rate of change that's out of the normal. It's an abnormal rate. And then with that, we can say, okay, that doesn't look right, alert us through observability tools, again, around the cloud native ecosystem, Prometheus Grafana. And then we're going to get insight into that before the bang happens, hopefully before the bang. >> So that's an interesting when we talk about adjacencies and moving into this area of security- >> We're talking to Zeus about that too. >> Exactly. That's that sort of creep where you can actually add value. It's interesting. >> So, okay. So we talked about shift left, get that, and then expanded ecosystem, industry leading technologies. By the way, one of them is the Red Hat Marketplace. And I think, I heard Anton's... Anton was amazing. He is the head of product management at Veeam. Is been to every VeeamON. He's got family in Ukraine. He's based in Switzerland. >> Yeah. >> But he chose not to come here because he's obviously supporting, you know, the carnage that's going on in Ukraine. But anyway, I think he said the Red Hat team is actually in Ukraine developing, you know, while the bombs are dropping. That's amazing. But anyway, back to our interview here, expanded ecosystem, Red Hat, SUSE with Rancher, they've got some momentum. vSphere with Tanzu, they're in the game. Talk about that ecosystem and its importance. >> Yeah, and I think, and it goes back to your point around the CLI, right? Is that it feels like the next stage of Kubernetes is going to be very much focused towards the operator or the operations team. The CIS admin of today is going to have to look after that. And at the moment it's all very command line, it's all CLI driven. And I think the marketplace is OpenShift, being our biggest foothold around our customer base, is definitely around OpenShift. But things like, obviously we are a longstanding alliance partner with VMware as well. So their Tanzu operations actually there's support for TKGS, so vSphere Tanzu grid services is another part of the big release of 5.0. But all three of those and the common marketplace gives us a UI, gives us a way of being able to see and visualize that rather than having to go and hunt down the commands and get our information through some- >> Oh, some people are going to be unhappy about that. >> Yeah. >> But I contend the human eye has evolved to see in color for a very good reason. So I want to see things in red, yellow, and green at times. >> There you go, yeah. >> So when we hear a company like Veeam talk about, look we have no platform agenda, we don't care which cloud it's in. We don't care if it's on-prem or Google Azure, AWS. We had Wasabi on, we have... Great, they got an S3 compatible, you know, target, and others as well. When we hear them, companies like you, talk about that consistent experience, single pane of glass that you're skeptical of, maybe cause it's technically challenging, one of the things, we call it super cloud, right, that's come up. Danny and I were riffing on that the other day and we'll do that more this afternoon. But it brings up something that we were talking about with Zeus, Dave, which is the edge, right? And it seems like Kubernetes, and we think about OpenShift. >> Yeah. >> We were there last week at Red Hat Summit. It's like 50% of the conversation, if not more, was the edge. Right, and really true edge, worst cases, use cases. Two weeks ago we were at Dell Tech, there was a lot of edge talk, but it was retail stores, like Lowe's. Okay, that's kind of near edge, but the far edge, we're talking space, right? So seems like Kubernetes fits there and OpenShift, you know, particularly, as well as some of the others that we mentioned. What about edge? How much of what you're doing with container data protection do you see as informing you about the edge opportunity? Are you seeing any patterns there? Nobody's really talking about it in data protection yet. >> So yeah, large scale numbers of these very small clusters that are out there on farms or in wind turbines, and that is definitely something that is being spoken about. There's not much mention actually in this 5.0 release because we actually support things like K3s,(indistinct), that all came in 4.5, but I think, to your first point as well, David, is that, look, we don't really care what that Kubernetes distribution is. So you've got K3s lightweight Kubernetes distribution, we support it, because it uses the same native Kubernetes APIs, and we get deployed inside of that. I think where we've got these large scale and large numbers of edge deployments of Kubernetes and that you require potentially some data management down there, and they might want to send everything into a centralized location or a more centralized location than a farm shed out in the country. I think we're going to see a big number of that. But then we also have our multi cluster dashboard that gives us the ability to centralize all of the control plane. So we don't have to go into each individual K10 deployment to manage those policies. We can have one big centralized management multi cluster dashboard, and we can set global policies there. So if you're running a database and maybe it's the same one across all of your different edge locations, where you could just set one policy to say I want to protect that data on an hourly basis, a daily basis, whatever that needs to be, rather than having to go into each individual one. >> And then send it back to that central repository. So that's the model that you see, you don't see the opportunity, at least at this point in time, of actually persisting it at the edge? >> So I think it depends. I think we see both, but again, that's the footprint. And maybe like you mentioned about up in space having a Kubernetes cluster up there. You don't really want to be sending up a NAS device or a storage device, right, to have to sit alongside it. So it's probably, but then equally, what's the art of the possible to get that back down to our planet, like as part of a consistent copy of data? >> Or even a farm or other remote locations. The question is, I mean, EVs, you know, we believe there's going to be tons of data, we just don't.. You think about Tesla as a use case, they don't persist a ton of their data. Maybe if a deer runs across, you know, the front of the car, oh, persist that, send that back to the cloud. >> I don't want anyone knowing my Tesla data. I'll tell you that right now. (all laughing) >> Well, there you go, that one too. All right, well, that's future discussion, we're still trying to squint through those patterns. I got so many questions for you, Michael, but we got to go. Thanks so much for coming to theCUBE. >> Always. >> Great job on the keynote today and good luck. >> Thank you. Thanks for having me. >> All right, keep it right there. We got a ton of product talk today. As I said, Danny Allan's coming back, we got the ecosystem coming, a bunch of the cloud providers. We have, well, iland was up on stage. They were just recently acquired by 11:11 Systems. They were an example today of a cloud service provider. We're going to unpack it all here on theCUBE at VeeamON 2022 from Las Vegas at the Aria. Keep it right there. (calm music)