The Changelog: Software Development, Open Source - The impact and future of Kubernetes (Interview)

Episode Date: February 2, 2018

From KubeCon + CloudNativeCon 2017 — Brendan Burns (Kubernetes co-founder) and Gabe Monroy (creator of Deis) joined the show to talk about the origin, impact, and future of Kubernetes and cloud infrastructure.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. Error monitoring is provided by Rollbar. Learn more at rollbar.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Command Line Heroes, a new podcast from Red Hat. In this podcast series, you'll hear true epic tales of the developers, the hackers, and the open source rebels revolutionizing the tech landscape. Here's a preview of episode number three, The Agile Revolution. I'm Saran Yadbarek and this is Command Line Heroes, an original podcast

from Red Hat. Today's story begins in February 2001 and it's set at a ski lodge in Utah. We turned up at a lodge, you know, the pine beams and the fireplace in the entryway. We got there the night before and we basically just sat around and talked about what we're going to talk about. And the next day we turned up and we'd reserved a meeting room. We took the tables and moved them out to the edge and we just put the chairs in a circle or an oval so, you know, we could basically be facing each other and, you know, somewhat more open. These guys were open source developers, so staying open was kind of their thing. That was Dave Thomas. Dave and 16 others got together at Snowbird Ski Resort that winter,

not to ski, but to talk about what was wrong with the developer's world in the 1990s. I say talk, but argue might be more like it. They had originally met at a conference called OOPSLA, Object Oriented Programming Languages and Systems. And it was actually at that conference that they realized they all agreed that creating software was messy. They just hadn't agreed on what they should do about it. So the meeting on the mountain at Snowbird, that was where they were going to try and nail down a solution to that problem. The agile revolution and the resulting methodology has impacted every single one of us. Your epic true tales, just like this one, of hackers who transformed tech from the command line up.

Subscribe where you get your podcasts or visit red.ht slash command line. Once again, everyone. This is the ChangeLog. I'm your host, Adam Stachowiak, Editor-in-Chief of ChangeLog. Today, I'm talking with Brennan Burns and Gabe Monroy at KubeCon 2017. We talked about the origin, the impact, and the future of Kubernetes and cloud infrastructure. Let's kind of give an intro to both.

I know you're both well-known, but let's start with you. Kind of give a backstory, kind of who you are to Kubernetes, so to speak. Sure, sure. So I am one of the original creators of Kubernetes, one of the people who wrote the original prototype that sort of was the pitch vehicle that got everybody involved in saying that we should do this and sort of set the ground rules for the project. And been involved in the beginning, sitting on the IRC channel, talking to people, going out to conferences and meetups and kind of hitting the pavement for a long time

to kind of drum up a lot of interest. You know, I look around at this conference and there's a lot of really interested people. And it wasn't very long ago that I had a lot of people asking me, like, why the heck they should be interested in this thing. So it's kind of an interesting turnaround. How long ago was that, one of you? Oh. Not being, you know, whether they should be.

I mean, I don't know. Like, it depends on who you talk to. Three? Certainly two years ago, but even a year, a year and a half ago, I think you ran into people who were still, and I think, obviously, still throughout, there's a lot of people who haven't necessarily, if their thing is working for them, that's great.

There's no need to change. But definitely early on, there was a lot of, I think people were just sort of still kind of getting used to the cloud and virtual machines and traditional tools like Chef and Puppet. So that's all of a sudden all this new stuff. It's like, oh, I have to learn all this new stuff. What am I going to do there? So that was an interesting time doing a bunch of meetups. It was a lot of fun, though.

It was a lot of fun to get out of your shell and go and meet with a bunch of different people from different places, different experiences. Get to know them, get to know the kind of products they want you to build. So for the listeners sake, it's safe to say that you've been here since the beginning. Yeah, I would say I've been here since the beginning. I think a lot of the technology stretches back further than that.

It's from experience inside of Google. It's from stuff that's been in the Linux kernel since 2008 and work that's been done in Linux kernel. And even further back, I mean, I did this talk a while back about sort of like the history. And you can point back to like chroots in Unix in the late 1970s as sort of being the beginnings of containers, right? Right.

And so I think that it's important to point back and know that this is not an original idea. This is a collection of tools that have put together a lot of different ideas that people have had over the years. And then so now I'm a distinguished engineer at Microsoft and running a lot of the container and DevOps stuff that Azure does. Very cool. And Gabe, you, what's your history,

I guess, with Kubernetes specifically? So I kind of come at it from a different angle from Brendan. So my history really comes from the developer experience angle. You know, I was doing some consulting in New York and 2008 happened and it kind of evaporated overnight. And I took, you know, all the commonalities that I was seeing around, all the different companies I was working with, and it was all around deployment automation being on fire everywhere. So I started a company called Optimand, and I was building tooling to make deployment automation easier.

It was basically running around and adding early CI systems and Debian packaging and a bunch of stuff to automate software delivery at a time when that wasn't commonly done. And from there, I sort of evolved and that evolved to sort of pass and created this project called Deus, which turned out to be really popular. It was more or less Heroku, but running on your own servers, which is a very common refrain we were hearing from people back in kind of the 2009, 2010 timeframe. But I had the interesting experience of having to replatform the container-based thing. And actually, early involved in the container ecosystem, close with Solomon,

and he was one of the largest external contributors to the Docker project for a while, just before it became popular, only because we needed it for the Deus project. And what ended up happening over time was every orchestrator that we tried to platform it on, it just didn't work and something was wrong. And that eventually led me to Kubernetes. And I remember, I think the first time I ever talked with Brendan was about

extending the Kubernetes API. And I'll never forget, he's like, Oh, yeah, he's like, I was on a plane or something. And I whipped, I think you said, SREcon, I was Dublin, going to SREcon in Dublin, and I'd done this stuff. And he did the TPR, first pass at TPR as the extension model on the plane. He's like, I'm gonna push this branch up. He's like, you guys take a look at it. And me and Matt Butcher, who's actually the architect on Helm, were super excited to work with him on it. And yeah, so from there, ended up joining Microsoft

by way of an acquisition seven months ago. And now I'm sort of Brennan's counterpart on the PM side, working on the Azure Containers portfolio. So it's AKS, the ACI, the service broker stuff, dev tooling, lots of different things we got in the hopper. I think it's interesting the perspectives here that you sort of like represent the end user, so to speak, to a degree. A user of Kubernetes to build a platform on, pre-Kubernetes even, trying different platforming tools, different orchestrator tools to build Deus on.

And eventually, my perspective from it isn't as a user with Deus, but it seemed like Deus was trying to catch some steam, but it caught a lot of steam with Kubernetes. That's what it really solidified in making it easy to use. I think it was one of the first PaaS platforms to realize that the future came in replatforming on top of container orchestration. I think now, a year and a half, two years later, it seems obvious with Cloud Foundry and with OpenShift and others, like replatforming on top of container orchestration. I think now, a year and a half, two years later, it seems obvious with Cloud Foundry and with OpenShift and others, like replatforming on top

of container orchestration. I think Deus really saw that early, and I think that caught a lot of attention and light. Yeah, I think one of the interesting things to me is how the developer experience of the time when Deus was popular, it's kind of fallen out of favor in a lot of ways, right? The 12 factor is pretty limiting, and Kubernetes opened up a lot more opportunities. And so we ended up kind of shifting our focus to things like Helm and Draft and Brigade

and some of the newer stuff that's a little bit more Kubernetes native in its disposition. And I think what you're seeing from Brendan with Metaparticle is taking that jump a to take in that jump, you know, a little bit further. And I think it's really tricky with developer experience, because on the one hand, you want to be innovative, right? But if you go too far, you're going to lose people, right? And I think if you don't innovate enough, people are going to be like, oh, well, that's not compelling enough for me to drop whatever my current thing is. I think Deus definitely hit a sweet spot in kind of where it was at the time. But I think in a way we've kind of, as an industry, moved on from that a bit. Yeah, I think that's definitely the case.

What's the state of Deus right now? I know it was an acquisition seven months ago. What's the state of the company, the project? Because it's like a company and then a project in the same, which is somewhat confusing to most people. Yeah, it's an open source project. And what's really cool to me is we've spent a lot of time trying to put proper governance around it and even small things like semantic commit messages so we could write change logs.

And a lot of that stuff to really just try and get a community of maintainers to step up. And what I'm really excited about, there's a group called Team Hefi or whatever who is sort of taking on the Deus workflow project and driving it in a new direction. And I'm really excited to see that work taken off. It's been highly active. So yeah. And I would say the Deus team itself, like the engineering team from the company has been, they are a core part of the Azure Container Service team at this point, responsible for a lot of the engineering work that went into the AKS launch that we did recently,

as well as the open source projects that we've launched recently. Kashi, this GUI for Brigade, it's a workflow engine. The draft tooling that we announced a month or so after the acquisition. So that whole team is contributing to both the core Azure containers experience

as well as open source tooling that makes Kubernetes better regardless of where you're going to run it. Yeah, and even things like the open service broker, which interestingly, you know, derived, we started thinking about it first at Deus as a past thing because it was a Cloud Foundry-ism. And when we were, you know,

platformed on top of Kubernetes, we're like, well, there's really a better way to solve this in Kubernetes. That linked us up with Red Hat and Google, and we all kind of worked together. And I'm really excited to see things like the open service broker stuff landing, not just from Microsoft, but also from folks like Google and Red Hat. I mean, everyone's talking about this because it's a pretty important part of the modern stack. Was that announced here at the conference? It was, yeah. I didn't catch that announcement yet.

Can you give me kind of an overview of what that is? Yeah, sure. The general idea is that just because you can run something in a container doesn't mean you should. Right. And so things like data stores, often the operational characteristics of a hosted cloud service, Azure Cosmos DB, for example, are going to be much more appealing to a container-based equivalent. And yet, people want to be able to use the Kubernetes APIs to manage that stuff. So how do we build a bridge between Kubernetes and this world of Azure services, or even on-prem services, Oracle databases, things like that? The Open Service

Broker API has some verbs, provision, deprovision, bind, unbind, and give me the catalog, right? And that's basically the broker, right? That's it. And so what we did was we built a set of Kubernetes resources and Kubernetes controllers that can manage the lifecycle of apps. And what you get at the end of it is a Helm chart where you can Helm install WordPress, and it looks and feels just like any other Helm chart that you would install. But where there would be a MySQL container, you instead have Azure database for MySQL. But the lifecycle management and the tooling is exactly the same. Very cool. So I'll be going back to a little further back in the past.

How many years has it been since the birth, I guess, public birth of some sort with Kubernetes? How far back does it go? It's about three and a half years. It'll be four years in next June. Four years. And so I think pre-call, I don't know if those made it into the actual audio that would go to the listeners ears or not, but Brandon, when you said you can remember a year, year and a half back even-ish where people were still questioning Kubernetes. We're at a point now where to me, and maybe everyone else is thinking this too, is like, Kubernetes is one.

It's definitely, you've got a conference that was 1,000 people last year, 4,000 people, 4,200 people this year, significant growth, a lot of buy-in from worldwide partners, members in the CNCF and so forth. So it's definitely one. Can you kind of, as somebody who's been there since the beginning, shed some light on kind of where you came from and where you're at now? Yeah, I mean, it's really incredible to see. It's humbling, I would say.

Did you expect it? I mean, is it a surprise to you? I mean, I know you're good and the team behind is good. I don't think you can ever expect this kind of stuff, right? I mean, I think you have to. This is a shift. You have to go into it and believe that you're going to work hard and hopefully the right things are going to happen. But you, you know, I don't know that you ever take it for granted. Um, I, I think that, you know, there was a moment, I really actually

remember a distinct moment about a year and a half ago, I would say maybe a year and three quarters ago where I kind of felt the wind. It's like the wind switched from being in my face to being at my back. And it was sort of just this intuitive sense of you've crested the hill. And you're not done, but it's getting easier. I still think that there are a lot of people out there who are thinking about container orchestration and still sort of wondering what's the value prop for me. So I think we're still talking about container orchestration,

but I don't think we're going to talk anymore about what container orchestrator to use. I think we kind of always knew that that was going to happen for some API. At some point, someone was going to. It just doesn't make any sense, right? Like, if you're a monitoring company, if you're a developer, like, you don't want there to be multiple APIs for this. You want there to be one API because then you know. I remember we had all these discussions, and Gabe knows this because he actually took Deus

and platformed it on a bunch of different orchestrators before they chose Kubernetes. We talked to people, and they said, which one am I supposed to target? I'm a monitoring company. Which one am I supposed to target? We don't have those conversations anymore, and I think everybody's happier.

The developer ecosystem is happier for having that. I kind of always said there would be sort of a POSIX standard here, and I think that's what we're seeing emerge. And now the exciting thing is, okay, if this is a commodity, if every public cloud has this as a service, what do we build next? What do we build on top? And so I think that's the other exciting part, is that we can finally sort of put the orchestration API behind us.

And it was never intended to be the final API. We need to start thinking about what are the layers we build on top. And that's really exciting to me. Do you have any insights into what's next then? Well, so, I mean, Metaparticle that I talked about yesterday is something that I think is important. Do you want to give a breakdown real quick? Sure, yeah. So Metaparticle, it's actually an independent open source project at metaparticle.io. It's really

trying to, I would say, bring distributed systems to people who might not otherwise be distributed systems developers. Another way that I've said it before is like visual basic for the cloud, right? Like how do you have that kind of an experience where you can think about the concepts of cloud native computing, but not necessarily the details of, hey, there's this YAML file here

and there's this Kubernetes object. Maybe I just describe my system as having four replicas and I want you to take care of ensuring that you, you know, in code, I'll say I want four replicas and you take care of figuring out how to deploy it and how to put a load balancer in front of it and stuff like that. I think that there's always been this inevitable trend in configuration management and actually we talk about this a lot with the Helm team around configuration management gets more and more programmatic and eventually it turns into a bad programming language. And I think that at some level,

we should just admit that configuration is code. People have said configuration is code, and I think we should admit that, well, if configuration is code, maybe you should just write it in a real programming language. There's all of this tooling around unit testing that we've built, all of these practices around writing software code that don't extend

into the way we configure and deploy our applications at all, right? I don't think that anybody, I just, you know, someone pinged me and said, I was just starting to think about what it meant to unit test a Kubernetes config, right? It's kind of crazy that we have 20 years of people thinking about unit testing code, and yet we're having to reinvent it for configs. Like, why? We should just go to a place where there's frameworks, there's UI, there's all of the kind of stuff that we expect, code conventions, all of this stuff, and we can express that in code.

And I think if you do that, not only do you end up with a better system with one source of truth, but you actually also build a more accessible system. You can have people who might otherwise just be front-end JavaScript programmers who are starting to think about deploying distributed systems. I think it's the only way that we scale the industry to the number of systems that need to be built. So I think that's one of them. I mean, I think it's like, maybe like Kubernetes at the beginning, it's an experiment. It's an idea. I want to start a conversation and start a community. I don't know that it'll be the one, but I think something like it will be the way that we build systems in the future. This question is more for either of you, really.

Just kind of teeing off what you said there is how we got here. Can you go back into the history of Kubernetes and the community, not just the technology, but the community, the impact? How did we get here? What were the right recipes that other open source would-be's of Kubernetes?

Maybe there's not a repeat, but there's somebody out there looking to what you all have done around the technologies, around the community, around the governance, even around joining CNCF and Google's perspective and now Microsoft's perspective on containers. I can sort of talk about that a little. Sorry, Gabe can give his perspective as well. I was a student of the FreeBSD Linux wars in the early 2000s. And when I was thinking about community and technology and how technologies win, I thought a lot about that.

And, you know, I think Linux in that world won because it was friendly and open and it was an ecosystem that you could build on. It didn't win. There are no technical reasons why it won, I don't think. It won because of the community that it built and it won because of the ecosystem that developed around it. And then the technology came afterwards. People were like, oh, okay, it's won. Let's go in and harden security.

Let's go in and do all of these things. And so that was part of it was that it's not okay to just build a community. You have to build an ecosystem. You have to do a good job of sort of telegraphing what you are and what you're not and staying to your commitments and saying, you know what, this is the line where Kubernetes stops, and this is the line where, you know, and I think we did that with Helm, actually. Like, I had conversations with Gabe where we said line where, you know, and I think we did that with Helm actually. Like we, I had conversations with Gabe where we said like configuration management, package management is something that Kubernetes is not going to do. We're not going to pull that into the core. That's

going to be a project that lives on top, gives space for an ecosystem to develop around you. I also think I went into it with a real, a real humble attitude, a real, like every single question is important kind of attitude. I think that's incredibly important. Also, it makes it a welcoming community. I think I'm really proud of the community that we've developed. I think it's pretty unique, honestly, in tech in general, in terms of the degree to which it welcomes people in. I think that's critically important. And it was, I hope hope a big part of the success as well. I don't know. What do you think about the perspective since you kind of come at it as a developer user

experience, implementer, kind of end user perspective? Because you weren't involved in the creation of Kubernetes. You were involved in building something like a pass and needed an orchestrator the entire time. And here comes Kubernetes. Can you kind of share your perspective on that? You know, it's interesting to me. One of the things, before I joined Microsoft, I would pull up a quote from the Borg paper. You know, a lot of these systems are sort of inspired by the way Google was managing infrastructure internally.

And in the Borg paper, like right in the first part of it, they call out the reasons why they built it. And there's three things they call out. The first is they wanted to empower developers for self-service. They wanted developers to be able to deploy to these large clusters without having to involve ops, for example. The second thing is they wanted to build software that was extremely reliable and resilient to underlying infrastructure failures. And the third thing was that they wanted to be able to throw hardware at the problem to scale out, right? So if there was a scale event or, you know, they needed to, you know, distribute a workload, they could just add

capacity and everything would take care of itself. And what's interesting to me is I think that, you know, though not all companies operate at that scale, Microsoft scale, Google scale, that kind of scale, those three things are still important to everyone. And especially as we're, the reality is there's only so much compute power you can pack into one server. And as you get the benefits of distributing this stuff out and self-healing infrastructures that eventually converge, declarative models for how you want to manage this stuff. This really impacts folks who are operating at 20 server scale, as well as many thousand server scale.

So I was enticed by that proposition. And I think that we still have a lot to go on that first thing, the empowering developers. And I think that my big takeaway from this conference, including not just Brendan's keynote, but also, you know, Kelsey this morning, talking about how, look, you know, we still, and Michelle Nurali actually at the keynote before talking about, look, Kubernetes is still too hard for developers. So I still think we've got a ways to go there. But the good news is that, you know, on the other dimensions, I think we're actually

in a pretty good place. Brendan and I actually were joking the other day that when we start talking about enterprise security features like RBAC and you know, policy and governance, you know, you know, the project is like moved on like from its phase. So, I think that's a good thing to see, right? Cause it means things are maturing. this episode is brought to you by Google Cloud Platform and their awesome weekly podcast where Google developer advocates answer questions, get in the weeds, and talk to experts, customers, and partners about GCP. Here's a preview of episode 111 where Mark Mandel is asking Sam Ramji about products he's passionate about in the future of cloud.

Are there particular technical products that we have or potentially passionate about in the future of cloud. Are there particular technical products that we have or potentially may have in the future that get you really excited? Anything you're particularly passionate about right now? Oh, boy. Just pick one. I was going to say, clearly I'm not a very passionate person. I'm really lucky I get to care about all the things I'm doing. There's a lot of real interesting things happening in terms of how we take code,

which is a developer's set of intents, and turn it into running production systems that developers and operators can both collaborate on. There's a whole chain of technologies there, both first-party technologies and third-party technologies. Third-party like Spinnaker that we've gotten into. It's an open-source project that was started by Netflix, and we've gotten really involved in it. It's a really nice way to do multi-cloud computing. And all of these things really need to come back to giving developers control of exactly how they want their code

turned into an artifact like a container, how they want it structured into services and pods, and where they might want to run it. So I think part of what brought me to Google was this core belief in open hybrid cloud. When I left Cloud Foundry, I had spent two years committing all of my heartbeats to putting technology back under the control of the companies that use it rather than the companies that sell it. And part of what brought me here was Brian Stevens said, our mission is to be the

open cloud. I said, you must be kidding me. That doesn't make any sense. Every hyperscale cloud provider is clearly an ambitious monopolist. Not at all, right? So when we look at this. So if you're looking to move to the cloud or generally interested in deeply technical cloud-focused conversations, check this podcast out. It publishes weekly, and you can subscribe in Apple Podcasts, Google Play, Stitcher, YouTube, and more. Head to gcppodcast.com and look for the big subscribe button at the top right hand corner once again GCP podcast calm and by DigitalOcean DigitalOcean recently announced new highly competitive

droplet pricing on their standard plans on both the high and the low end scale of their pricing they introduced a new flexible $15 plan where you can mix and match resources like RAM and the number of CPUs, and they're now leading the pack on CPU optimized droplets which are ideal for data analysis or CI pipelines, and they're also working on per second billing. Here's a quote from the recent blog post on the new droplet plans, quote, we understand that price to performance ratios are the utmost consideration when you're choosing a hosting provider and we're committed to being a price to performance leader in the market. As we

continue to find ways to optimize our infrastructure, we plan to pass those savings on to you, our customers. End quote. Head to do.co slash changelog to get started. New accounts get $100 of hosting credit to use in your first 60 days once again at the do.co change log so Let's talk about the, I guess, the acceptance of it and who's using it. Because I think at this conference, my eyes was open to a different type, I guess, of user, which I really hadn't considered. But I'm not as close to this project as you guys are. But it's like you've got people who are accepting the cloud and then you've got traditional IT, which is present here more than I've ever seen at maybe the kind of tech conferences I've gone to over my years. I see a huge presence of actual IT, not just cloud application developers who ship to the cloud and are in this new world.

We're sort of like old school virtual machines like behind the scenes, behind firewalls, that IT is present here looking to new ways where Kubernetes is taking over what they've done before. And in some ways, they're kind of scared of it. Well, I don't know. I mean, I would hope that they're not in the sense that I actually... Well, not so much scared of it. Let me clarify what I mean by scared is that it moves so fast.

They're used to deploying and chilling out and just sort of maintaining, not in a bad way, but that's sort of like the older IT world. And that's not here with Kubernetes. Kubernetes is fast moving. Yeah, although we've talked a lot about how much it needs to slow down. And so I think that there is a component of once you're starting to talk about those enterprise features, you're also starting to talk about, hey, maybe, I mean, it's great to have a three-month release cycle, but, you know, maybe if half your customers aren't going to adopt your three-month release, what's the point?

But I would also say that, you know, I think that as much as we talk about Kubernetes empowering developers, I think Kubernetes actually also really empowers operators, even traditional machine operators, because the whole purpose of the technology is to provide this abstraction boundary between the developer and the machine, right? And so just like I can deploy apps and not care what machine they land on, that makes a reliable app. I can upgrade machines and know that I'm not going to impact customers, right? If I'm an IT ops and I want to roll a new kernel, I don't have to go talk to all of my application owners and convince them and try and say, hey, please, could you reboot your app? We need to do this security migration. No, I just go through the cluster one by one, do the upgrade, reboot the machine, do the upgrade, reboot the

machine. And I know that the Kubernetes infrastructure will move those end user applications around so they won't even notice. They won't even know that I went and did a software upgrade across my entire OS. That's a hugely empowering thing for a traditional IT developer. I think that separation of concerns is actually one of its real strengths. We think of it as being developer-oriented technology because at the end of the day, it's a developer-oriented API, but the abstraction boundary and the isolation works in both. The decoupling works in both directions. And so I'm actually not surprised at all that there are more traditional IT people here.

Because if I were them, I would adopt this in a heartbeat because it's going to make my life dramatically easier. Okay. Gabe, any feedback on that? One of the big things that we're seeing from those traditional IT folks is the desire to lift and shift workloads into containers. I've been present for some pretty shocking, you know, the idea that you could go take a bunch of existing legacy Windows applications and in a few days get those things wrapped up in containers, moved over to an orchestrator, and get all the benefits of the self-healing system, node failures, the workloads are going to move around,

the applications are much more resilient, you get to go back and decommission a bunch of old servers and hardware, maybe you throw a cloud move into the mix. I mean, that stuff is really, really enticing to traditional IT orgs, right? And these are things that container orchestration makes possible. I definitely agree with Brendan. There's a lot to like here. I think we have to be conscious that container orchestration is sufficiently generalized

that modern cloud-native microservice development that we associate that with Kubernetes very closely, there's actually a lot of other uses for this stuff. IoT being another one. I mean, lots of different things. Machine learning. I mean, there's lots of different things that you can use this for. And I think we're just scratching the surface of that.

Yeah, I think that's definitely the case that I see people with, maybe they're running a binary that they don't even know how to recompile from an old version of Linux. And suddenly with containers, they know that they can upgrade the kernel, but keep that whole thing working

and package up all the libraries and all that. They can effectively run like a Red Hat 4 binary on top of a modern Linux operating system. That's hugely compelling for a lot of IT operators. So what do you say then when you said before about slowing down? In a press conference yesterday, none of you were there, I don't believe.

I didn't see you there at least. A fellow asked the question of LTSing Kubernetes to the point where some IT can, like you had said, implement it, there's a new release, have some sort of schedule where this will be supported for a while. You can kind of depend on certain APIs. You can build on certain things.

Is there any conversations around that kind of slow-moving pace or not slowing to the point where you're not innovating and moving fast, but to the point where your release second can actually adopt some users? Yeah, I mean, I don't think that we've, we haven't had the conversation around a formal LTS. We do backport patches, important patches, not just to the previous release, but actually several releases back and so we do do some of the sort of more longer term support things that you might consider

into the past releases but that probably buys you a year maybe you know conservatively that would buy you a year before mostly the project would throw up its hands and say sorry yeah upgrade um i i do think we're gonna have to do that kind of stuff i mean i think maybe mostly the project would throw up its hands and say, sorry, we should upgrade. I do think we're going to have to do that kind of stuff. I mean, I think maybe looking at the way that Ubuntu does long-term support, you know, with a long-term support release and then a bunch of smaller releases along the way that you can use if you want, but they're not the long-term support releases, may be the kind of model that we need to move to.

I do think, though, that in the move to cloud, one of the things that I think you're seeing is a move towards more auto-upgrading systems. One of the analogies that I draw is people used to update their browser. Now people don't update their browser. The browser just updates itself. I don't even think about that anymore.

Nobody even thinks about it. You couldn't even tell me. I guarantee you, you can't even tell me the version of The browser just updates itself. I don't even think about that anymore. Nobody even thinks about it. You couldn't even tell me. I guarantee you, you can't even tell me the version of the browser you're running. 75. Yeah, who knows? That's how many versions I have. That's how much you pay attention to it. And so I think there's a degree to which if we're good about backward compatibility

and we're good about making sure that what you did last year still works, people aren't going to care as much about what version of it is in an AKS world where we're delivering the Kubernetes API as a managed service. So I think it's a little bit of both. I think we're going to have to do some of that, but I think also as people enter into the service, Kubernetes as a service world,

maybe they're not as worried about that stuff. Maybe let's talk about something you mentioned yesterday in your keynote, which I thought was pretty interesting, was this being able to scale to 100,000, no, 100 million, not 100,000, 100 million developers. Can you kind of, we'll link up to your keynote on video, but can you give maybe a two-minute overview of what you meant by scaling to that, the scale at which GitHub is moving and open source is moving and what that means for, because we said earlier, one of the key components of successful Kubernetes,

cloud native, is community. And that means more developers. For sure. And I think one of the reasons we've invested, I mean, Gabe mentioned about third-party resources. Like, I started to work on third-party resources before we even hit 1.0. Because it was clear even then,

I didn't try and merge it until after 1.0. Because it was clear even then, I didn't try and merge it until after 1.0, but it was clear even then that extensibility and enabling people to build and integrate with Kubernetes without being in the core of Kubernetes was going to be critical to our success. We were already seeing the strain points of the community, and we were, I don't even know, probably at 100 contributors at that point, not the point not the thousand plus that we have now and

so that's a big push making sure that we can effectively continue to innovate and iterate on the ecosystem without having to change the core code base as much and and that's a that's a huge part of scaling But I also think that we have to start considering that the people who we are trying to appeal to are not necessarily going to be distributed systems experts. I think up to this point, we've basically assumed that you have some degree of experience with delivering reliable systems at scale

if you're going to come play in the Kubernetes world. And if we're going to go forward from here, we have to not make that assumption and maybe separate out. Maybe if you're in the core, you need to do that. But if you're building on top, you should be able to consume abstractions that make sense to you

at the level that you want to build at. Brennan and I talk a lot about this idea from my past heritage, easily for me to color it all in past, but talk about this idea of verticalized pass. And I think that part of getting to 100 million developers is going to be crafting a set of experiences that are unique, right, that are targeted at different audiences. And some are going to be GUI-based, and some are going to be CLI-based, and some are going to be editing code in IDE, and others are going to be, you know, who knows, right?

But, you know, there is no one-size-fits-all answer to all the problems that we're going to need to solve going forward. So I think approaching this thoughtfully, you know, with an eye towards principled architecture of the different layers is what's going to allow us to set up a really resilient foundation in order to build the type of experiences that, you know, frankly, society is depending on us to build. Yeah, for sure. And I think that when someone once said it's the most important thing in any project is knowing what you are not. It's not knowing what you are, it's knowing what you're not. And I think if you set those things up the right way and you resist the urge to try and become everything, then things up the right way and you resist the urge to try and become everything,

then you build the right layering and you build the right modularity. I think that's one of the guiding posts I try and live to. So maybe in closing, let's talk to those out there who've heard the term cloud native. They've heard the term Kubernetes.

They've looked at orchestration. They've looked at containers, but they've never really taken that first step. They've dabbled with containers, but they've never really taken the adoption to even cloud. Sure. What are some good resources that you all point people to often to kind of get those first steps to get that aha moment? Because both of you have a, not so much you, but Gabe, you have a first day that you touched Kubernetes and you were like, this is amazing. So where do you send people to to kind of get that original aha moment with Kubernetes and to say this is what we should do? Well, there's a couple. I think the first thing for me is I think that the 12-factor methodology, it's not directly related to Kubernetes, but I think it was a really important moment in sort of the development of how you would build software in a way that is friendly for the cloud.

I think reading through that, it doesn't take very long. What is it called? 12factor.net is the website. And it's actually pretty dated, but it's actually held up quite well over time, I'd say. And then the other, I don't know if there's a research of this, Brendan, you might know, but the thing for me that really hit home with Kubernetes was the idea of declarative infrastructure that has control loops that reconcile desired state and current state. And these self-healing systems, right? And how all of Kubernetes is basically a series of objects that are representing desired state and then a series of controllers that are enforcing that desired state and pushing the world towards that state over time. It was the first project I'd ever seen that had that kind of architecture that deeply.

And I actually think that was part of the extensibility model because really what you do with the extension model is you say, well, here's a new type of resource and I want to run another controller that's going to sort of enforce that sort of state. And there's a level of elegance and simplicity to the whole model that it was just different than anything else that was out there. Everything else felt cumbersome, complex in comparison. I think the only thing that was weird, awkward about Kubernetes was the networking model. But shockingly, it only took like a few months for everyone to realize that the Kubernetes networking model was actually the right one. And then everyone started adopting this IP per container, IP per pod kind of model. And, you know, once that's sort of behind you, you're left with this core of Kubernetes. It's actually really quite beautiful and really quite elegant in my view. One last one before we go.

Speak to this podcast based on developers. So you've got people out there thinking, like, how can I get involved? Not so much just using it, using Kubernetes or getting involved in CNCF or the different places that they can go to or the different projects involved in CNCF. But what about contributors for open source? I hear there's a contributor ladder. I think it's CNCF globalF Global at the TOC level, but not so much at a Kubernetes level. What do you do to get new contributors?

What's the onboarding ramp? How do you adopt new developers into the project? Yeah, I think there's a variety of things. One thing I would say is that the Slack channel is super active, and it's separated. We have a separate channel for users versus developers. Some people go and, some people go and ask, like, how do I deploy apps questions on the user's channel? And then, but if you want to go do coding, there's the developer's channel. We try and mark a bunch of the GitHub issues with things like Help Wanted. Some

of that stuff is sometimes dated and, you know, we don't probably do as great a job curating that as we could, but that's a good place to start. I would also say, though, that we're reaching a place where there is so much in the ecosystem that oftentimes a great way to get started is in one of the ecosystem projects. So I've been doing a lot of work lately on client libraries in different languages, working on the Java client library, the.NET client library, the TypeScript client library. And that's nice because it's an important part of the ecosystem, but it's a separate project from the main project.

And so it's an easier thing to wrap your head around. And maybe it's even in a language that you're familiar with as opposed to Go, if you haven't had a chance to look at Go. So I think there's a variety of different places where you can find access points. I would say with the main Kubernetes project, be persistent and patient. We really do want and value the contributions. We know that it's messier and harder in places than

it probably ought to be. And in fact, there's a SIG contributor experience. There's a special interest group for contributor experience that is kind of continuously trying to make it better. And that's where things like the contributor ladder comes out of and some of the messages that the bots chat back to you on your GitHub issues and stuff like that. But we definitely welcome people to come in and contribute and figure out the place that works best for them. Very cool.

Anything else that I didn't ask that you guys are like, man, I want to share this to this community listening to the show? I think the one thing that I'm kind of excited about that we announced at the conference is this thing called the virtual kubelet. I've heard about this. Yeah. Eric St. Martin's a friend of mine. He runs GoTime. He was part of the hack team that's been here for a week doing that,

I think. I got some of the Baxter on it. Yeah. And so Eric helped out quite a bit on that effort, actually. And what's cool about it to me is that it's really evidence of Kubernetes staying power, right? Because we didn't have this concept of a serverless container runtime like what we shipped with Azure Container Services back in July, where the first major cloud provider come out with anything like that. We knew when we launched it that people were, yes, they were going to want to use it directly. Containers in the cloud is pretty nice. AZ Container Create turns out to be a pretty nice experience for doing simple stuff. But we also knew folks were going to want to use the Kubernetes API,

so we shipped a connector that basically bridged the two things. Immediately, Hyper.sh, who had a similar product, they forked the connector, friendly fork, but they forked the connector, wrote their own runtime. And since then, Brendan and I were like, oh, man, you know, there's probably something we should do here. And there's actually a lot of meaty problems that we don't know how to solve yet. How do you attach volumes to a serverless container? How do you manage load balancers and things like that? Scheduling affinities. I mean, a lot of open questions. And I'm really pleased to see the reception to the virtual Kugelhut has been tremendous. And it looks like we're going to have pretty much all the major

clouds who have, and startups who have these serverless container runtimes working together on this code base that we're going to be donating upstream to the Kubernetes ecosystem. And I'm really excited to see that come to fruition. Yeah, for sure. I think that's going to be over the next few years. I think one of the things we're going to definitely move to is, you know, if Kubernetes lets you not think about your machines, I think in many cases people don't even want to have machines, right? So this move towards serverless containers and orchestration of serverless containers

I think is the next really important part of what we're doing. So listeners, I know we just barely scratched the surface on this virtual kubelet, and I'm sure that in a future episode of GoTime, Eric will go deep on what's going on there. So tune in to a future GoTime episode. But for now, fellas, thank you so much for your time.

I appreciate it. Thanks for having us. All right, that's it for this episode of the change log if you enjoyed this show share it with a friend head to iTunes, Apple Podcasts whatever you want to call it go to your favorite podcast app and if they have the ability to favorite it or share it do us a favor and share it with a friend

and help us get known, leave us a review and we appreciate it. Thank you to our sponsors, Red Hat and their awesome podcast, Command Line Heroes. Also our friends at Digital Ocean and GCP Podcast. Bandwidth for ChangeLog is provided by Fastly, so head to fastly.com to learn more. Error monitoring is by Rollbar. Head to rollbar.com. And we host everything we do on Linode cloud servers.

Head to linode.com slash changelog. Check them out. Support the show. And the changelog is hosted by myself, Adam Stukowiak and Jared Santo. Editing is by Jonathan Youngblood. Music is by Breakmaster Cylinder. And you can find more episodes just like this at changelog.com or wherever

you get your podcasts. Thanks for listening. Bye.