Data Protection in the Cloud - How the Conversation has Changed
Transcript
(dramatic music) >> (claps) All right guys. We're at AWS re:Invent 2022 here in Vegas, and we just happened to run into each other in the hall talking about the difference of this conference versus previous AWS re:Invents and even other like open source conferences. Anthony, what's been your experience over the years? >> Yeah, I mean I came to my first re:Invent in 2017 right? And that was, it was big, but from a Veeam perspective and we were, it was hard to have a conversation about all things, AWS related versus backup relate but, five years later, five or six years later, I think it's five, this is my third one.
(Keith laughs) And we're having greater conversations. There's more excitement around the booth. People are actually, getting attracted into what we are doing. But then also I think just this whole realization that data is so important. That's obviously been a narrative that's been pushed for the last three or four years right? " Like that's become such a central part of everyone's thought process. So it kind of validates where we are as Veeam and as STEM technologists and what we've been kind of talking about for a long time.
So it's really exciting. There's so many people, and I think it's a really, really good event to be back in person as well. >> And then Michael, we're just talking about just the difference in transformation, and who we're talking to. It's not just developers anymore, needing to do kind of the DevOpsy thing, but now we're seeing more sysadmins. >> Yeah, absolutely. I think like the sysadmin-wise are, the data's always been more relevant. Maybe they once were looking after the data on premises in their vSphere environments but now the company needs to expand that, and have that in the public cloud, and they still have to have that responsibility to protect that data.
So like you mentioned around like open source conferences as well, the difference there, exactly the same. That trend of the sysadmin evolving, and having a bit more of responsibility around the data, and the workload to a degree. But generally the data, how do we protect it? How do we restore it if bad things happen, 'cause they're going to happen. Yeah so, I think there's an evolution of the sysadmin role, having more more focus around automation, more focus around what they can do with that data.
How can we do more with less, that sort of like mindset is happening. >> So guys, let's have a scene. Let's talk about kind of the sponsor part of this video and where Veeam is helping to, customers navigate, like these massive landscapes. What I'm discovering is that, IT is not dying, like it's cumulative. There's VMware services, there's Kubernetes services, there's AWS has just announced a bevy of data services, that again my mind went directly to kind of how do I protect that?
Not just how I protect the underlying data, but how do I protect my work? Like with the value, Adam talked about the value and the transferability of the actual work that, at the end of the day when I create a model. I need to protect the model. So let's talk about kind of the being overall approach. Either one of you can give me an intro or overview, of what's the Veeam approach to cloud and data protection in the cloud. >> Yeah, okay like traditionally right.
Obviously we are born in the virtualization world. We all know that right. So, we've rode that wave really successfully. That's done and dusted. I've been at Veeam for six years, and I've seen the platform evolve to not just do your hypervisors but also start to branch out into, as a service with Microsoft staff, but more specifically really push into the cloud space right. Backing up, obviously AWS is why we're here but the other public clouds that are out there, into the Kubernetes world.
And we are evolving into that. So, we really just sit there with this platform now which we didn't have six years ago. We had a couple of solutions. And now we talk about the outcome. Like you said, you've got your data, how do you protect it? So we are really just facilitating that, and trying to talk to the industry, talk to the guys that Michael was describing, that we're transitioning from on-premises, to a more hybrid world. You do have that that group of people that are just the DevOpsy, the serverless guys, who they're the harder ones to have the conversations with.
But if we can kind of bridge that, then our value becomes pretty good right. >> Yeah, so Michael, let's talk about kind of the bridging the worlds 'cause... I kind of think of you as the casting evangelist. Whenever I think of what Veeam is doing, when it comes to Kubernetes and cloud native backup you're kind of my first button to kind of press on the phone of who to talk to. But the vision is much bigger now than just Kubernetes, and traditional VM backups or even EC2 backup.
Talk to me kind of the workflow when I'm thinking about backing up my apps. How should I be thinking about that now? >> So, first and foremost, it's generally focused on the application. And that doesn't matter whether it's a virtual machine, physical, cloud, cloud native type approach. But like, to Anthony's point about like serverless, or like we won't get into like web assembly or anything like that but... >> Obviously it will be one of our favorite topics, but go ahead.
>> But generally speaking, if we think about like, where does our app send the data? Where does it store the data? It's generally going to be some sort of database, some sort of data service. A database can live in a virtual machine, a physical, way back it had to be physical. And then that's evolved. Whether you want to run that database inside of Kubernetes, or inside of RDS for example. But the database is going to be there. Or the serverless might even leverage that database.
But how do we protect that? Now I like from a demo point of view, we bring out failure scenarios like just dropping databases. Now that shouldn't really happen in a production but it's a good way of simulating a huge failure. But accidents do happen. They can encrypt them databases. So how do we protect the data? Well, the database as part of that whole application. So you might have your application running in Kubernetes or it might be running in an EC2.
It might be that your database runs in RDS, it might run as an EC2 instance. It might run as a VM. And you have to look at all of that. So, I think from my focus is that, all the data doesn't always have to live in a container, or in the Kubernetes environment. We have customers that are using, like cast them for example that protect RDS, plus the front end application, that lives inside of Kubernetes, which gives them the scalability and the flexibility of that.
And then it just hooks into a Postgres RDS instance or some sort of Aurora type MySQL instance over in the AWS for latency, et cetera. So yeah, there's a lot of flexibility in terms of that, but we have to think about the overall application wherever that may be yeah >> And actually I just, so Mike and I did a really, a demo that we did sort of this year right, was where the same application was a basic WordPress site, but we had it across all sorts of those platforms right?
And the idea was that we broke every single one of them and we recovered them with the Veeam tool set right, the platform. But the application was central to that. So I think from what we were talking about, that was a pretty powerful way to show that it doesn't really matter where you're putting the data, where the application lives, you can protect it. >> So we're going to talk about kind of this, portability of workflow in a second, but you two have hit a point that, when I talk to AWS architects or AWS executives, they have a tendency of drilling home this point of shared responsibility.
There's what they do, and then there's what the end user organization or customer needs to do on their side. >> Michael Cade: Yeah. >> What side of the field is Veeam playing on when that shared responsibility model? >> Yeah, so I think like, so customer data, in fact, AWS, their shared responsibility, they've got a really good post, that talks about what they're responsible for, and what you are as a customer. And customer data is a big rectangle in there that's very bold.
So that, like we go back to the databases or data services, that is your responsibility. They'll keep the platform up. Ultimately they're a big service provider right. I'll let you touch on the service provider side, but ultimately they're providing a service. They're providing a platform, that enables you to run databases, virtual machines, file systems, et cetera. But, and you put your stuff on it, that's your responsibility, they'll keep the infrastructure up, but it's the data is your responsibility. >> Yeah, and I think it's kind of blurring a little bit though right, because obviously now they've got that shared responsibility model, where they have that triangle, but then they've got their backup products as well.
So it's almost like there's a little bit of a, coming together where they're going okay, well you can be responsible for it using our tool set as well right. So we absolutely love that because it validates where we are in terms of the backup for AWS product which we build on top of their platform, talk to their APIs and in a special way and their primitives to create a product that leverages our portable data format. It increases efficiencies and lets you sort of back up EC2, VPCs, RDS in a Veeamy way right which people love.
So it kind and the way that I talk about it, especially we're seeing quite a few services companies, that are moving into consulting for AWS. And they're wondering how can they make money off managed services for backup, as workloads move from the cloud, from on premises to the cloud. And that is absolutely the way, so we can offer these services, they can control it from a central point, and just basically continue to get the best of both worlds. >> So let's talk a little bit more about that managed service provider story, because this has been a difficult period of transition for most managed service providers.
>> Michael Cade: Yeah. >> When I was backing up my data set via managed service provider, to another cold site via Veeam, very clean solution. But now I'm introducing Kubernetes, I'm introducing RDS, I'm introducing VMs, and other types of compute. And manage service providers are kind of stuck. There was no centralized resource that could do that entire landscape of services. Are there now managed service providers that can now go to and say, hey you're based on Veeam. I talk to Anthony and Michael, can you now back up all of these other assets for me.
>> Yeah, and I'd probably say first off, it's not like they have to do some work right. So the providers have to tap into our APIs, into our automation to be able to abstract... We've got a couple of tools out there. We've got a service provider console, which is like a proxy to our other services calls in the APIs. They can then talk to that to create their offerings. It's actually an evolution of what they were doing with say VMware right?
With Veeam VCD or whatever it was right. But now they're just doing that, using the automation to be able to build the services, and they're now building, they call 'em their own frameworks. So they have their framework when a customer comes to them, and they can use bits of their framework, and that framework might plug into our services. So whether it plugs into Caston, whether it plugs into our our backups or even, on VMC, they might still use a classic Veeam backup replication.
That's what they're now controlling. So we definitely give them the tooling to be able to do that, but they got to do that little bit of work still. >> So, Michael look, talk to me about this portability piece. We're obviously, we're recording this at AWS, so we're going to keep the conversation confined to AWS conversation. But I harken back to the days where I was backing up my Hyper-V and my vSphere environment, and I could kind of use this Veeam abstraction to restore to either platform.
As I look at my AWS environment, I have EC-2 that I'm backing up with Veeam, then I have VMware that I'm backing, VMware cloud on AWS that I'm backing up in Veeam. Does that kind of abstraction still hold up? >> Yeah, so for any of those image-based backups right? So whether it's physical, virtual machines, and there's obviously a long list of virtualization. You mentioned two just them, but our HV, and lots of other image-based backups for virtualization. Then you've got the clouds from a compute point of view.
All of those backups from us are stored in a VBK format. Now you don't need to know (team laughs) like the acronym, or anything for that, but it's like a zip file. So wherever we've taken that back up, we've got the ability to instantly recover an EC2 instance back into VMware. So actual stream that data back into an on-premises virtualization VMware environment but then equally be able to directly restore that into any of the other big hyperscalers. But AWS being one of them.
So that allows us to take physical and virtual machines from on-premises, and actually restore them up into AWS as EC2 instances as well. And we can manipulate what that looks like. So just because it had 4GB of RAM on premises we can give it 16GB of RAM when it get goes to an EC2. So we can transform what that looks like, as it goes through that process. Obviously we can automate that as well. So you can put that all into a way of being able to provide disaster recovery or automated recovery, or maybe automated testing as well for that data set.
But that portable data format, is obviously the lifeblood of Veeam in terms of, we started with a VBK that we made 10 years ago, is still available for us to be able to recover that wherever you want. >> Yeah, so while we're recording this at AWS re-Invent we're not beholden to them, 'cause this is still the CTO advisor studio. So, I want to talk a little bit about, what you just hit on. Workload portability is a thing that I've been researching for quite some time.
I've used Veeam to back up an EC2 instance, and then repatriate that onto my... Into the CTO visor hybrid infrastructure 'cause it made sense. That's where it made sense to run workloads. As I think about like this image based backup capability, how is Veeam thinking about other types of backup that's may not be image-based, but I still want to, I want this portability or cross clouds, or cross infrastructure. >> So if we... Let's take unstructured data for an example right.
So NAS-based data, SMB, NFS data that we have on premises. Maybe we are using well-known NAS enterprise storage system but we want to take advantage of EFS 'cause we're here. Let's talk about the elastic file system. We've got the ability to restore that unstructured data and be that migration tool as well, to move that into EFS. There's no, we see it as a file system, we don't really care about the underpinning. But then when we get up there, how do you then protect it?
we have the backup for AWS, that then allows us to protect EFS as well. So again, it's that continuation of how you protect it using that single interface, that VBR interface, that allows us to protect all of it, all of the services. And then from a sysadmin perspective even from a developer perspective, it's just the Veeam API. Like I don't care if it's EFS or NFS, or some other file system behind it. The process to back up the unstructured data is the same process.
>> Yeah, pretty similar, obviously there's some differences when you look at EFS and their API and what NFS looks like on premises. Same with different storage vendors. So we have integration on premises with some of those enterprise storage systems, that allow us to use their storage snapshots to then suck the data out of that. So, but relatively, yes it's going to look and feel the same way. We're just abstracting that the complexities of that. >> So I'm talking with two principle technologists.
What are your titles at? >> They flow, depends on the day, depends on the day. >> Why are they here at AWS re:Invent? >> Oh yeah, so I would say, lead technologist cloud and service provider here. >> Okay. >> Technologists for cloud native. >> And there's a lot of complexity here. We, right before we started the interview, we were talking about Control Plane IO, and the need to extract away from the services here at AWS re:Invent, they announced a ton of data services.
Too much to digest even on this show. And we we're talking about data protection. I think that's a great conversation for another date. But we also talked about the abstraction of managing the data, which is a huge problem. As I think about whether my data is in GCP or AWS or on prem I have the same team to be able to manage it with, the challenge when you talk to the Veeams of the world, is to challenge these folks on exactly how do you do this practically.
I hoped we brought a little bit of that conversation. Both these folks are on Twitter. Our link to Twitter handles below. But if you can't get ahold of them directly you have a question for me, and you want me to ask them, I will ask them the question. I'll be the proxy, I'll abstract Veeam folks for you. com. Again, if you want to DM me your question says @Ctoadvisor on Twitter. Talk to you the next CTO Aadvisor studio from Las Vegas.
