STEPHANIE WONG: Hey, everyone.
It's Stephanie Wong, back again.
I'm a cloud developer advocate, and I
am thrilled because we have Eric Brewer, our Google fellow, here
with me again today.
We are doing a series of videos.
And we are talking about Google Kubernetes
Engine for next-gen developers.
Eric, welcome back.
ERIC BREWER: Great to be here.
Thank you.
STEPHANIE WONG: I want to talk about some of the most
common questions that both you and I, and I think a lot of us
here at Google Cloud, have gotten, the first being, what
is the difference between Kubernetes-- that
is, Google Kubernetes Engine in particular-- and serverless?
ERIC BREWER: Well, they're both the future.
So in that sense, they're easy to get confused.
But I would say the main difference
is Kubernetes, and GKE in particular,
are a really great platform for building
a wide range of services.
And that's really the key.
You can build all kinds of services
on top of Kubernetes and GKE.
Serverless, especially classically defined,
obviously, means no servers.
But it usually means functions as a service
or request-reply patterns in particular websites.
And so that is an example, one of many,
of a domain-specific solution.
And in general, when you have a domain-specific solution
like Cloud Run, you could do a fantastic job
for that domain that is much easier to use than Kubernetes.
So if you know exactly what you want to do and it's opinionated
and it's narrow, you should build that as a Platform
as a Service.
If you're going to build all kinds of things,
like your enterprise, Kubernetes is the great base for that.
And in fact, I see lots of enterprises building
internal Platforms as a Service of various kinds on top
of Kubernetes.
And that combination makes a huge amount of sense.
STEPHANIE WONG: So it sounds like if you have a specific use
case that serverless products are well-equipped for, then,
absolutely, go with that.
But what about in the case where you
might start with a serverless product, like Cloud Run, Cloud
Functions, et cetera, and then you decide later on that we are
fully bought into Kubernetes and we would
like to broaden our use cases?
We want to build platforms on top.
Is it possible to have both in your environment?
ERIC BREWER: Lots of customers use
both today in very interesting combinations.
There are certainly customers that
started out on App Engine or Cloud Run
and have moved to Kubernetes because they
want finer grained control over all the details.
That's one reason.
And in fact, they're rebuilding a customized platform
internally for themselves.
There are other groups that use something
like Cloud Run for the front-end services
and use Kubernetes for back-end services.
That also makes a lot of sense because you
can do a lot of data management control in Kubernetes.
There are groups-- I know of at least one
that uses both for different reasons, which
is they have a Kubernetes cluster that
does their main load.
But when they have a hot spot, like a Black Friday,
they actually use Cloud Run to absorb the spikes.
And so there's lots of ways to make this work, really,
depending on what cleverness you want
to play to mix these together.
But they're definitely-- they work well together.
And you can start on Cloud Run and move to Kubernetes
later-- is another really common pattern.
STEPHANIE WONG: Well, here's a thought.
So we've talked about this a little bit
in our previous videos-- about how platform teams want
to use Kubernetes, and yet they also
want to customize their platforms for their needs.
We talked about policy enforcement as an example.
So how should an enterprise use Kubernetes Engine?
ERIC BREWER: Well, in general, a cloud provider
offers more things than you, really, would
like your developers to use.
And what I mean by that is if you're an enterprise,
you have a platform team, and you say, oh,
we're building this kind of financial service,
we really don't want to give our internal developers
all possibilities.
We don't really want them to be in charge of their own credit
card transactions, for example.
That's a highly regulated thing.
It needs to be done very carefully with careful audit
logs.
And so really, what I'd like to do
is give my internal developers a platform
where they can do credit card transactions that
are guaranteed by the structure of the services
to be compliant with all regulations-- and by the way,
in all different countries in which we operate.
And so I see Kubernetes as the way
to build these customized platforms, where they enforce
whatever rules the enterprise cares about through things
like control over project creation,
control over the nodes you use, control over the OS you use,
control over the libraries and repos you pull from.
Those kinds of background controls
are things that are not typically
up to the internal developers to decide, but, at the same time,
provides services framework, possibly something like Anthos
Service Mesh to manage services across these things
and give their developers, again,
the productivity that you want and the velocity of features,
but, again, in a way that's decoupled
from risk around certain features that are highly
regulated, especially.
STEPHANIE WONG: Yeah, and it sounds
like there is very much a culture
and organizational structure in place in which you
have your operators and administrators
and your developers.
Now, we do have a lot of curiosity
out there in the community about advice
for these next generation of Kubernetes developers.
And we've actually collected some of them.
I know that you threw out a prompt for AMA
questions on your Twitter, and so did I. So get excited,
everyone.
We are going to come back in the next video with a handful
of those questions.
So stay tuned.
And thank you so much, Eric.
ERIC BREWER: Looking forward to it.
Thank you.