Attackers have gotten very smart.
They realize that they have to go after the backups in
addition to the primary environment, because if an organization
can recover, then they're not gonna pay the ransom.
And the reality is, that the vast majority of
ransomware events are attackers just trying to make
money.
Welcome to Screaming in the Cloud.
I'm Corey Quinn, and this promoted guest episode
is brought to us by our friends at Rubrik.
They also bring to us their chief product officer.
Anneka Gupta has been there for about four years now - first thank you for
daring to put up with my slings, arrows and other implements of misfortune.
I'm excited to be here.
Thanks for having me.
Let’s talk about something I’ve written about before: S3 is not a backup.
I know, I know—you’re versioning, you’re replicating
to another region, you even have lifecycle policies.
Congratulations, you’ve built an expensive way to lose data slightly slower.
Here’s the thing: when ransomware compromises your
credentials—and it will—it can delete every version in every
region because it’s all using the same access controls.
That’s where Rubrik comes in.
They actually air-gap your backups from your AWS credentials, make them
immutable, and can tell you which snapshots are clean when you need to recover.
That’s a backup.
Learn more at rubrik.com/SITC.
So let's, let's start at the very beginning here.
What does Rubrik do, followed up with, and what
does a chief product officer at such a place do?
Absolutely.
So Rubrik is a security and AI operations company.
We help organizations recover.
Their data when they've been hit with cyber attacks,
uh, such as ransomware, and we help them build cyber
resilience into their, their infrastructure and strategies.
We're also doing a lot around helping our organizations operationalize AI.
As a chief product officer, my day is quite varied, but my role fundamentally
is about enabling our product strategy and product roadmap and really
thinking about what is it that we can solve better for our customers and
how do we continue to innovate and innovate and innovate in this highly
evolving landscape, um, at the intersection of data security and AI.
So I'm going to back up a little bit here and, uh, date myself
somewhat that I'm an old crusty sysadmin from once upon a time,
and I've always tended to view the idea of cyber resilience as
being a fancy upmarket term for make sure that you take backups.
We start talking about ai.
It's, ah, but we've had tape robots since the last century.
Uh, I get the sense that events may have
outpaced me in this particular part of the world.
It feels like it goes beyond backups today.
That's a great question and a great perspective.
I think that we end up talking to a lot
of people that share this perspective too.
If you think about the technology of backup and recovery
and the way that the use cases have evolved really.
Originally, it was really around natural disasters and
natural disasters that were gonna hit your data center or
operational issues that, again, end up hitting your data center.
But what we've seen is, first of all, as the data landscape has
evolved, as organizations both have data that are still in their
data center, data that's in the cloud, data that's in SAS app.
Now the surface area is so much broader and the challenges
are so much broader as well, that on top of that, what we've
seen is that there's been an evolution where it's not just now
about operational failures or natural disasters, it's actually.
A lot of the time organizations are having to recover from cyber
attacks, and when you're actually executing a cyber recovery,
it's actually quite different than operational recovery because
in a cyber event, it's not just about, Hey, recover everything.
To the most recent point in a cyber event, you have to
answer critical questions like: What was the blast radius?
How do I find a clean point of recovery so I don't
reintroduce malware into my production systems?
How do I quarantine the malware?
How do I know if sensitive data was impacted?
All of these questions you have to answer before you actually do a recovery.
And the challenge is, is that to answer those questions without
a technology like Rubrik, it often takes weeks or months in order
to actually be able to find that clean point of recovery and
to answer all these questions and to get back up and running.
And what we have seen firsthand is with our customers, is that they've
been able to really shorten that cyber recovery time by about a hundred x
and that has allowed them to have, be more confident that in a cyber event
they can actually minimize the overall downtime of their business, which
is hugely impactful because in a cyber event, it's not just the ransom that
you may have to pay, it's actually the cost of downtime for your business,
which can massively outsize compared to like what a, a ransom might be.
How challenging has it been to productize this?
Because I think back at the places that I've worked as a grumpy
sys admin, which we then call, you know, DevOps, or platform
engineering or SRE, which is the same thing, they just pay better.
Great.
The problem that I found was that.
Planning for backups and restores.
'cause no one cares about backups.
They care very much about restores.
But getting back to a point of viability was a highly bespoke process in every
case due to architectural limitations, implementation decisions that have been
made in years past, and of course, the specifics of a given business model.
Absolutely.
So the way that Rubrik architected our systems from day one was really figuring
out how we could build a unified platform that could create a single way to
manage and operate your backup and recovery across on-prem, cloud, and SaaS.
And so we have built things that makes it super operationally easy, way
easier to deploy where you don't need as much hardware on-prem and in
the cloud we have cloud native ways of deploying our technology and so it
becomes a lot easier to operationalize across this, this whole ecosystem.
And the reality is, is that the way to do recoveries well and
fast, um, across these different surface areas is really different.
And the limitations and technical challenges are very different.
Also when we think about how do you actually, um, how do you actually like
scan for malware and find clean points of recovery and know what was impacted?
Well, how you really do it or how you tell the auditors you do it.
I see.
Those should be congruent.
They should be
congruent.
Yeah.
But there it's really hard, like as you said, in
per like previous to, to customers using Rubrik.
Often what our customers have to do is rehydrate the data.
Then run some kind of scanning on that
data and that can take a really long time.
Instead, the way that rubric is architected is that we have a single
data and metadata layer where we actually can scan the backups and
in real time, provide insights into, here's where we found malware.
And we can do that both, like every time we're taking snapshots
as well as every, as going back through the historic data.
So the ability to, the ability to scan in place really enables
organizations to just do all of that upfront work without having
to like set up holes, separate infrastructure and take valuable
time in, in setting that up and then actually running the scans.
I've always found that when you start setting these
things out, people care about them very much right after.
They really should have made it a point to care
about it a smidgen more than they did already.
Like no one is as, uh, zealous, uh, about backups.
As someone who's lost data, how do you get people to care
about this before it becomes a barn or a horse situation?
I think people are already making that shift.
Like what we have seen with, with our customers is that, you know,
since like 2019, 2020, 2021, as ransomware became a bigger and
bigger challenge and organizations were really facing it, boards were
asking their management teams, Hey, what's your plan for ransomware?
And as there was more publicized examples of massive attacks on
healthcare companies, on Colonial Pipeline on casinos on, you know,
all of these very, very publicized attacks now it is very top of mind.
I think also what we're seeing is in highly regulated industries,
there's a lot more regulation coming out saying that, Hey, you
have to have a cyber resilience and cyber recovery strategy.
It is unfortunately, the case that people often invest still too late.
But I do think that, that that psyche is changing around it.
And I, and I think the, where we're going in the future is saying, Hey, you
actually should not just have this as an insurance policy, but you actually
need to be doing cyber recovery simulations and cyber recovery testing on an
ongoing and frequent basis because you don't wanna find out when you're in the
middle of a cyber event that, hey, you actually didn't have the right technology
or strategy or people or process in place to actually do those recoveries.
When you keep talking, referring to it as cyber, I hear this is much more
of a security angle than my historical experience with, and, and they are
aligned on a, a common axis, whether it's because there's an attacker that
wound up deleting data or I once again did one of my hilarious database
stunts that I'm sure will laugh about someday when the bleeding stops.
I found that you care about a lot of these same things.
Are you looking at this more as a security story?
Is it more of an operation story or is there,
is this a distinction without difference?
I think it's kind of a distinction without a difference in that anything
that we're building for cyber is also going to serve well in an operational
recovery where in a developer dropped a database table or where there
was some kind of server outage in your data center or where you had some
kind of deletion or encryption event, um, in your cloud environments.
Like all, all of the technology is the same to
support both, I think in the cyber scenario.
You just have these additional questions around the blast radius,
finding a clean point in recovery that are very different than what you
would have in other cases where you might have to execute a recovery.
So a, a question that I have to ask, it might be slightly
impolite, but that's sort of my brand and I, I tend to.
Go with it is that if I take a look at how folks care about
things in business, there there are two real categories.
There's the proactive idea that this could triple our market share.
It could quintuple our revenue, summon the board.
Great.
And then you have the, the reactive side of things.
Security being one example, backups being another AWS cost.
High buying fire insurance for the building, all
things that should definitely be done and cared about.
But you can throw effectively infinite money at these things as
a white elephant until you have no money left, and it doesn't get
you any closer to the business milestone that you're targeting at.
How do you Go to Market in a story like that?
I think if you look at security specifically, the spend going towards
security is skyrocketing, but most of that spend is going towards prevention
technology, and the challenge with that is that people are investing more
and more in cyber prevention, and yet there are more and more cyber attacks.
There's a real challenge there if you're really focused around prevention.
What we focus on is assume breach, assume that you have already been breached.
Assume that, um, a attacker is either already
in your system or is going to get there.
What are you gonna do about that?
And how do you actually recover and respond to that?
And so it is a separate area where traditionally,
there's been a pretty big underinvestment there, and
so our, our message is, Hey, you have to assume breach.
I mean, because of the prevalence of cyber attacks.
And if you just keep investing in prevention, prevention, prevention,
you're never going to actually make your business resilient, and then
you're going to be susceptible to the inevitable moment where an attacker
breaks through your four walls and is able to to breach your environment.
Uh, you folks have, uh, been on the record as saying that,
I forget the exact number, but some horrifying percentage
of security incidents backups have been compromised.
I believe it was a majority of the time.
Yes, for certain providers, you can actually go out on the internet and
see how ransomware groups are specifically compromising the backups.
Rubrik has been architected day one from a security first mindset,
so we have multitude of controls around the backups themselves
that prevent the backups from getting compromised during an attack.
Now cynical question that I have to ask, is that entirely
because the backups were explicitly targeted or is part of
this because they've been compromised for two years back?
Things have naturally gone, uh, organically into the backups
before someone finally noticed that they had a problem.
It's one of those c no evil approaches to security approach.
As best we can tell we've never been breached
is sort of a statement of proud ignorance.
It's a great question.
What I will say is that when malware lands in a primary
environment, it can get copied into the backups, right?
So that's a potential point of, of compromise.
But what I will say is like usually that malware
is not gonna be activated on the backups.
It will just be in the primary environment.
And we have capabilities that help you find malware specifically in the backups.
What, when it lands, or shortly thereafter,
if it's a new, new malware that was detected.
Attackers have gotten very smart.
They realize that they have to go after the backups in
addition to the primary environment because if a organization
can recover, then they're not gonna pay the ransom.
And the reality is, is that the vast majority of
ransomware events are attackers just trying to make money.
It's not these like massive nation state actors.
Those are obviously there too, but it's a lot of cyber attackers for hire.
Or people that are just trying to extract money
out of organizations as quickly as possible.
In order to do that, they have to try to compromise the backups as well.
And for legacy solutions where they were not built with the
security first mindset, where they're taking backups over open
protocols where the data is not immutable on the first copy.
Like all of these things that are just not very secure, that leaves the
backups themselves susceptible and the attackers will go after them.
Roughly five years ago I put out a blog post
titled, uh, Multi-Cloud is a Worst Practice.
And despite my opinion on that, which has evolved somewhat but not entirely,
the world has clearly gone multi-cloud either by strategy or by accident.
Uh, sometimes it's for great reasons.
Sometimes it's for terrible ones, but it leads to massive.
Expense in terms of infrastructure sprawl, in terms
of just the cost of complexity that ties into this.
What are you seeing?
Because that has to have security and resilience impact.
Absolutely, and I think that not only are our organization's
multi-cloud, and often it is by accident, right?
It's a organization acquired another company that happened to have used a
different cloud provider than their main cloud provider, or two different
departments within the same company decided to use different cloud providers
for different reasons, and that didn't get caught and reconciled together.
There's a lot of reasons why people end up in this multi-cloud state.
They're not only in a multi-cloud state, but they're in a
hybrid cloud state, so they still have important data that's
sitting on premise, um, as well as data that's in the cloud.
Now, the challenge with all of this is that if you're managing a cyber
resilience strategy with five different tools, one for your cloud environment,
one for your SaaS apps, one for AWS, one for Azure, one for GCP, one for
OCI, if you're using different tools for all of this, then first of all, the
operational complexity is really high and second, um, actually making sure
that you have a strong cyber resilience strategy across all of these when
they may not be uniform and have uniform capabilities is very challenging.
So what we see is that often organizations with this kind of complexity,
one way they can manage the risk is by having a unified platform that
helps them with cyber resilience across all these apps so that they have
a single construct and way of managing cyber resilience and managing
whether they are actually in compliance with their own policies.
Being able to manage that in a central way.
It, it,
it's always strange to me seeing environments from a costing perspective
where, oh, yes, we're spending a large amount on backup because it's worth it.
You dive into it a little bit and you ask leading questions, and it turns
out that they're backing up a fleet of web servers that have thousands of
them and they're spending at great expense imaging each one of these things.
When the entire web server fleet is created about 200 lines of
cloud formation, it's, hmm, maybe there's a better way to do this.
This gets worse in the multi-cloud story.
I mean, for a while back I found that one of the more cost effective things
companies could do is turn off all of AWS's first party security services and
just suffer the breach because it costs less money when all is said and done.
Uh, with multi-cloud that is no longer tenable, people are
forced to go in a direction of third party providers that.
Frankly have a better user experience.
So thanks for that, but also starts letting
them reason around this in a sensible way.
So I guess my question for you is, is multi-cloud
actively serving to make security worse?
Like are we just giving people bigger attack surfaces while patting
ourselves in the back for avoiding lock-in, even though we didn't.
Quick word from Rubrik, who wants to have
an awkward conversation about your backups.
You know those snapshots you’re taking?
The ones in the same cloud account as your production data?
Those aren’t backups.
That’s just... more data in the same place.
When ransomware shows up—and it will—it’s going to encrypt your production
data AND your ‘backups’ because they’re protected by the same credentials.
Rubrik actually air-gaps your backups and makes them immutable, which
means attackers can’t delete them even if they compromise your accounts.
It works across all major clouds and actually
helps you recover when Murphy’s Law gets creative.
Check out rubrik.com/SITC.
anytime you're talking about the surface area expansion of data
and applications, that is increasing the risk to your organization.
It's increasing the number of entry points that an attacker has.
It has, it's increasing the amount of surface
area that your security teams have to monitor.
So there is inevitably a risk associated with it.
I think most of the organizations that I talk to
that have multi-cloud environments, it is not because
they explicitly chose it for a vendor lock-in reason.
It's usually because they evolved into that, through
acquisition, through not having a centralized IT team
or infrastructure strategy and ending up in that state.
There are some that are trying to play the clouds against each
other and get a better deal, but I think it's becoming more and
more common knowledge that, first of all, you're increasing your
operational complexity and you're increasing your security risk area.
So I think that's it’s a challenging position to take.
Also usually the more that you commit to a given cloud,
the more you can get discounts based on that commit.
So if you're spreading that commit across multiple
clouds, then you're just not gonna get the best deal.
So I think that's a, that's a big piece.
Cost is super important for our customers and we, you know, when we deploy our
technology in the cloud, we are cost optimizing the storage of backups massively
compared to the native solutions that the cloud providers provide, because that
is one of the benefits in addition to cyber resilience that we need to provide.
Otherwise, it becomes, as you said, cost
prohibitive to actually provide these services.
I should point out that as we're recording this, we are in
the, the day after AWS's big, uh, meltdown for availability.
That lasted half a day.
And I really hope that by the time this publishes,
people don't come back and have to ask which one.
So we're, we're gonna be optimistic on that.
But there's a lot of knee-jerk reactions of, oh,
we're gonna start going multi-cloud for everything.
We're going to start spreading things out so that we aren't subject to this.
So many of these stories are not, this is
how we eliminate a single point of failure.
It's here's how we add a second single point of failure at tremendous
expense, and then act surprised later if we actually do this.
But these conversations happen every time that
there's a significant, uh, notable cloud outage.
But people generally don't do that once the panic has subsided
and people, people are having the strategy they have for a reason.
And those reasons are no less valid today than they were a week ago.
I agree with that, and I think that there are multiple, there's multiple
types of risk factors that companies are inevitably thinking about.
They're thinking about, okay, like what happens if, if my tenant
gets compromised or my account gets compromised by a cyber attacker?
They're thinking about what happens if the
cloud goes down in this region or zone?
They're thinking about, what if the cloud totally goes down?
I have to fail over to a secondary cloud.
Like there are a, a range of different scenarios that.
Um, companies are worried about, and we see this and we talk to 'em all
the time, and I think there's a, you, as with any risk, you have to ask
yourself like, what's the expected outcome of this risk actually manifesting?
How costly is this to your organization and is this risk worth managing.
One of the things that we found to be quite successful for
organizations is using our technology to be able to keep a copy
of their applications and be able to do a recovery cross region.
So thereby you aren't reliant on a single region in the cloud.
A multi-region outage is much less likely than a single
region outage, and so there are coping mechanisms.
I think truly doing cross cloud recovery, backup and recovery is
quite challenging from a cost perspective, operational perspective,
there's so many aspects of that that make it not super realistic today.
I do
see companies doing a rehydrate, the business
level of backups to another provider.
Uh, not necessarily because there's a tremendous risk of
AWS suffering, its first ever, uh, global network outage.
They've never had an issue that hit.
Every region they've had control plane issues, but there
it's easier for some of these companies to do this than
explain to their auditor every period why they didn't do it.
It checks a box there that feels like it is much less tied to
the specifics of a risk and more of a decision that they make.
There are a lot of check, check the box
capabilities that people wanna be able to, to offer.
And, uh, we think about those and, and offer solutions,
different kinds of solutions for those check the box features.
And then there's stuff where that needs to be operationalized
really well because it is something that you will likely rely
upon in a real event, like cross region application recovery and
being able to orchestrate, um, a full application recovery across.
The different resources and data that make up your application
as opposed to doing it on a service by service basis.
So there's a lot of things that are like real
challenges that you want more than a checkbox for.
And then there's some stuff that's understandably, you need a
checkbox for the auditors, and that's kind of the way it goes.
It's always difficult to test these things because you can
simulate a full region outage of your cloud provider of choice
whenever you want, but there are other companies involved in the
critical path of getting you in front of customers and you can't.
Test their ability to survive that with their
critical path vendors and so on and so forth.
And somebody, it winds up being a giant thorny knot
because everyone cross depends on everyone else.
So we see these challenges of how do people come back up
when everyone is codependent on one another already working?
And that's where some of the fun firefighting
engineering tends to come into play.
How do you think about that?
There's always going to be externalities and things that you haven't
tested and that you're going to have to deal with in real time.
That is just the nature of doing business.
You cannot map out every single dependency between
all of your technologies for all of your applications.
So I think one is.
Figuring out what are your, what is your minimum viable business like?
What are the applications that are absolutely critical
to servicing your business that you cannot live without?
So then you shrink kind of your surface area.
Really thinking about those, those applications, and then test what you
can test, like go and, and test the pieces that you're able to test.
And that way you get the reps in on the things that you can control and
the things that you can see and the dependencies that you do know about.
And that way when you know, let's say there's, you're able to test and,
and manage 80% of those things, then when you're hit with a real cyber
event you can spend all your brain power on the 20% that is unexpected
because in an event there's always gonna be unexpected issues that emerge.
Some of them may be technology, some of them may be people
and process like, oh, you don't have the phone number for
this vendor that you thought you had the phone number for.
Right.
It's, it's simple or you
do, but it turns out they have one or two other
customers that might be in the phone tree ahead of you.
Yeah, exactly.
So there are many things that you can control, but I think if you have.
The ability to actually test recoveries for, for things that are incredible,
like for the applications that are really incredibly valuable to you,
and you're able to cover 50 to 80% of, of that whole process, that just
sets you up even better for when you actually have to face a cyber event.
What
do you think people are mostly getting wrong right When you take a look
at the, at the broad sweep of how they're thinking about cyber resilience.
I think specifically in the cloud, there are a couple of patterns that I see.
One pattern is people thinking that because the cloud is redundant,
that means that they are actually protected in a cyber event.
But the reality is, is that if the data is corrupted.
Redundancy only means that that is gonna get replicated throughout.
Replication is not a backup.
You learn this at your peril.
Yeah.
Correct.
Yeah.
Um, so I think that's one, one thing that's not super well
understood all the time is that that's not a cyber recovery strategy.
That's a, a failover if your infrastructure is down, but your data is fine.
The second thing that I would, uh, also mention is that
every cloud company has their own native backup solution that
essentially is taking cloud snapshots of the environment.
There are a lot of challenges with these solutions
that is putting it very charitably.
Yes.
And I think a lot of people are like, well, I
have a solution because I have native backup.
And the reality is that there are a lot of gaps in native backup,
even from an immutability, recoverability, granular recovery.
And then when you talk about all of the cyber capabilities of being
able to detect malware, find a clean point of recovery, detect
the blast radius, all of that, then the tools are really lacking.
And so that is the cyber resilience plus the
actual like granular capabilities, immutability.
And on top of that, the cost that some of the native
backup solutions add to your storage bill is quite high.
So with our solution, we optimize all of those
pieces, and we're not just limited to a single cloud.
So in your inevitable sprawl of multi-cloud because of the way your
business has evolved, now you have one solution that can cover all of that.
It's worth pointing out as well.
It, it's easy to to to become overly negative when
looking at a lot of the first party offerings.
I mean, I've stared too long into that abyss and it is gazed
deeply and thoroughly into me, which probably explains a lot
the but this, these are hard problems and it's very tricky to
start building things that are holistic solutions for folks.
We've been talking about cloud, but there's an awful lot of hybrid out there.
It turns out that building data centers wasn't
knowledge lost to the ancients, and now only.
Three specific companies can do it.
Lots of companies have on-prem facilities and
are in a variety of different hybrid approaches.
What's your story for those folks?
That's like our ideal customer.
Honestly.
We have so many organizations that we support that have a piece
of their, their applications on-prem, some of their applications
in the cloud, some applications that span on-prem and cloud
and have different components, and being able to have us.
Single solution and platform to be able to,
to provide cyber resilience across all of these applications
and have the same paradigms, have different ways of actually
taking the, the backups and doing the recovery themselves based
on the tools that are available in each of these environments.
It's really important and that's why.
Um, a lot of our, our customers come to us because they, they want that solution
that's gonna span across, and they also want the flexibility of saying, Hey,
maybe in three years I'm gonna move even more of my application to the cloud.
Will you be there with me on my journey,
or am I gonna have to start from scratch?
They don't wanna have to start from scratch.
I'll also point out that you have a variety of approaches
that make sense for a modern cloud infrastructure.
I've, I've worked with so many, quote unquote legacy vendors, which,
you know, a condescending engineering term for it makes money where you
go in and they're, oh, so what are your instances for your database?
Like it, it's DynamoDB.
What do you mean, instance?
Like what?
What's that?
Can you just pull a disc image from it and then we close the page
and look at something more reasonable for us as a closing thought?
And I understand that this might be controversial for.
Well, most companies, but I'm gonna roll with it anyway.
When it comes to cyber resilience, it's one of
those things that absolutely positively has to work.
When people are dealing with Rubrik, they're
already having a pretty bad day on some level.
Why is this a great spot for ai?
: try
to keep it as not insulting as I possibly could
and I feel I may not have succeeded for it.
I dunno, I don't think that that's an insulting question.
AI is a double-edged sword, right?
There are wondrous capabilities that AI is going to to give us.
Things that we're investing in from our,
like improving our solutions, leveraging ai.
And then AI is also a risk, right?
That has to be managed.
And so when we think about AI, you know, I was telling you,
uh, earlier, you earlier about the journey of people having
to recover from natural disasters and then cyber events,
they're gonna have to recover from AI making mistakes as well.
So this is just gonna be another vector of risk that you, or that's
gonna necessitate having really great capabilities around recovery
now, I think like AI is obviously still in its infancy and there's
a lot of, uh, challenges that organizations are facing as they think
about the adoption of AI and how they can truly get value from it.
Because I think, you know, if you talk to, survey organizations, most
organizations say AI's a top priority, but most projects are stuck in prototype.
They're not getting to production.
It is certainly not the top of the spend curve in the common case.
Correct.
And I think, but, but there's a big challenge around how do
you provide, um, monitoring for AI agents, governance for
AI agents, and remediation when AI agents make mistakes.
So that's something that we're thinking about in the
contex of our, our platform and where we can offer it.
And we're also looking at, in this complex sprawl of data and
infrastructure and applications, what are the ways that we can use
AI to help organizations monitor their infrastructure better and
make recommendations of what are their most critical applications?
How can they be protecting these applications better?
I think there's a lot of use cases like that that we can, troubleshooting
failures in backup and recovery, like all these use cases are
things that we're also looking at, well, can we use AI to make, to
make it better, to make it simpler, to make it easier to operate
our technology and provide cyber resilience to large enterprises.
Yeah, and I think that that is a reasonable take on this.
There's a, there's a lot of challenge that I have.
With folks that are tripping all over themselves to take
what they already are doing and already going to market with.
And then, nope, it's AI and has been forever.
But it does change some things, not everything.
I don't think that it's, it's clearly not valueless, but I
also don't think we're gonna properly summon God through JSON.
I think the truth probably is somewhere between those two, and
we're still figuring out as a society what that looks like.
Technology advances and taking an approach of optimism,
but with a sense of caution to, it seems reasonable.
Yeah, I think so.
I mean, I think with any technology, there's great advantages
that come with it, but you have to figure out how to leverage it.
And at the end of the day, it has to be solving a real problem.
And that's, I, I think we're still in the time with AI where we're
trying to figure out how to make it, like, how to take this technology
and leverage it to solve really interesting problems, and it hasn't been
totally figured out yet, especially for, for the large enterprise context.
I, I think you're right.
We're gonna see where this plays out.
I, I'm very curious to see how it goes, but fortunately if it winds up,
uh, not doing what we had hoped and ends up being an entire boondoggling
disaster, well at least we'll have some resiliency around our data.
I sure hope so.
Thank you so much for taking the time to speak with me.
I appreciate it.
Yeah, thanks for having me.
If people wanna, if you wanna learn more,
where's the best place for 'em to find you?
If you wanna find me, I'm on LinkedIn.
Um, you can look up my name.
I work at Rubrik Chief Product Officer.
If you wanna look up Rubrik, um, go to rubrik.com and
you can also find us on all social media platforms.
Yes, and I believe the New York Stock Exchange or
you, nasdaq, I can never remember who's on which.
Uh, NYSE:RBRK.
Apologies.
Yeah, it's one of those.
Things where it's like certain people care very much,
and for the rest of us, it just gets lost in the details.
Uh, Annika Gupta, chief Product Officer at Rubrik.
I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud.
If you've enjoyed this podcast, please.
We have a five star review on your podcast platform of choice, whereas if
you've hated this podcast, please leave a five star review on your podcast
platform of choice along with an angry, insulting comment that we're just
going to scatter to the winds because we will not be taking care of that data.