[MUSIC PLAYING]
RICHARD SEROTER: Hey, I'm Richard Seroter with Google.
I'm here with Corey Quinn to talk a little bit
about multicloud.
And, Corey, what do you do again?
Remind me.
COREY QUINN: There are days I wonder myself.
Primarily, it tends to be creating a scene on Twitter,
it seems.
But, in my day job, I help companies
fix their horrifying AWS bills, a problem that
happens to everyone in the fullness of time.
RICHARD SEROTER: So tell me something in your real life
that you only buy from a single vendor.
COREY QUINN: Oh, dear lord.
Easy, underpants.
I wind up getting them from Amazon, only.
Because, one time, it didn't work,
and I got their error page which had
refreshing pictures of dogs, which was kind of soothing.
Now, if I listen to a lot of folks
who will tell stories about the e-commerce world, oh,
because I wasn't able to complete my underpants
transaction, then I was never going to wear underpants
that one day out of the week.
In practice, I tried an hour later, and it worked.
Counterargument, if it wound up happening every third time
I tried to buy underpants, I would probably
spend a lot more money at Target.
RICHARD SEROTER: I was afraid you were going to have, like,
a chest-wax guy or a hamster guy,
so I'm glad that we stuck with underpants.
That's good.
COREY QUINN: Exactly.
We're going to make sure that we keep this at least
somewhat appropriate for folks to wind up displaying proudly
on social media.
RICHARD SEROTER: Yeah.
That's good.
Give me a case when it does make sense to do multicloud, Corey.
COREY QUINN: Sure.
You're a big company.
You acquire another company that is
doing something in a cloud provider
you're not doing anything in.
Should you migrate that in?
Probably not.
It doesn't add much as far as business value goes.
It's going to be incredibly obnoxious to do.
It's going to be expensive, take longer than everyone thinks,
and what's the business upside to this?
It feels like that's one of those things that doesn't often
have a good answer other than, well, we're all in on provider
x, so it's important that we migrate everything
that holds still long enough into that provider.
Why?
RICHARD SEROTER: So Duckbill's multicloud, right?
COREY QUINN: We're absolutely multicloud.
We wind up using-- for example, our infrastructure
lives on mostly AWS.
Our code stuff, of course, lives on GitHub
because we're not irresponsible enough to use CodeCommit.
And our email runs through G Suite
because, frankly, I'd rather you run email servers
than we do it ourselves.
RICHARD SEROTER: Yeah, makes sense.
So when is it a-- you kind of alluded
to it-- when's it a terrible idea to do multicloud?
COREY QUINN: The idea of having this one workload that
you're going to deploy to any kind of multicloud
environment-- oh, we want to build this thing so it can
seamlessly be deployed to any provider that we choose--
except you don't.
You deploy it to one provider, and it
remains an aspirational form of multicloud,
kind of like a DR plan you never bother to test.
And, in theory, we could deploy it elsewhere.
That's why we're building things like load balancers
from primitives ourselves.
It doesn't buy you anything and it slows you
down your feature velocity.
If you're going to do that, make sure
that the strategic upside makes sense.
I want to be clear.
My point has never been, multicloud is always bad.
My point is, make sure you understand why you're doing it
before you do it and not just because Gartner
said it was a good idea.
RICHARD SEROTER: Yeah.
What do you have to say for those folks who
worry about locking into a given cloud?
How do you kind of negate that, a little bit, in that concern?
COREY QUINN: You're already locked in.
That might not be the most reassuring thing to hear,
but you've hired staff based upon expertise
with a provider, whomever that provider happens to be.
The way that they handle identity federation,
the way that they handle security,
the way that their networks work,
and the way that their services fail--
and let's be serious, it's cloud.
They're built on top of computers.
Everything fails in the fullness of time.
And making sure that you understand
what that degraded mode looks like
is fundamentally important.
RICHARD SEROTER: Yeah, great point.
What a piece of advice do you have for someone--
either they were already accidentally multicloud
and they're trying to figure out how they get a handle on it
or they're starting down this journey for whatever reason?
What kind of fundamental thing do they have to get right?
COREY QUINN: I would start by talking to someone who's
done what you think you want to do
and asking them what they wish they'd done differently.
That seems to be an undervalued skill in the world, of talking
to people who are where you're heading
and "If you could do it all over again, what would
you do differently?"
Sometimes, they'll give you great advice.
Sometimes, they'll say, "Nothing at all,"
which is usually a lie.
Other times, they'll just start screaming incoherently
because they have seen things that you, too, will see
if you continue down this path.
It really depends.
It comes down to understanding the reason behind why you're
doing what you're doing and making sure
that it resonates in the right ways.
It sounds like there's this big mystique behind it,
but there isn't.
Just make sure you're doing it because of an actual problem
you have and not this theoretical problem
you think you might encounter five years from now.
RICHARD SEROTER: Mm-hmm.
Is there an aspect of it that you
think easier than people think?
COREY QUINN: Sure.
On some level, depending upon what you're doing,
it's really easy, in most cases, to wind up
swapping out one CDN for another, for example.
Right up until the point where you
start shoving logic into the CDN, at which point
you are, more or less, trapped.
If you have a bunch of Varnish rules
that are being implemented by your CDN,
you're not going to have a great time moving away.
Whereas, if it's just pure caching and points of presence,
well, different story entirely.
But I'd take it a step further than that.
Before you decide to go all in on multicloud as a strategy,
take the existing cloud a workload lives in
and move it to a second region in that provider.
You've got, presumably, full API compatibility.
Everything behaves the same way, and it
takes most of these concerns off the table.
Once you've done that, see how easy it was and then
plan accordingly.
Spoiler, it's harder than it looks.
RICHARD SEROTER: Awesome.
That is amazing advice.
Corey, I appreciate you taking a couple of minutes
to chat with me today and impart some wisdom on everybody
on maybe how to do multicloud just a little bit better or not
at all.
[MUSIC PLAYING]