[MUSIC PLAYING]
KELSEY HIGHTOWER: Hi, my name is Kelsey Hightower.
I'm a principal engineer working on Kubernetes and GKE,
our managed Kubernetes service and our Cloud
native distributed systems.
Maybe six or seven years ago, I was introduced
to the world of containerization through Docker
and also became a contributor to the open source Kubernetes
project.
And I've been working on Kubernetes since the beginning.
I've contributed code, documentation, and even
wrote a book on the subject.
When I meet a lot of customers that are already
running in the Cloud, a valid response to the things
that I talk about is, well, our stack is already working.
The next question is define working.
And so when I talk about Kubernetes, they're like,
hey, we've been on Cloud for over eight years,
and I'm always impressed by that because in the early days,
most people were very reluctant to go to Cloud.
But once I start digging into their actual setup,
typically it's lots of virtual machines and custom scripts.
Some people even brag about how many lines of code
they use to deploy their applications to their servers.
And I look at them, and I pause, and I ask the simple question,
why?
And what I think has happened over time
is everything that they've learned
has translated into hundreds and thousands
of lines of configuration management code.
But the truth is no one really wants to maintain
that stuff long-term.
So when they asked me why Kubernetes,
I'm saying all of that stuff that you've
learned in the last 10 years, multiply that
by 1,000 companies around the world,
and companies like Google and Twitter and all of us
all contributing those ideas to a central place,
well, that's what Kubernetes is.
And so a lot of companies will take a look at their existing
infrastructure.
Maybe they're spending way too much money
by having one application pinned to a single virtual machine.
If you have tens and thousands of virtual machines, my guess,
you're probably going about 80% underutilized.
Most people in the industry have a hard time
getting to 5% utilization in their virtual machines.
So the immediate value of something like Kubernetes
is simply taking all of those virtual machines.
The truth is you probably only need 3,000 instead of 10,000,
and then letting Kubernetes play Tetris in your infrastructure.
It does a much better job at scheduling how
your workload should be run.
So for many people, just because you were good at
Cloud 10 years ago doesn't mean you're necessarily
benefiting from Cloud in 2021.
And this is where you look at people's roadmaps.
So if you are an infrastructure practitioner,
maybe you work on the platform team,
we all maintain a roadmap.
If you take a quick look at yours,
I bet you'll find things like we want better security.
You want end to end encryption.
You probably want to have a more consistent CI/CD pipeline.
Well, all of those things are currently not working.
And so this is where you start to ask yourself,
do I really go figure out how to build and then maintain
all of those things on my own?
Or do I try to accelerate my roadmap?
The first option is to download the open source Kubernetes
distribution and spend the next 30 years integrating
it and running it yourself.
I think there's a better option.
I wrote a whole guide called "Kubernetes the Hard Way"
that teaches people how to actually do this.
But what's the easy way?
That's where GKE comes in.
And this is what we mean by a managed Kubernetes offering.
And what that does is it integrates everything
from security, storage, GPUs, and networking into something
that's maintained by the Cloud provider.
If you take Kubernetes and all the best practices and time,
you end up with GKE.
So ideally, it's really hard to keep up
with all the advances in the Cloud.
For example, we're constantly coming out with different VM
types and sizes.
We have things like preemptible VMs
that can save you over 40% or 70%
in terms of your compute spin.
But in order to use things like that,
you would have to go and do all the integration work yourself.
What happens when there's a new security vulnerability
in the open source project?
Well, you will be responsible for tracing that
down and patching it yourself and then upgrading
all of your clusters.
But many of our customers have hundreds, if not thousands
of Kubernetes clusters.
So what they can do is use a centrally managed control
plane to do all of those tasks for them.
I think what most customers do is they underestimate
the long-term responsibility of building and maintaining
custom infrastructure.
And when it comes to infrastructure in 2021,
there are some fantastic platforms that are already
built. GKE comes to mind if you want a Kubernetes offering
that's fully integrated.
There is less and less value of building and maintaining
these things yourself over time.
Kubernetes is only as good as the infrastructure
it runs on top of.
And the thing that makes GKE great
is that it's our only container platform.
Look, Google created Kubernetes, and we stood behind it
for the last six or seven years.
We've gone all in.
So if you look at Kubernetes on GKE or inside of GCP,
you'll find all the deep integrations.
For example, did you know that you can actually
share a single GPU across six or more containers?
Well, that's only possible because we've
done some deep integration work to make that work.
So for a customer staring this containerization movement
in the face, what you can expect on day
one is the need to repackage and take stock of your existing
applications.
So some customers may have 10.
Some customers may have 1,000 applications.
On day one, the most important step
is to have a catalog of everything,
and I'm talking about even that stuff in the dark corner
that no one's touched in 10 years.
All that needs to be taken account of.
Once you have an inventory of your application stack,
the next thing is prioritizing which things
need to be containerized first.
Now you're moving on to what we call day two.
We're going to also assume that you're not
going to waste your time trying to run something
like Kubernetes from scratch.
Do not do that.
Now, if you click the button, like I'm recommending,
your day two is going to be very different than some
of the pain you've read on the internet.
Now, what you can do is day two is once you have
a containerized application, your next task
is just to describe how Kubernetes
should run that application.
And that's where your team is going to spend a lot of time,
basically serializing their operational needs
into Kubernetes configuration files.
And then when those things are ready,
you can point them at Kubernetes and start to transition
your application at the proper pace for your organization.
Now you're going to be in a state
where some things will be running in Kubernetes,
and some things will be running in those virtual machines.
And then when you get to day three,
you're going to see a path where you're
going to have a lot of repeatable patterns.
And what those repeatable patterns are,
you can apply back to the rest of your application stack.
And the truth is, some applications will
run much better on virtual machines,
but what you will find and what we
tend to see is the far majority will benefit from running
under something like Kubernetes, where
you can benefit from density and consistency
as you deploy across multiple regions and zones.
I'm going to be honest with you.
Installing Kubernetes or just using Kubernetes on its own
is not going to necessarily make your company more innovative.
But the time savings you get back from using Kubernetes
will.
Let me put this in perspective.
Let's say you only have 100 engineers that
work at your company, and roughly they
work about 40 hours a week.
You only have 4,000 hours to build all the products
and services that your customers need.
My guess, you never have enough people to get the job done,
nor do you have enough time to get the job done.
What if I told you that most companies are spending
about 30% of their engineering capacity
just building the platform?
What we want to do is give you the ability
to take that 30% of engineering time
and shift its focus towards building those applications
and services that your customers actually need, use, and care
about.
The biggest problem for cost for most people
is that their machines are overprovisioned.
For example, you deploy one application per VM.
And typically, during parts of the day,
you might get to some high utilization.
Maybe 60% of your CPU and memory is actually
working to serve your business.
But what about the other 16 hours in the day?
What's going on at that point is,
usually, you're sitting there completely idle.
And unless your team is building a bunch of automation tools
to scale things up and down to respond to your traffic needs,
you're probably just wasting idle compute,
translating to wasted money.
So how does Kubernetes actually help?
Well, number one, there's this concept of bin packing.
Look, it can be super complicated.
But the easy way to think about it
is, instead of putting one application per machine--
and there's a reason why your team is
doing that because it's actually complicated--
what you do instead is you give all the machines to Kubernetes,
and then Kubernetes does a job of packing those applications
on where their spare capacity is.
And when that is full, all your applications are running,
it can automatically turn off the machines you're not using.
And when traffic comes in again, Kubernetes will automatically
spin things up.
But that's where the cost savings come in.
I'm often asked if Kubernetes is the endgame.
Is this the Holy Grail of infrastructure?
If not, what's next?
Well, number one is the Kubernetes API
has become a industry standard.
And I believe that's going to stick around for a while.
But there's one thing that doesn't necessarily need to,
which is the cluster that runs underneath.
This is where GKE Autopilot comes in.
Now, one thing that's nice about Kubernetes
is it allows you to really bin pack and scale
your infrastructure.
The thing is, you have to tell Kubernetes exactly how you
wanted to do that.
And that can also become a form of overhead and management
that you may not want.
And what we've learned over the last five or six
years of running Kubernetes in production
is we can automate that all for you, hence the name Autopilot.
And given that new set of capabilities,
meaning we can scale your infrastructure horizontally,
we can even scale your workload vertically.
And one thing we've managed to do
is eliminate the entire cluster.
So now we can make the VMs disappear.
Now, not to worry, the Kubernetes API is still there,
and you can still use that to do everything for you.
But we will even take care of the cluster provisioning
underneath.
So when you go from running thousands of applications
down to just one, we maintain the infrastructure underneath,
and you don't have to worry about it.
This is the next step on the path to serverless.
And for those that don't need the Kubernetes API,
you might want to take a look at something
like Cloud Run, a completely serverless experience that
allows you to take those very same containers that you were
running in something like Kubernetes or Autopilot
and get rid of the entire cluster
and delegate the rest of that responsibility to us.
Number one, I will make sure that my team understands
the state-of-the-art infrastructure.
And if no one's heard of Kubernetes,
you've got to go solve that problem first.
Step two, I will look at our team's infrastructure roadmap.
And when I start to identify things
that are already existing in the world of Kubernetes,
I got to ask my team why don't we
just move to the industry standard platform
and then innovate there instead of starting from scratch.
Once you've made that decision that Kubernetes
is right for you, I think the world of containerization
gives you the next set of benefits.
One big problem that's plaguing our industry right
now is the security.
No one really knows what all goes into our software.
Who built your compiler?
Where did those third party dependencies come from?
And that's why I think you should make sure
that in any of your strategies, whether you
skip Kubernetes and go straight to serverless,
I believe that the container format will
be necessary in order for you to be able to make
your first step to a secure software pipeline,
to make sure you understand where
all the bits of your software are coming from.
And once you adopt containers, then the entire Cloud
opens up to you.
You can run containers on VMs, Kubernetes, Autopilot, or even
something serverless, like Cloud Run.
Infrastructure is a means to an end,
but it can be extremely time-consuming and expensive
if you don't have time to do it correctly.
So the whole value, the innovation,
the truth is the innovation comes from time.
You need time to innovate, so using something like GKE
will give you your time back.
The net benefit is all that time that you get back,
you can use it for something far more important,
which is innovation, building the products and services
that your customers care about.