RICHARD SEROTER: All right, I'm Richard with Google.
Armon, tell me who you are and what you do.
ARMON DADGAR: Hey, Richard.
Happy to join.
My name's Armon Dadgar.
I'm one of the co-founders of HashiCorp and CTO there.
RICHARD SEROTER: Awesome.
So we're talking multicloud today.
Why do multicloud things?
Can't you just stick to one cloud?
Why are people using multiple clouds?
ARMON DADGAR: Why make our life unnecessarily hard,
you're saying?
RICHARD SEROTER: That's right.
ARMON DADGAR: I think what we've seen
is there's probably three or four, I'd say, independent
but each compelling drivers on their own.
One reason I'd say is the clouds have differentiated technology.
It's like, great, I want to use the best of breed, AI, ML
services that Google may offer.
I might want O365 and managed Azure Active Directory.
So great, that's a compelling reason
to use a different cloud.
So I think each of the clouds has
a set of compelling technology unique to themselves.
I think that's one.
I think a second reason ends up just being pure M&A, right?
Great, you're a giant company.
You went all in one cloud.
You bought a company, went all in on a different cloud.
Welcome to multicloud.
I think a third compelling reason
we see is sort of regulatory.
You're a bank.
You want to move to cloud-based services.
Your regulators are forcing you to say
you have to show us that you can operate in multiple clouds
and do a failover before we'll give you sort of approval.
I'd say the last two pieces of it
is either you're operating in certain markets, maybe China,
for example, where there's less choices,
or you get pushed into specific clouds.
And then the last piece, you might have a business
relationship with these different vendors that
drives you to say, hey, I'm going to consume multicloud.
So I think all of those are valid,
and we see all of those in practice
RICHARD SEROTER: Yeah, that's great.
Now, you've been writing for "The New Stack"
a series of articles looking at different dimensions
of multicloud.
So I think it's been a nice way of framing it
because it can sometimes feel like an all or nothing
maybe, sometimes in vendor messaging
or even when you're doing your own cloud strategy.
So you talked about things like data portability or data
multicloud, workflow.
Can you talk about that just a little bit?
What are the sort of areas where people start framing
a multicloud plan to adopt?
How should they slice that up?
ARMON DADGAR: Yeah, it's a really good question,
and I like the way you said it.
It's like people treat it like this binary of you're
either multicloud or not multicloud.
And our view is if you ask people what multicloud means
to them, there's sort of five different definitions or more.
And so for us, we sort of broke it down and said,
I think there's four really clear definitions of multicloud
as we see it.
One is what we call work load portability.
One is what we call workflow portability.
One's what we call data portability,
and one's what we call traffic portability.
And I think each one of them has different implications in terms
of, OK, what does my investment look like?
How am I consuming cloud?
What are the constraints I put on myself?
And I think there's almost a graduation criteria.
You sort of have to do the simpler versions of multicloud
before you can get to sort of the panacea of I
push a button and seamlessly move traffic from one cloud
to the other and no loss of data, for example.
RICHARD SEROTER: Which one's the hardest?
ARMON DADGAR: For sure, I think that kind of panacea view.
I think if we say, I want to get to that point
where I can have my data in any cloud and push a button
and I just instantly, say, from 100% of traffic
here to 100% of traffic there, I think
that requires just a really high bar of investment
in terms of to get there, you have
to have your data replicated.
So you have a data portability question of my data
has to be on multiple sites, and I have
to be doing active replication.
It means you need a consistent workflow.
So I have to have a consistent pipeline that
lets me deploy my app to both sides
and be able to push a button and change
where is the thing running.
That sort of implies the workload
itself has to be portable so I'm not using
sticky services in a cloud.
So that constrains what I can actually use.
And at the final tier, my app has to be aware
that I'm doing this, right?
So if I have multiple layers of business logic
that's doing things like caching or transactions
that might not be able to span a multicloud environment,
my app might break.
So I think it's everything from it
becomes an application investment.
It becomes a platform investment.
It becomes a CI/CD investment.
It becomes a tooling and a workflow investment,
et cetera, et cetera.
So I think that's sort of the pinnacle.
RICHARD SEROTER: Now, you mentioned there, though,
and you touched on it that some of these
can kind of naturally--
I mean, it's going to be harder because you
use the unique services of each cloud.
Your first answer talked about that's
the one reason people do multicloud,
is there's unique services at each one.
So do you think that adopting multicloud necessarily
forces you down the sort of lowest common denominator?
Well, maybe I shouldn't use a unique service in this cloud
because I can't find it in another one.
How do you balance that so that you still
get the value of cloud but maybe give yourself
strategic portability where you need it?
ARMON DADGAR: Totally, and I think
this is such a good question.
And I think what it brings you back to is sometimes
it's like what's the reason you're
doing this to begin with.
What was the business value?
Were you just using multicloud to say you
were using multicloud?
And why are you forcing yourself into sort of a lowest
common denominator view?
I'm with you.
I think if you're going to do multicloud,
part of the value of it is you get
these differentiated services.
And so if you're treating it like lowest common denominator,
you're hamstringing yourself.
You're not going to get that value out of it.
So I tend to think that that's a bad way to approach it.
You want to use the cloud for where they're differentiated,
where you're going to get their strengths.
Now, I think practically speaking,
there might be scenarios where that's not possible.
If you have a regulator who's saying,
hey, you have to show me that you
can do a failover between cloud A
and cloud B, OK, well, then you better pick things
that are portable, right?
Otherwise, you're going have a really tough time proving
to your regulator.
So I think there's conditions under which you have
to be more practical, but I think for most people,
they don't have those constraints
so it's like, yeah, you should lean in and use
the differentiated cloud services.
RICHARD SEROTER: No, it makes sense.
I mean, we see that, too.
Well, there's brilliant answers.
Thank you, Armon, for taking some time to chat with us,
hopefully make Google Cloud and just
cloud people in general more intelligent
about how to do these strategies.
ARMON DADGAR: So thanks so much for making the time.
[MUSIC PLAYING]