A conversation with Brendan Burns: What is Kubernetes?

Kubernetes was founded almost seven years ago my guess, depending on when you start the clock when it publicly released or when development started.

It was the three of us, Joe Beda, Craig McLuckie, and myself.

Honestly, we were influenced by some internal systems.

A system called Borg at Google that we'd been using at the time, as well as our own experience with people trying to adopt Cloud and the challenges of people adopting Cloud.

It was hard, it's too hard, right?

Docker came along honestly.

I think without Docker, we couldn't have done it.

All right, so Docker lit this fire, but we had all this experience about where they should go.

So we took the enthusiasm around containers that Docker managed to generate up.

So Kubernetes is an orchestrator for helping you with application development.

When you think about what it takes to deploy an application up to the Cloud or even to an on-premise collection of machines.

You have to package up that application.

You have to distribute it, you have to keep it running, and you have load balance traffic between the various pieces of the application.

Then obviously in an API to introspective and find out what's going on.

Before Kubernetes there were a few systems bits and pieces, but Kubernetes just really mainstreamed the idea of this distributed systems application environment for building and constructing distributed systems that span across a bunch of machines.

I think Kubernetes really succeeded because of our focus on community and ecosystem.

So I think technologically obviously has to work.

But I think that building this really honestly amazing community of people who supported each other, who helped build docs, who helped build tutorials, who went and talked about it in conferences.

Then an ecosystem of companies that were betting their whole company on it.

Startups that are saying like, well, the prerequisite for using my monitoring software is that you have a Kubernetes cluster, that formed a really virtuous cycle.

I think the other thing is that it's a layer in the stack that is at some level supposed to disappear.

So once it became popular enough, everyone's was like, okay, that decision has been made, let's move on.

All right, and so there's a certain amount of value for the broader ecosystem and having a single solution.

Container is one of those words were I think it means different things to different people, or has a really broad set of meanings.

I think fundamentally, it's about taking an application and packaging it.

So building of binary representation of all the different pieces that you need for your application, the software, the configuration files, whatever, just having a protocol for distributing that application around the world.

Then once it starts running on a machine, having a isolated playground for that application to run so that it can't interfere with other applications on the same machine.

So I think those are the three pillars of what became known as containers.

How do I take everything and package it?

So it's exactly the same on my laptop as it is out in the Cloud.

How do I distribute it around the world really easily?

Then once it's running, how can I have an environment where if I have a bug in one component, it doesn't affect another component?

Those pieces are what makes up what it means to be a container.

Although different people have different answers.

Well, I'm an open source fundamentally means that the source code for your project is available under an open source license.

So there's a consortium that defines what it means to be open source, has to do with different open source licenses exist that have different kinds of restrictions on what you can do with it.

If you make changes, if you have to publish those changes.

But fundamentally, from my perspective of what it really means is coming together as a community to build software in the open.

So it's not Microsoft building software, or Apple building software, or VMware building software, it's all of us coming together in a global project.

It's Kubernetes building software as a project out on GitHub that makes up the open source.

For me, that was really important.

It's not just about the license, it's not just about the source being out there, but it's about the community that comes together to build the software.

But I think when we're talking about Cloud Native, one of the things that we're thinking about is API-driven development.

So you're creating stuff with an API.

You're not logging into a machine running commands, you're declaring a state usually these days in some text file like a YAML file.

Then you're applying that state to the world and you're letting some other system take responsibility for making reality match up with your declared state.

So this has been called Infrastructure as code or a bunch of other kind of buds words associated with it.

I think the other part of Cloud Native is this idea of elastic scale, right? That I can immediately get more resources if I need them, I can immediately throw away resources.

I think of Cloud is being a better version of an online computer retailer where like used to be, you can get a computer in a day and you had to go through some return policy.

Well, with Cloud you can get it in a few seconds and you can give it back and immediately.

So run it for two minutes, put it away, don't pay for it ever again.

I think that's a fundamental characteristic of what it means to be Cloud Native because they're now development patterns that assume that I can create a complete copy of my infrastructure and then throw away my old copy without any real effect on me in terms of price or anything else.

That's what it means for me to be Cloud Native.

Well, people keep saying the future of Kubernetes is boring.

Like it's supposed to be disappearing.

It keeps sort of not disappearing.

But I keep thinking it's going to disappear.

That's because it's present in every major public Cloud at this point.

It's become something that people just expect to be there.

So people are really focused on what do you build above it.

I think one of the decisions early on that we made those really foresightful was to make it very extensible.

So that people could add on new components.

So people could make it their own.

I think that's the future is the stuff that gets built on top.

As more developer tooling and as more experiences get built on top, I think, I hope that the underlying Kubernetes bits is kind of fade, like X86 fades.

Where nobody really talks about like what's the processor architecture instruction set that you're running? It's there, obviously it's important, but it's not part of what you think about on the day to day.

I hope that's the future for Kubernetes as well because there's so much more that we need to build.