[MUSIC PLAYING]
RETO MEIER: We couldn't get enough of him.
So we brought him back.
Joining us once more is Kelsey Hightower, developer advocate
at Google Cloud.
Kelsey, talk to us about how serverless solutions
help developers.
KELSEY HIGHTOWER: Yes, so I think
serverless solutions for people new to serverless,
it's kind of like we've learned a lot of patterns
from four or five years of Kubernetes.
And all the things you need to do to provide that higher level
interface that you give all your developers
or that you enjoy working with every day, that's where
serverless attempts to start.
So we take some of those patterns
and we give people the smallest interface that they want to do.
So if you think about if a file gets uploaded to a Google Cloud
Storage bucket, you can just invoke your business logic
and execute your code for you.
STEPHANIE WONG: Now, people want serverless,
but they also want containers.
How is Google enabling developers
to have both the velocity of serverless
and the flexibility of containers?
KELSEY HIGHTOWER: That's the thing
that I'm probably the most proud of.
So when serverless is most introduced for first introduced
to most people, they always thought about it
as functions as a service.
You write a single function, an event
comes in, it calls your function.
But there's a lot of existing business
logic that needs a little bit more
than just a single function.
Maybe there's some bootstrapping code.
You got a set of things like logging,
but a little bit more flexibility
and your choice of runtime.
So what we decided to do was take a lot of the learnings
from Kubernetes and allow developers to deploy
their own Docker container.
So any runtime that you want to use, any business logic
that you want, any libraries, and we're
going to execute that container just like we do with our Cloud
Function.
So they scale to zero.
They scale up quick.
And they give you the same serverless workflow
that you're used to without abandoning all the good things
that come with containers.
RETO MEIER: Nice.
So you've talked a little bit about serverless
isn't brand new, but we're changing the way that we're
sort of approaching it.
Can you tell us a little bit more
about how Google is changing that serverless experience?
KELSEY HIGHTOWER: So I think, for us,
is that our DNA has always been around this idea
of this kind of software delivery chain, right?
So this idea that when you build a software,
we like to build it once, we sign those images,
and then we decide where we want them to be deployed.
So that means giving people a bit of choice.
So typically, serverless has been
kind of these proprietary cloud platforms.
Once you're in there, you're kind of locked in.
What we decided to do is make sure that it runs everywhere.
So wherever you as a developer want
to run, just like most Google tools and libraries,
we allow our serverless stack to run wherever you are.
So I think what we're doing different here
is taking some of the things that worked well
in the Kubernetes space and combining them
with some of the developer experiences
that we know that people are looking for.
And it's combining the two.
So flexibility without losing the tradeoffs and benefits
of going serverless.
STEPHANIE WONG: That's great.
So how does our serverless offering help our developers,
and how is it different?
KELSEY HIGHTOWER: I think where it's
different is that you get to use a familiar tool chain that
has been popularized over the last couple of years, right?
So containers are the way most people
think about having full control over their own software.
Then to be able to take that software
and outsource all of the delivery, right?
So security, IEM integration, being
able to connect to things like Spanner and BigQuery,
taking all of that kind of toil away from you,
and just say, hey, checking your containers,
and we'll run them for you.
So what we're trying to do is kind
of make it very seamless from a developer.
Once you go from idea to deployed,
we're just trying to give you that same GCP experience
at the container level.
RETO MEIER: Nice.
Now how do our serverless offerings
give developers a more open and portable offering
so that customers can potentially
move their workloads around?
KELSEY HIGHTOWER: So one thing-- the trend
that has been really prevalent in GCP is in Kubernetes,
we started with Docker, popular open source container runtime,
and then we shipped an open source project,
Kubernetes, which is the underlying platform for GKE.
And then when we thought about entering serverless,
so we've had App Engine for it for almost 11 years now.
And we decided that let's-- what would we do if we wanted
to make App Engine to be more open?
So we decided to start with the Knative project.
So Knative has a lot of serverless components.
You can think of it as a serverless toolkit, things
like bills, a function framework.
And most of that stuff is laid on top of Kubernetes.
So what we've done is we've taken the best
parts of Kubernetes-- again, those design patterns
that we talked about.
How do I just run my application?
We've extracted that out into a high level set of libraries
called Knative.
And there's a hosted version we call Cloud Run.
And we also give you the ability to run Cloud Run on top of GKE.
So the benefit there is that if you
need to do some machine learning,
you can take that serverless workload
and run it on a specialized VM with a GPU or TPU.
So you're no longer restricted to just our serverless
runtime environments.
You now have the whole of GCP opened up to you, even
in the serverless context.
STEPHANIE WONG: And you touched on this a bit.
But a lot of our customers tell us
that they have custom requirements,
like specific run times, custom binaries,
or workload portability.
And more often than not, they turn
to containers for an answer.
Can you talk about how RGKE serverless
add-on allows you to bring serverless to containers?
KELSEY HIGHTOWER: Yes.
So when you think about--
a lot of these abstractions change over time.
We went from mainframe, to physical machines,
to virtualization, to higher level platforms,
like App Engine.
What we now have with the container image, this ability
to build a code that you want, use the runtime that you want,
any version that you want--
and now that becomes a portable bit.
You can run this on a virtual machine.
You can run this on GKE.
You can run this on Cloud Run.
And you can also run it on App Engine.
So I think what the developer gets
is this ability to truly write once
and deploy wherever they want.
RETO MEIER: Now, while we believe
Google Cloud is a great place to run all types of workloads,
some customers, we know that they
need to run on-premises or across multiple clouds, right?
So tell us a little bit more about Knative
and its role in giving developers
the freedom to move stateless containers pretty much
anywhere?
KELSEY HIGHTOWER: Yeah, so our contribution to the ecosystem
started with maybe Kubernetes, right?
So Kubernetes, over the four or five years--
you can see it now-- it's deployed and offered
by every major cloud provider.
Lots of people are already running it on-prem.
So it has wide adoption.
So our strategy of layering Knative
on top of Kubernetes, this allows us
to kind of reap those benefits.
So the tools that you're familiar with,
we layer Knative on top.
So that gives us that portability framework
underneath.
So, no matter where you're running,
whether it's on-prem, different cloud provider, on GCP,
you can get the same APIs, right?
So we talked earlier about automating those APIs, that's
what Kubernetes represents.
And I've always said this.
Kubernetes is a platform for building platforms.
And we've chosen to build our newest serverless
platforms on top of Kubernetes.
STEPHANIE WONG: Can you talk a little bit more
about how Knative provides inventing and integrating
events from Google or third party services
so you can really extend your applications?
KELSEY HIGHTOWER: So the big thing to know about Knative,
it's not just Google's project, right?
So now we have so many contributors--
Red Hat, Cloud Foundry.
So a lot of the things that we've
seen in the eventing space, like what is an event,
how should we accept it, a lot of those open protocols,
like Cloud Events, all of that's supported inside Knative.
So Knative gives you a couple of components.
We call Knative serving.
Run my container.
Scale it to zero.
Start it again when a request comes in.
Then you have the event team piece.
So there's an event.
And what we wanted to do is make an event portable.
So different cloud providers has a different collection
of events, different transports for events.
So we wanted to do is make sure that the event framework was
very flexible.
If you want to integrate with GitHub,
or GCP, or some other service that you have
that you've defined yourself, that's also included.
So what we've done is we've given all of these framework
pieces, and what we've done with Cloud Run is
we've kind of curated the perfect stack for you.
RETO MEIER: Great.
And is there a particular way in which
we're able to solve that problem that you describe,
as like having all of these things
leading to all of these different places?
KELSEY HIGHTOWER: Yes, so I think for us is,
Kubernetes is super flexible.
So what that flexibility allows every cloud provider
to do their own integrations.
For example, on-prem, we come out
of the gate integrating with things like with VMware and F5.
So we abstract away some of the differences
between all of these platforms.
So that's what Kubernetes' job is.
Once you have that set of abstractions,
things like Knative just sit on top
and naively assume that those abstractions are there
and that we can get on with building those higher level
platforms.
So Kubernetes is a huge part of this.
And the community has been doing this work
for over four years of abstracting away
the differences between these cloud providers.
So whenever you build on top of that,
we just inherit all of those benefits.
STEPHANIE WONG: Well, thank you so much again
for joining us today, Kelsey.
KELSEY HIGHTOWER: Awesome.
Thanks for having me.
[MUSIC PLAYING]