(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)