(majestic music)
- The Holy Grail for computer science
is where we declaratively state a
problem we want to solve,
and then the computer solves it.
No writing explicit instructions
with difficult or confusing syntax,
just as our low-level
assembly language evolved
into high-level languages like
C++ or Python -
abstraction has always been
about making things simpler
and easier to understand.
But maybe when you hear Kubernetes,
simple and easy might not be
the first things you think of.
(upbeat music)
Any system has low-level interfaces,
but much of the work around Kubernetes
has been focused on how we maximize
accessibility to developers.
Layers of abstraction
make it easier to use.
Encapsulation refers to an
object's ability to hide data and
behavior that are not
necessary to its user.
Kubernetes orchestrates containers
by encapsulating dependencies,
storage, tools, and services to provide
resource and infrastructure abstraction.
The Kubernetes operator pattern
encapsulates our knowledge and expertise
about running a specific
application on Kubernetes
in a reusable way, which makes it easier
to deploy complex applications.
Kubernetes can, of course,
deploy applications, but what's
really exciting is how extensible it is.
When you combine a custom
resource with a custom controller
you end up with the operator pattern
and a true declarative API.
(keyboard clicking)
And since we're talking about
Kubernetes, there is one specific guy
that comes to mind when we're thinking
about where it started
and where it may be going.
(notification beep sound)
- Hey, Chris, how are you?
I haven't seen you in a long time.
- Hey Kelsey.
I was just doing some thinking about
Kubernetes, where it's come from,
where it's going, and so I thought who
better to talk with about this than you?
- Yeah, so I think it's been eight years.
And to me, when people look at
Kubernetes they typically think about it
as this application development
environment or a platform just
for developers and applications.
And if you think about it,
it falls in the same lineage of Linux.
Like Linux is an extensible OS.
If you look at it, you can
use it as a server.
And a lot of people, if they were to
look at the phone in their hand,
it's probably running Linux.
And you can use it to build a mobile platform.
So then if you look at Kubernetes,
we've entered the distro era, if you will.
And Kubernetes to me is an
extensible control plane.
You can go and build that layer for any
other system that you wanna build.
And I think if people were to look at
Kubernetes as more than just an
application platform, they'll realize
its true power and the opportunities
to put different user interfaces
and apply it to different applications and scenarios.
They just knew what it was.
- We've spent a lot of time focused
on application deployment,
lifecycle management, scaling, all of
the things that Kubernetes
is fantastic for.
One of the things that I've really
focused on and the way I think about
Kubernetes is extensibility and CRDs and
the ability to create custom controllers.
But I think you're thinking
at a whole 'nother level.
So tell me what you see in terms of
how Kubernetes is poised to really
fundamentally impact the industry beyond
what we know as this application space.
- When people think about deploying
an app it's like taking my binary in
some package and running it for me.
But what happens about all the other stuff?
Who controls the storage?
Who controls the network integration, the service discovery?
All of those activities are best
handled by a control plane.
So that's what Kubernetes
is first and foremost.
It's a framework and it turns out
it's a framework for building other
control planes too, right?
It's a control plane that actually has
little control planes embedded into it.
So I think once people look past its
initial usage, which is a control plane
for deploying apps, you'll find that you
can actually build other control planes
as well.
- You know, I love the
controller pattern and the loops that
are trying- reconciling current state
with desired state, but what does that
mean in terms of a control plane
to build control planes?
- Yeah. So when we think about a
framework like a control plane,
the roots of this is in this
promise theory, right?
Typically when we think about a
deployment tool that could be a
bash script, you can write a script to
say, deploy this to this server.
And that will be some process
that's being automated.
But when we started thinking about a
control plane it is a bit abstract.
What do we need a control plane to do?
Well, we need to have some intent.
So in the Kubernetes world people
talk about YAML files quite a bit.
And so in this control plane,
it says I have a place to store
the intent and that's where things
like etcd fit in, right?
So we have an API server and you have etcd.
Given those two things you have the
the fundamental building blocks
of a control plane.
But I think what people have to do
is kind of have a, kind of
be able to visualize this, right?
So the premise underneath this as promise theory,
is important, people understand it.
Like, if you think about like a-
the postage stamp, and that envelope
that you put your mail in, right.
That post-it stamp says, hey,
I paid my postage and I
want it to declare something.
Like it's coming from this place
and I want it to go to this other place.
So that declarative statement you've
just made, and now we're gonna give it
to the distributed system, in this case,
it's the post office.
And that post office has a bunch
of controls, there's locations, there's
mailboxes that have regular pickup schedules.
You can go drop the envelope and there
is gonna be some kind of promise.
So if you take it into a location
they'll look up the source and
destination and say, look, we can
get it there by Tuesday.
Now for all, you know,
it may or may not get there by Tuesday,
but there is a promise that it will,
and here's your tracking number.
And then there's a bunch of loops-
really people, and these independent
controllers may be responsible for
driving the trucks, sorting the mail,
and they're gonna do whatever it takes
to get that to the other place.
And the real key to understanding
Kubernetes is that, that promise,
unless you change it, unless you
redeclare a new address for the go-to,
even if one of those mail trucks
breaks down along the way, another
mail truck is responsible for coming,
picking up that letter and
taking it to its final destination.
Kubernetes gives us many of those facilities.
So when you think about what type
of control planes I wanna build, well,
that same facility I'm in the serverless space.
I work at a cloud provider.
And so we need a way for people to
communicate what they want to happen
with their applications.
- Yeah. I like that.
And I was first trying to picture you
with your postal service hat on,
but with a cloud hat it really
makes a lot of sense because you're
you're separating the implementation
from those promises and that implementation,
these can, the controllers and controller loops,
that's the extensibility of Kubernetes.
And the details around exactly how that works
while one, they could evolve over time
and two, it's maybe not your core focal point.
'Cause I, I know you've really thought
from the developer point of view,
hey, if you're digging down into "kube-control"
or "kube-cuttle", or kubectl
whatever your preferred pronunciation is,
you're probably going down a path
that doesn't meet your application needs.
And you're sort of taking that same concept one step further
at this control plane level.
- Yeah. So one thing I like to think about is,
these control planes,
at least the one that Kubernetes presents,
gives you the opportunity to serialize your culture.
Dig into what I mean there.
If you're a developer and you find out a
great way of deploying an app and
hooking it up to a load balancer
with a specific config.
But if you step back from that, you can
now take all the things you've learned,
and create a new controller, right?
That's that little thing that's in that loop.
And then you can create an
interface, a data model to say,
hey, all our developers need to do
is tell us what application they want,
and maybe our controller can work across multiple regions.
This is a little bit outside
of what Kubernetes does by default.
So the way you have to look at this
is that all of the actions we do
when we discover patterns, we can turn
those into new control plane components
and introduce a new control plane
for carrying out those actions.
You can serialize that learning to a
new controller and open it up and allow
your team to interact through that API
versus coming to you all the time.
- I love that notion of serializing expertise.
I often think about it as an
encapsulation, like leveraging somebody
else's expertise and we've been on this
mission for years or decades, even,
of trying to figure out ways to reuse
somebody else's expertise, whether it's
object-oriented programming, or
service-oriented architectures or
microservices, and taking this kind of
through the extensibility of Kubernetes
into the control plane,
I think that's fascinating.
And serializing expertise, I mean, it feels unlimited
and clearly there's application- the application world
that Kubernetes thrives in.
- The whole point of this is that Kubernetes
by itself isn't all that interesting.
It's only what we do with it.
And there's a few stories that come
out-of-the-box and you can read those,
but they get boring pretty fast.
But then if you look at it
as a blank sheet of paper and you're
willing to take all your expertise.
so if you're a network administrator,
maybe you go make a CNI plugin
to take everything you know about
networking and just abstract it away,
so that a developer who needs an
IP address or to live on the right
network segment, doesn't really
have to think about it.
If you're in operations and you know how
to roll out software safely over
multiple regions, you can make a controller for that.
You can name it, the multi-region deployment controller
and take all of your expertise, serialize it into that thing
and share with other people.
And lastly, if you harness the power of open source,
then you can get a whole community of people
to do the same thing and then share that knowledge
and propagate it through these systems
and we just happen to call it Kubernetes.
- I'm seeing a new meme. We had, there's an app for that.
Now it's, there's a control plane for that.
Kelsey really appreciate your time.
- Yeah. Thanks for reaching out.
- When you're thinking about abstraction
and encapsulation, Kubernetes supports
that with extensibility and broad reusability.
So you don't need to create your own
control plane from scratch.
We understand the role Kubernetes plays
in application development and we're
just starting to realize its potential
to build and develop control planes.
The future includes bringing all of
our expertise together while building
communities around control plane
abstractions to shape next generation technologies.
And this puts another waypoint on
our map and search for the Holy Grail.
(upbeat music swells)