Technically Speaking

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.

00:56 — INTRO ANIMATION

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. 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.

Hey, Chris, how are you? I haven't seen you in a long time./p>

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 digital 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 another 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 serving 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. But 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 controller, or "Kube cuddle", 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 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.

11:39 — OUTRO ANIMATION