The Changelog: Software Development, Open Source - Perspectives on Kubernetes and successful cloud platforms (Interview)

Episode Date: January 9, 2019

Adam caught up with Brendan Burns (co-creator of Kubernetes and Partner Architect at Microsoft Azure) at KubeCon + CloudNativeCon 2018 in Seattle, WA to talk about the state of Kubernetes, the importance of community, building healthy cloud platforms, and the future of cloud infrastructure.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by Linode, our cloud server of choice. It is so easy to get started with Linode.

Servers start at just five bucks a month. We host ChangeLog on linode cloud servers and we love it we get great 24 7 support zeus like powers with native ssds a super fast 40 gigabit per second network and incredibly fast cpus for processing and we trust leno because they keep it fast they keep it simple check them out at lnda.com slash changelog. Welcome to 2019, everyone. Yes, we're here. We've arrived.

This is our first show back, and I'm excited about it. This is the changelog. We feature the hackers, the leaders, and the innovators of software development. And I'm Alex Dekowiak, Editor-in-Chief here at ChangeLog. And on today's show, we're actually going back in the past to 2018, recently at KubeCon, CloudNativeCon 2018 in Seattle, Washington. And I sat down with Brendan Burns, the co-creator of Kubernetes and also partner architect at Microsoft Azure. Brendan and I talked about the state of Kubernetes, the importance of community, building healthy cloud platforms, and last but not least, the future of cloud infrastructure.

The last time we talked was in Austin. Right. You had your comrade there, Gabe Onroy. Yeah, yeah, yeah. We talked a little bit about the direction, obviously, of Kubernetes, but I thought it'd be interesting to come back a year later. Sure. Because that conference, I don't know how much you remember from a year ago.

I'm sure your life is a little blurry these days. It was snowy. I remember it snowed. It did snow for the first time in Texas in a while. It never snows in Texas, let alone Austin. But yeah, we did actually have some snow. More of a state of Kubernetes. I mean, you've been here since the birth, obviously, one of the founders of the project.

During that conversation, I did ask you something. And I don't mind if you forget some of the things, I'm sure you do tons of interviews, but I asked you your temptation to keep it. Sure. Speaking of Kubernetes, rather than open sourcing it or taking these ideas and planting them into Google and the way that it's rolled out. Your response essentially was like, no, I'm actually really happy with open sourcing it. Because you see a lot of people, a lot of developers have really good ideas, release a portion of it as open source and build this gigantic company around it. And you could have been the kind of person who was maybe, I don't want to say selfish, but maybe self-thinking and did that with Kubernetes.

I don't know. I'm not sure it succeeds, actually. No? Right? Like, I mean, I actually think that the reason we're all here is because of the ecosystem and because we've enabled this large group of people to bet their success on this open platform. Right. And I actually don't think, I think if you, you try and hold onto it, you try and be too tight with it, it doesn't succeed. Like I, I think that's the lesson of cloud in my mind anyway, is that if it's not open and it's, it's not gonna win ultimately. And, and so, so yeah, I don't know. I don't actually think that, I mean, it wasn't a choice

that I was interested in no matter what. But I'm actually know. I don't actually think that, I mean, it wasn't a choice that I was interested in, no matter what. But I'm actually not even sure that if you make that choice. Because, I mean, if you cast your mind back, actually, in the moment leading up to, you know, when we first announced it, there were a lot of different orchestrators out there. A lot of different projects, right? A lot of different approaches. Many of whom, you know, only the people who are sort of paying attention even noticed. And I think that the reason that five years later we're here with 7,500 people is because it's not the tech that it really could be something that everybody could bet on is the reason why it survived I don't yeah so I'm a big

believer that that open always wins that community always wins and it takes longer than others sometimes it takes a while sometimes yeah but what do you think gave me that feeling though you know you say very uh you say you use words like always yeah yeah like every time always those are well you know what i mean i am guilty i have to admit i'm guilty of using words like that a lot i speak very definitively at times and maybe like maybe maybe maybe it's more definitive than or maybe i believe it's more definitive than it is um but i mean i think you look back and you look at, you know, some of my first experiences in open source were sort of in the height of the

free BSD Linux sort of FUD wars, whatever, in the sort of late 90s, early 2000s. There was a, you know, it was a big, big thing going on. Like people would argue, you know, do you use BSD or whatever? And I think one of the things that really I took out of that was that the community that developed around Linux was more supportive, it was more open, and the ecosystem just was more available to people.

And I think ultimately that's why Linux ends up being the success that it is. And FreeBSD is still out there for sure, right? But it's not like it was in 1999 where it was sort of a horse race. Yeah, it's clear, right? It's clear who the winner was. And so I paid a lot of attention to that um i think that there's other you know there's a lot of other examples um i think the hadoop ecosystem is another really great example of like you know lots of different companies sort of being able to come in and bet themselves on that ecosystem. Right.

Yeah. Right. And, and, and also companies being willing to step in and develop in-house expertise in, in that, you know, that software and that technology. So, you know, that's sort of, and in smaller scale too, you can look at things like, you know, Ruby on Rails or any of these other kinds of, you know, every, I feel like every single one of the important cloud-based projects has been open source at its core. And I think it's just, it's a necessity. I don't know. I got one comeback to that, but I want to go here first.

We'll go to the comeback first, and we'll pause the other one. So when I was in this analyst meeting, it was talked about how you've got a graduated project. When we talked about the CNCF, for example, you've got graduated projects, which is what Kubernetes is. You've got incubator projects, which are in the incubation stage. And then I don't know what this last one is. Sandbox. Even more, even less incubated than incubating. So everyone that has been graduated

began as open source. They talked about well, hey, if you've got ideas around this pathway, this CNCF landscape, this cloud native landscape, the way to get in essentially is to create something open source that's useful. Yeah. Right? That has adoption.

So, you know, speaking to that, that's the exact recipe for essentially having a project that matters in this world, this particular world here. Yeah, yeah, yeah. Not like the world at large, but just Kubernetes cloud native world. Yeah, yeah. No, and I think that's true. I mean, I'm not going to say that it has to be every project. I mean, I think you look at things like SQL Server,

massively successful database, totally, you know, not open source. I think you can certainly build useful, interesting software that a lot of people use. But I think that in the world of infrastructure, where you're not using it, well, you're using it, but you're running on it. You really want to be able to understand it and debug it and participate in it. And it's a platform.

It really needs to be open. I don't know. That's my feeling. Especially because it's such a hybrid world. People need to know that they can run the same app in multiple different places. Open really helps with that. Does licensing ever come up for you when you talk about open? So whenever you have certain

projects out there, you know, using like Commons clause or just ways to not be cannibalized by the big guys or the big people so to speak. Yeah, I mean I think this is a real risk for a lot of people. Because that's what happens at infrastructure levels. Like, you know, we build it, we can't make money from it. It's tough. And I think that I actually feel like as a cloud provider, if we're not creating a platform that you can make money on as an independent software vendor,

like, long-term, we're making a mistake, right? And I think one of the great... You know, it's attributed to Bill Gates, but one of the things he said early on was for every dollar that Microsoft makes, our partners have to make $10. And I think if you don't have that vision, if you don't have that notion that if you're building a platform, to build a successful platform, you have to enable other people to make money on it. You can't be always cannibalizing their stuff. I don't know that we're there in cloud yet, but I think we really should try and get there.

Any risks coming up that you're aware of around this concern? Well, I think as cloud providers, we actually have to build infrastructure for those ISVs. So the independent cloud providers have to have this adopted feeling. Right, I think we have to adopt the belief that we're not just providing infrastructure for infrastructure consumers, but we're actually providing infrastructure for ISV app developers. And one of those teams does this work on this thing called managed applications. And it's really all about how do we build a platform for independent software vendors to be able to successfully and scalably sell their software on Azure. Right. And actually, I think Kubernetes is a big part of that because the challenge of selling software is the making it reliable and operable at scale. Right. making it reliable and operable at scale. It's great if I can sell 10 copies of my software,

but if I have to have a person on call for every one of those copies, I don't really have a very scalable business. And I think Kubernetes enables people to containerize their applications and potentially run them very reliably without a lot of interference from an operator at a much higher scale. And so that was sort of one of the motivations for doing it in the first place, was to provide this infrastructure platform for application developers to build on top of. Like, if you think about someone who sells software on a CD, right, every copy of that

CD doesn't really incur much in the way of operations cost. Maybe they have a support center somewhere, but every time they sell a new copy of that software, it's not like they think, oh my God, I'm going to have to hire a new SRE to take care of it for me. But in the distributed systems world, it's kind of like that. Either you build a SaaS. For every new customer, you have a cost. Yeah, for every customer, there's a little bit of consulting, a little bit of operations

you have to do. It's very linear, and that means it's hard to scale your business. And I view that as an infrastructure problem. We're not supplying the right infrastructure to these software vendors to enable them to manage their software at scale. And so I hope that Kubernetes, and especially managed Kubernetes, like in the Azure Kubernetes service, provides that. Provides that sort of

application-oriented infrastructure, makes it easy to build and scale your app. So, I don't know. Any particular good stories around managed applications? Like, what's just a great example of a managed application and why? So, like, we built a really great partnership

with Databricks, for example, in Azure. So, Databricks is a big data warehouse kind of streaming analytics solution. And fundamentally, it's a piece of software that that company built. And now they've been able to turn it into a product inside of Azure without being, they're still an independent company.

They're still doing their thing and running on all sorts of different clouds and on-prem. But by using managed applications, they've been able to integrate it into the Azure API in a way that makes it more native to Azure than it is if they just sort of installed it. And it makes it more operable, too, because we can enable people, their operators,

to gain access to all of the resources that are being deployed in Azure to support it. So that's a pretty successful example that we've built. But we have a bunch of different other partners who are using managed applications. Like databases, stuff like that? That sort of things, or people like Chef and other sorts of people who have to have a server component that they want to deploy into everybody's end user subscription if they're going to be a customer.

Is there anybody that can actually just build their business, say their application runs on Azure, but that's the only place it runs? They actually build it to run in Azure as an independent company. I think at this point, all of the ISVs know that they need to be multi-cloud. What I mean that is not multi-cloud. I mean it is maybe just simply like their stuff only runs on the cloud under a provider. They don't even have managed. It's literally a software built inside of managed services, for example.

And I suspect that that's sort of where we're headed, where you take a managed Kubernetes cluster, you lay on some application code, you use some of our managed application infrastructure, and you actually literally can sell that as a product. Wow. And we actually help you monetize it, right? So we actually help with the billing relationships and that sort of stuff. And I think as a cloud provider, that's an obligation.

I see that as an obligation that we have. I think it's good for our long-term health as a computing industry, but I think if all we do is sell infrastructure to the direct consumer, if it's just to the person who's building the system, I don't think we've built a healthy ecosystem. You need a healthy ISV,

independent software developer, vendor ecosystem. And I do worry, actually, that we don't do enough with some of these open source companies to help them build scalable business models. Interesting. So you're doing more of that now? Or a long-term goal? I think it's a long-term goal. I think it's a focus for Azure to build an environment in which our partners can be successful, financially successful, invested in their success. I think that's historically, that's always been something that Microsoft has been good

at partnering well with companies, ensuring that they can make money on our platform. I think it's an important differentiator for our cloud for sure. This episode is brought to you by Clubhouse. One of the biggest problems software teams face is having clear expectations set in an environment where everyone can come together to focus on what matters most, and that's creating software and products their customers love. The problem is that software out there trying to solve this problem is either too simple and doesn't provide enough structure, or it's too complex and becomes very overwhelming clubhouse solves all these problems it's the first project management platform for software teams that brings everyone together it's designed from the ground up to be developer first product in its dna but also simple and intuitive enough that all teams can enjoy using it with a fast intuitive interface a simple api and a robust set of integrations, Clubhouse seamlessly integrates with the tools you use every day and gets out of your way.

Learn more and get started at clubhouse.io slash changelog. Our listeners get a bonus two free months after your trial ends. Once again, clubhouse.io slash changelog. You mentioned just people, community, things like that, and the importance level of it. For us in our business here at ChangeLog, one thing we do is partner well, not only with community members, but also with different brands that need our help to share their story, tell them developer culture stories. And just the stories about these different brands just have a hard time telling more than their core competencies, like actually making them far more human than they were able to in other avenues. And one thing I often have to tell people about our perspective when it comes to partnerships and our DNA is that we're here to raise the tide of everyone. You can't go around building a great city knocking people's buildings down.

If my job, let's say I was a Microsoft employee or you in the role you have, you're not going around knocking people's buildings down. If my job, let's say I was a Microsoft employer, you, in the role you have, you're not going around knocking people's buildings down. You're helping them lift their buildings up. You're making sure streetlights are corrected, that the roads have no potholes, you know, whatever. All the things that make a city a good city. Yeah, yeah, yeah. How do you feel about that?

No, I think so. Knocking buildings down versus building others. Yeah, it's a really important aspect because you waste so much energy in that stuff that's not helping anybody be successful. You're not helping anybody

ultimately at the end of the day what excites me what has always excited me is enabling that user to be successful using software that I've built or I've helped build. And anything else in some ways is a waste of time. And so if you're tearing stuff down or you're focusing on anything other than making your stuff great, I don't know, I feel like you're wasting your effort.

It's no fun to win if it's a scorched earth, right? Like, that's, like, at the end of the day, you're like, you raise the flag, and you're like, I won, and then you look around, and you're like, no one else is here. I mean, how is this really winning? What triumph is worthy of nobody else? Yeah, yeah, yeah, and I think that's the trouble,

is some people focus more on the winning than on the, like, empowering the user. And obviously, it's great. I mean, I love the fact that we're here and there's 7,500 people here. And that's amazing, right? It's way better than me being in my basement and being like, look at my Kubernetes project. I wish somebody would look at it, right? But as I said, sort of at the get-go, I think we're here because we've had that take the

high road, build people up sort of ethos. We've invited people in, we've invited people to join and to help and to find the place where they can contribute. I mean, we were just at the Contributor Summit yesterday and we were celebrating a bunch of people who do like release management, who've done docs, who've run, you know, helped organize the task board for various special interest groups. Like, totally non-technical jobs, totally not distributed. But they're essential jobs to keeping the community going. And the fact that we've created a community where people volunteer for that and then get rewarded is, like, that's why it's successful.

So, I don't know. I'm a big believer in that i'm glad you brought it back to community because that was the tangent i wanted to go on earlier right and what i wanted to ask you about that was that we hear the word community a lot it's because of the community and i don't i'm not discarding that i'm sort of tangentially just sort of like making fun of ourselves as we say this but there's some people out there who are like, what do they mean by community? Right. So help me break down what community is at the cloud native level, the Kubernetes level. Like what is a community member? Is it a user? Is it vendors? Like how do you see successful community being implemented in this community

here? I think it's two. I mean, I think it's twofold. I think there's sort of two different layers of community. There's sort of the core Kubernetes contributor community, which we had like 400 people yesterday who are the people who are kind of day in and day out. This is their job, right? They're working on providing it as a service or they're working on making it better or working on integrating storage providers into the core project. Like there's a small community that is really focused on building the project itself, the team, if you will, that builds the project. And that's an important community, but in some ways it's more like any other traditional software team, right? I mean, it's different

because it's distributed and lots of different, you know, not everybody works for the same company and some people don't even work for anyone. And that's a little bit different, but it's sort of the same. And then I think what you're seeing here, you know, on the expo floor and everywhere else is the broader community, and that's sort of the community of users and the community of the people who have taken an existential bet on this technology, right? I think that's, in some ways, the more interesting and powerful community,

which is the people for whom this technology is the way that they deliver their application, or it is the thing that their startup is based around, right? You know, a monitoring company that has said, we're all in. If you don't use Kubernetes, you can't use our software. That's a community member. They are fully vested in this community's success because if it's not successful, then they can't their company doesn't exist, no matter how awesome it is. No matter how awesome their thing is, if Kubernetes isn't successful,

their monitoring tech or whatever isn't gonna be successful. So I think it can be vendors, and I think that, but I think the big thing is that everybody is sort of collectively vested in Kubernetes being successful and users being successful using Kubernetes. That's what makes the broader community.

Being on Slack, helping people out on Slack, helping out with the GitHub issues, Stack Overflow, all of the sort of like the traditional people helping each other stuff that you've seen happen, I think, in the developer community for a really long time, actually. Like, really, certainly from the advent of the Internet and probably, you know, the broad-scale Internet in the mid-'90s, and probably even earlier on mailing lists and things like that where people are... There's just a sense that we're going to give advice and we're going to help you learn to, you know, get through that error that you hit six months ago and all that sort of thing. I don't put up a silo and say, oh, yeah, you're working for a competitor company.

I'm not going to help you with that Kubernetes error that you just hit. It's that kind of stuff because somehow you've magically been able to have probably highly influential people from various companies come together. Yeah. And then still not... It's hard. Enable or disable, you know, kind of clicks and access and politics. I mean, I wouldn't say that we're, I'm not going to get up here and be like,

we're not going to be like, we're free of all that stuff. It's just like kumbaya all the time. But I think that we have been very lucky in the group of people who have, who were sort of in the initial leadership positions. Right. And that once you, but that once you shape a culture, it kind of takes care of itself. Right. Um, and so I think that, you know, we had the steering committee summary at

the end of, um, the community meeting yesterday and, uh, you know, we got up there and in another world, you could imagine us being like, here is the future direction of Kubernetes for the next 12 months. We will do this, this, this, and we are the future direction of Kubernetes for the next 12 months. We will do this, this, this, and we are the steering committee and we tell you what to do. And instead, we spend a long time talking about how our primary job

is giving away responsibility and giving away power and delegating to people. And I think that when you do that, you know, it's, it's, uh, it's funny. Like if, you know, you might say, well, it's lazy to be like, Oh, I'm just going to let you take care of that. I'm not gonna do it. You take care of it. But like, when you do that to people, they do such an awesome job because you've trusted them, right? Because you've given them this,

it's, you've given them power, but you've also told them that you trust them and they're going to do amazing things to validate your trust. So I don't know. I think that's, that's really helped. I mean, it's still like, we still have bike shedding. Like I think, I think we still have plenty of bike shedding discussions where we spend way too much time talking and not enough time doing. And, and sometimes we have fairly significant disagreements but I do think that there's a level of respect amongst everybody that is important to the project for sure. And I think unique actually. I think if there's anything that I'm proud of from the project it is that community, that small community, that culture, that group of people that we built there.

I don't know. It's a pretty special thing. This episode is brought to you by Raygun. Raygun recently launched their application performance monitoring service, APM as it's called. It was built with a developer and DevOps in mind. And they are leading with first class support for.NET apps and also available as an Azure app service. They have plans to support.NET Core followed by Java and Ruby in the very near future. And they've done a ton of competitive research between the current APM providers out there and where they excel is the level of detail they're surfacing.

New Relic and AppDynamics, for example, are more business oriented where Raygun has been built with developers and DevOps in mind. The level of detail they're providing in traces allows you to actively solve problems and dramatically boost your team's efficiency when diagnosing problems deep dive into root cause with automatic link backs to source for an unbeatable issue resolution workflow this is awesome check it out learn more and get started at raygun.com slash apm It seems like the secret sauce is that somehow everyone who matters or can either destroy

or build up the future of Kubernetes understands that, hey, if Kubernetes succeeds, then your business has an opportunity to thrive, or our business has an opportunity to thrive. So that's our treaty, so to speak, our NZ, so to speak, our DMZ. Yeah. Yeah, but I mean, there's two different ways that that can end, right?

That can end in sort of the mutually assured destruction, Cold War style. OK, sure. Yeah. Okay, sure. You know, like, yeah, we're never going to mess with it, but nobody's going to really, like, invest in it either. Or it can end up, I think, where we are, which is, like, we're going to really go and collaborate, raise all the boats, as you said.

I like how you say bet. I mean, you really have said the word bet a couple times. Like, bet everything on the fact that it's going to... And you have to, right? Like, I mean, that's what it is, right? Yeah, it's rolling the dice. But anything that's worth doing ends up being a bet like that, I think.

Let's talk about some things you mentioned last year and contrast them against this year. Last round stage you mentioned Metaparticle was part of the future. What's the state of Metaparticle? Man, I'm so sad about Metaparticle. I just haven't had enough time. I still think it's the future. I still think it's the future.

Okay. I still think it's the future, but I, you know... Any movement on it? Any progress? I mean, I just haven't heard much about it. Here and there,

but in all honesty... Was it premature to mention it or announce it? No, I don't think it was premature because I think people are still talking about it.

Right? And I think it was intended in some respects to stir a conversation more than to turn into, like, I don't think I had any expectations. It was going to become like the, you know, the, the, a huge project over the next year or whatever. Um, uh, I do wish I'd had more time to spend on it. Um, I mean, real life kind of got in the way, I guess. Um, uh, but, but I do still think that there's an ongoing conversation that's, that's happening in that space.

Um, that's worth having that people, I still see people either talking to me at conferences like this or referencing it in documentation. Um, I hope they'll get, I guess it's one of those things that's on my list of like, I hope I'll get back to it someday. So, yeah, that's sort of where that's at. Is that what you do on like nights and weekends?

What's the night? It was. I mean, that was what I did. Yeah, so nights and weekends, a lot actually what I'm talking about today, I do a number, I've been working a lot

on the Kubernetes, client libraries for various languages in Kubernetes. Right. And that's actually what my talk is at the end of the conference on. So I've been spending a lot of time on that. I've been spending a lot of time on the VS Code extension for Kubernetes. I've been really enjoying working inside the IDE and trying to sort of integrate Kubernetes and the IDE together.

Right. Also, a lot of time and energy on the virtual kubelet, virtual node stuff. That's been trying to figure out how we marry serverless infrastructure up with Kubernetes. That's been a big effort. Well, this show will come out after your talk, so give us maybe a... Oh, my talk is like way down in the weeds. Let's go in the weeds. Let's go in the weeds let's go let's go in the weeds there so i'm going to do some live i'm gonna do some live coding i'm going to do a

pr my first first pr in a talk actually i've never done it before so i'm gonna it's gonna be an experiment um and by way of experiment i'm going to show the complexity of of how we build these libraries starting with a github issue that's sitting out there because somebody wants to use our generated library to proxy request, and they find out that they can only do gets, and they can't put bodies, they can't do posts or puts, and this other thing.

And they file an issue, and they go, why can't I do this? Well, so all of our libraries are built from open API specifications. So it's a JSON specification for an API that the Kubernetes community puts out. You take it, you put it into a code generator, it generates a whole bunch of code. And that tool, actually, we don't control. It's another open source project.

And so to fix this bug, what I'm going to do in the talk is we have to make a change to the open API specification. We have to make a change to the open API specification. We have to rerun that code generator. We have to then take that code generated code, check it into the client library repository, build that client library repository, and then push it out to like Maven and these, you know, code library things. And so it's like this very small thing that turns into a bunch of different stages in this pipeline and and just to explain why you know it's the only way we can keep up with the project right there's always these new api types being added in there's always

new you know data fields and whatnot um and so if we didn't use a code generator and you see this actually because there are people out there who have handwritten Kubernetes client libraries and over time they just get further and further out of date and they get further and further out of date because it's just exhausting to try and keep up so the only way you can do it is through these code generators but if you use the code generator then suddenly

you're beholden to the features that are supported by the code generator to the quality of the supported by the code generator, to the quality of the API spec, which has some gaps, the quality of Swagger or OpenAPI itself, which has gone through a couple different versions to fix some problems. So that's sort of what the whole talk is about. It's going to be very much in the sausage making, like how the sausage is made category. So who's the person

that should not miss that or if they're listening later, they should go on YouTube and find the talk? I mean, I think anybody who's interested in non-GoLang client, not coding to the Kubernetes API

in a language that's not Go. That's who we're really aimed at. And actually, ultimately, we may very well be aimed at Go as well because the existing Go client library is a constant source of pain and friction for developers because when you import it,

you basically import three-quarters of the Kubernetes tree just to import a client library. So it's way too heavy. So there's some amount of work to see if actually we should move to one of these generated client libraries for more sort of smaller scale Go programmers who want to communicate with

Kubernetes and then there's also consistency so one of the other things you realize when you start doing this is how the system loads like a kubeconfig file, like the config file that describes how to talk to your cluster, it's not documented anywhere, right? It's only in the code, right?

But suddenly, like, you're writing client libraries for six different languages, and somebody says, hey, kubecontrol works, Go works, but your Java library doesn't work, right? And you're like, why not? And you figure out, oh, it's because this system looks in this path, and we didn't implement that for that over here. Or Go loads JSON or YAML in a specific way where that becomes a string.

And in Java, Java tries to put that into a Boolean or whatever it happens to be. And so it's been an interesting exercise as well in understanding these places in the project where the only documentation is the implementation and having to take that apart. And honestly, I wish I'd contributed back more documentation than I have. Usually it's just pointers.

Usually in the code I just say, hey, the only place this is documented is in the code over just say, hey, the only place this is documented is in the code over here where I found it. Right. You know, point back to that. Does that make you want to go write some docs for it? It totally does.

And then like I'll reference earlier the lack of time. Right. My Nights and Weekends are taken up by this. Also, I bought Red Dead Redemption. So like my Nights and Weekends. What is that? Red Dead Redemption. Oh, it's a video game.

Okay. It's high quality I wish I was more of a gamer I'm just not, I get into it but I'm not like hardcore gamer, I'm not like hardcore but sometimes there's a game and it just takes up my life for like 4 months right, gotcha, so that's this one right now so I have that but it's been from like my

teenage years, like I will play Castlevania Symphony of the Night any day I'll go back and replay the original Castlevania but for some reason I just don't get into Nice. I'll go back and replay the original Castlevania, but for some reason, I just don't get into modern gaming as much. Maybe because I'm older. I don't know what it is,

but for some reason, it just doesn't intrigue me as much. The open world stuff. Maybe my son isn't old enough yet. He's still, you know, almost, he's going to be three soon, so I mean, he's not into it. Yeah, yeah, yeah.

Maybe when it becomes a dad and son thing, or a daughter and father thing. I only play Mario Kart with the kids. Definitely got to play games with the kids. Let's laugh a little on the way out of this conversation. I'm looking at your Twitter feed recently. All right. Am I saying it correctly when I say, is it Fiffy?

Fippy. Fippy. Fippy. The PHP app. The PHP app? Fippy. Fippy. Fippy. The PHP app. Fippy the friendly PHP app. Okay. So this giraffe, right? Yep, giraffe. Is everywhere. She's, yeah. Awesome. What's up with that? What's the backstory?

The Children's Illustrated Guide to Kubernetes. I've seen that, yes. So Fippy is the main character in the Children's Illustrated Guide to Kubernetes. We had a volume two, this at KubeCon. So Fippy goes the main character in the Children's Illustrated Guide to Kubernetes. We had a Volume 2, this at KubeCon. So Fippy goes to the zoo. So this year's next Volume 2? This year is Volume 2. That's all last year.

Yeah. Fippy goes to the zoo, introducing a few more parts of Kubernetes, Ingress and a few other parts. And we also announced that we're actually donating. So all of that was originally created by Deus, which is a startup. Microsoft acquired Deus a few years back. And as part of that acquisition, we got Fippy and the stories and all this. So actually at KubeCon this year, we announced that we're donating all of that to the CNCF. So all of the intellectual property, all of the graphics and all that stuff donated to the CNCF

story donated to the CNCF so there's actually FIPI.io and you can go there and get the PDFs and all that sort of stuff so as a sort of tribute to all of that and a tribute to the fact that

KubeCon had come to my hometown I'm a native Seattleite born and bred and a tribute to the fact that CubeCon had come to my hometown. I'm a native Seattleite, born and bred. I decided to take FIPI on a little bit of a tour this past weekend, and so a lot of the places that the tourists or people, when I visit the places I take them around Seattle, I took FIPI around to all those places. I dug that. I think that's a really cool idea. I wasn't sure what made you do it.

I was hoping for some of this context. Yeah, it was because we knew we were donating it, obviously. So I don't know if you saw the keynote, but Matt Butcher and Karen Chu, who are some of the people who are responsible for developing this whole thing while they were at Deus, actually got to do a reading in the keynote. They did a reading of Volume 2 up on the stage.

Nice. It was pretty awesome. So if your listeners didn't get a chance to check that out, they should check out the live stream of the keynotes from KubeCon and see the reading of Kubernetes Children's Illustrated Guide Volume 2, FIPI Goes to the Zoo. So if you go to, what was it, FIPI.io. FIPI.io. So you've got FIPI and friends here. So if you go to, what was it? Phipppy.io So you've got Fippy and friends here.

You've got Goldie, Z. Goldie is based on the original gopher. Z and Captain Cube. Captain Cube. Captain Cube always looks a little grumpy. I don't know. I'm trying to cheer him up. It's the eyebrows. Sorry, it's the eyebrows. It's the eyebrows.

You've got a furrowed brow. He looks a little grumpy. He's the stern captain. eyebrows sorry it's eyebrows you got a furrow brow you're gonna see him like he looks a little grumpy yeah yeah I was gonna say that a stern captain I guess we'll put that in the show notes but that's also where you can download and or read volume 1 and volume 2 that's right yeah okay that's right I happen to have a printed copy cuz I we do last year and we got a where do you get printed copies as it I or just your at the conference? The Azure booth. Okay.

If you're at KubeCon. I guess this is going to go out after KubeCon. So, too late. But we'll have... For listeners, how do they get it? Is it even possible? I don't know that you can get... I mean, we have it at Conference Swag.

And I imagine CNCF at future conferences will have it. So, you know, come check out the booths. I got to go buy because I have to get more too. Future conferences. And we have... These things are going to be worth money one day. We have some... If not already. We have some stuffies as well. check out the booths I gotta go buy because I have to get more to future conferences and we have these things are gonna be worth money one day we have if not already

we have some stuffies as well and you can buy the stuffies at the CNCF store as well so those will probably be available

online did you happen to see Julia Evans illustration from last year no I don't oh yes I've seen

some of that stuff I have for whatever reason the conferences over last year they still had a huge stack. I want to say maybe like 25 of them. And I've been thinking like, I want to keep one for me because I've got to. Yeah, yeah, yeah. Sorry, I bought my own mic here.

I got one of them framed, ready to go up on the wall because I want to use it as wall art in my studio. Right. But then the others, I'm like, I got like 25 or 30 of these things. Yeah, yeah, yeah. So maybe if you're listening to this, reach out. We'll see if we can ship you one somehow. That's right. Roll it in a tube and cargo it out there.

Sounds good. Well, Brandon, it was a pleasure to catch up with you. Always sort of get a snapshot of where things are going. I feel like you're such a great person to talk about, obviously, because you keep rolling it. But you see things at a different level than I think most people get a chance to sure in this community so it's really interesting to get that anything that i may not have asked you in closing that you're like man i just i gotta share this uh don't let it leave without that no i think we did

a pretty good job actually i mean i'm glad we got the 50 thing in at the end so uh cool let's leave it there thank you so much for your time. I appreciate it. It's always a pleasure to catch up with you. Absolutely. Thanks so much. All right. That's it for this episode of The Change Log.

We're back. 2019 is here. I'm excited about it. And I hope you are too. Do us a favor. Share the show with a friend. Email it. Link it up on Twitter.

Blog about it. Go into Apple Podcasts and rate and review review it go into overcast and favorite it whatever you gotta do do us a favor and share this show of course thank you to our sponsors linode clubhouse and raygun and of course thank you to fastly for our bandwidth check them out at fastly.com and we move fast and fix things around here at changelog because of rollbar check them out at rollbar.com and we're hosted on linode cloud servers head to linode.com slash changelog this episode was mixed edited and mastered by me music is by breakmaster cylinder and if you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master or go into your podcast app

and search for ChangeLog Master. You'll find it. Subscribe, get all of our shows, as well as some extras that only hit the master feed. Thanks again for listening. Welcome to 2019. And we'll see you again soon.