The Changelog: Software Development, Open Source - Kubernetes brings all the Cloud Natives to the yard (Interview)

Episode Date: September 12, 2018

We talk with Dan Kohn, the Executive Director of the Cloud Native Computing Foundation to catch up with all things cloud native, the CNCF, and the world of Kubernetes. Dan updated us on the growth KubeCon / CloudNativeCon, the state of Cloud Native and where innovation is happening, serverless being on the rise, and Kubernetes dominating the enterprise.

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 servers. Head to linode.com slash changelog. This episode of the Changelog is brought to you by Hired. One thing people hate doing is searching for a new job. It's so painful to search through open positions on every job board under the sun. The process searching for a new job it's so painful to search through open positions on every job board under the sun the process to find a new job is such a mess if only there was an easier way well i'm here to tell you that there is our friends at hired have made it so companies send you offers with salary benefits and even equity up front all you have to do is answer a few questions

to showcase who you are and what type of job you're looking for. They work with more than 6,000 companies, from startups to large publicly traded companies in 14 major tech hubs in North America and Europe. You get to see all of your interview requests. You can accept, reject, or make changes to their offer even before you talk with anyone. And here's the kicker, it's totally free. This isn't going to cost you a thing. It's not like you have to go there and spend money to get this opportunity. And if you get a job through Hired, they're even going to give you a bonus.

It's normally $300, but since you're a listener of the changelog, they're going to give you $600 instead. Even if you're not looking for a job, you can refer a friend and Hired will send you a check for a thousand three hundred and thirty seven dollars when they accept the job. As you can see, Hired makes it way too easy. Get started at Hired.com slash changelog. All right, welcome back. This is the ChangeLog, a podcast featuring the hackers, leaders, and innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at ChangeLog. Today on the show, we're talking with Dan Kahn, the Executive Director of the Cloud Native Computing Foundation, to catch up on all things Cloud Native, the CNCF, and the world of Kubernetes. Dan updated us on the growth of KubeCon cloud native con the state of cloud

native and where innovation is happening. Serverless being on the rise and Kubernetes dominating the enterprise. So Dan, we're just shy of a year catching back up with you personally. We met you a year ago and the term cloud native was to jared and i and maybe even most of the world was still becoming new and we were still learning about and i think we actually even opened up the conversation with like dan what's cloud native and i think now people tend to know what it is without going too deep because i want to cover a lot of the subject but kind of give us an update of like the last, I don't know, nine to 10 months since we last spoke. What's been going on with CNCF?

Yeah, the Cloud Native Computing Foundation has been going like gangbusters. And so I could pull out the exact numbers, but we've grown from something like eight to 26 projects during that time. We've grown from about 100 members a year ago to we're just about to hit 300 members. Our events are growing like wild where we had 1500 people in Berlin a year ago and then 4300 in Copenhagen a couple months ago. And we're expecting 7,000 in Seattle in a couple more months. So on almost every possible metric of 3,000 unique contributors to the Kubernetes project and the amount of money and our end user communities grown from 20-something members to 59 today, there's just a huge level of growth and adoption and engagement. But on a more sort of technical level, we could actually dive into the cloud native,

what it means for a second, because CNCF had a process with our technical oversight committee where we argued about and came up with the definition. And it's a little dense, but it's only four sentences long. So I would read it to you. Let's do it. Okay. And you can find this by searching for CNCF cloud native definition, but it says cloud native technologies empower organizations to build and run scalable applications in modern dynamic environments, such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high

impact changes frequently and predictably with minimal toil. The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source vendor neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone. Well, you're right about being dense, that's for sure. It is pretty dense. That's only four sentences. Yeah, and it was five, maybe.

But man, we argued over it for months. I can see why. Yeah, but the perspective I would give on it is – and one thing that's interesting about it is people associate cloud native with Kubernetes. Right. Kubernetes is the leading platform. It's the biggest project in CFCF. It's one of the highest velocity projects in the history of open source. Right now, basically second only to Linux itself.

But what is interesting about that definition is it doesn't say Kubernetes, and it doesn't even mention orchestration, where Kubernetes is an orchestrator. And what I like about the definition is that it's saying that over the last 10 years, a lot of leading companies have separately run into the same scaling challenges, both scaling their applications on the web, but even more scaling their development teams. And when you look at companies like Twitter and Yelp and Google and many, many others, they've all needed to come up with a series of solutions that have actually kind of converged together. And now a lot of that learning is getting put into software.

And that software, as opposed to having to go pay someone tons of money for it, is available for free to anyone as part of the open source community. I think what's interesting, too, is, Jerry, when we did the Istio show a few back, just kind of seeing how, Dan, as you laid out, Kubernetes being the most popular, the highest velocity, second to only Linux, which is really kind of crazy. will it win and obviously since then it has but going down you know the cloud data trail map which was really interesting in that in that show which we'll link up to in the show notes but kind of at each layer as these as kubernetes and ci and orchestration observability and service match as each of these become more and more standardized you kind of see you know the winner essentially or the the preferred ways to do things start to creep into each of this trail map which this trail map is really great it was great for illustration but also great to talk

through you know to see how i really appreciate that and we're we're pretty pleased with that is um people found our stuff very confusing until we we started printing that out i will mention if you go to um l.cncf.io uh that's for landscape.cncf.io, there's a link at the top to both the trail map, which is a sort of recommended path of how you can approach cloud native. And we say, look, the very first step is to containerize, and then you want to do CICD,

and only third should you be implementing orchestration and looking at these other more advanced technologies. But then kind of on the trail map is the front page. When you flip it over, if you get our printout, we have this insane cloud native landscape. And that has over 570 different open source projects and closed source products from all of these different vendors around the world that it kind of represents the ferment and the excitement in the space. But without that trail map, the landscape can feel a little overwhelming. We were kind of joking around before we hopped on with you, Dan, about this being an accidental kind of a cloud native month on the changelog because we had the Istio show. Then we talked about a segment, really a

conversation around microservices and monorepos. And then last week, I had a great conversation with Paul Fremantle about Ballerina, which is a kind of a cloud native programming language, culminating with this conversation with you. So it's been a lot of coverage. And I guess, you know, to our listeners out there who aren't that into this stuff, stay tuned. We will diversify yet again. Have no fear. Well, that is a great lineup.

And I hope Paul might have taken credit for the fact that he's actually the person who coined the word cloud native about four or five years ago. Oh, he did not take credit. He was too humble to tease that out of him. Yeah, so among other claims to fame. Well, it just seems like we kid because it wasn't on purpose. We didn't decide to go all cloud-native recently.

It just kind of happened. And so it seems like we always joke that if software is eating the world, JavaScript is eating software. It seems like on the back back end operational side cn this cloud native idea and i mean evidenced by 500 uh um projects or you know entities in your landscape is really eating a lot of software and so there's just tons of stuff to cover is is that what you're experiencing i mean with the massive growth of of the CNCF, it seems like that's definitely the case.

Yeah, I would just say a flat yes to that. I will also mention, by the way, that Node.js is a sister project of CNCF in the Linux Foundation. So we're really thrilled to see the growth there. And also the JS Foundation, which has a lot of other core projects like jQuery in it. So certainly Kubernetes is a great way of running your JavaScript apps on the server. On that note, I would say, too, stay tuned because, listeners, we will be at, I think the invite is still open, Dan. You have to correct us if we're wrong, but I think we're still invited to KubeCon, CloudNativeCon, and we definitely have representation being planned for Node plus

JS Interactive, which is the next kind of bigger conferences y'all have here in the fall, which is exciting. Oh, that's great. Yeah, I'm really thrilled to hear that. And we're going to be setting up podcasting booths on the floor of KubeCon, CloudNativeCon, because there's so much interest here, and we really do want to facilitate getting this message out to a wider audience. That's exciting. This is news to me, and I'm excited about that. We've done something similar when we've gone to Microsoft Build

or a few different events there where they've actually given us reserved space to do and help schedule and just really plan our content well. So that's awesome to hear. And you know we're going to be in the washington state convention center which is where same place was yeah i think back in the end of may or june yeah and so it's it is wild now to be filling up that kind of space we actually with still with um two months left we have 143 different sponsors lined up for that event. And we're not going to be announcing the schedule for another two weeks. But I can say that based on the slots we have available for three days and the number of submissions, we had a 13% acceptance rate for the papers.

So it really just speaks to the level of interest in this community. The conference alone has got to be several folks, full-time day jobs to just manage, not only like the sponsors, as you mentioned, but 7,000 people. When I was there in December in Austin, that was around 4,200. And then the next one was in Copenhagen. You said 4,300. And now you're adding another, you know, little shy of, you know, 2,800 people or so to the next U.S.-based conference. I mean, you're not only scaling your technologies, but also obviously scaling in a community and a conference that can actually sustain that and entertain it and make it worthwhile to spend whatever money it is and the time involved to come there and actually get benefit. Yeah, and we are very cognizant that for the sponsors, it's a significant outlay of money. Although, I mean, we do offer a great deal for small startups, but companies spend a lot of money on this.

Then, you know, for those 7,000 people, most of them are flying in. They're taking times away from their families. It's the hotel and such. And so there are real expenses there. aspects of community building that because all these communities mainly exist online, that ability to come together at least once, and for a lot of people, they'll do both North America and Europe. So twice a year makes them so much more effective online when they can kind of connect together that email or that what otherwise might seem a mean Slack comment and can kind of see the wry humor behind it. And I definitely want to give a big shout out to the Linux Foundation events team. So we're able to leverage that same events team that puts on the Open Source Summit and Node Interactive and others. And it is a little crazy that literally just 18 months ago, we were in Seattle for our event and we had a thousand people there. And so to go 7X in two years definitely has required staffing up and just a whole set of different processes and approaches on it. What's been really nice is that we get to keep iterating.

So if we just tried to create a new 7,000 person event from scratch, I think that would probably be impossible. But the fact that they are growing and we can see the things that work and things we want to do differently. And I particularly want to give a shout out to our two co-chairs. These are leaders in the community who we bring on and put a significant amount of effort into managing the program committee and picking the keynote speakers and organizing the submissions into coherent tracks. And for our event in Shanghai and Seattle, that's Liz Rice of Aqua Security and Janet Kuo of Google. And they've just been doing fantastic work on organizing all this. And it is quite involved, though.

Just because we're on the subject and not that it's completely pertinent to the conversation, I'm just kind of curious in the moments as we're there. The last show, Jared and I did some back of the napkin stuff where we were talking about memberships and just kind of trying to really grasp the amount of money being put into the foundation and the future essentially of cloud native. But I'm kind of curious, the conferences as it relates to being a profit center and maybe how it helps financially the ebbs and flows. Is that a big player in it? Is it sort of a break even? How do you treat conferences? Just really curious.

Sure. We're not trying to run them at a huge profit. And so, I mean, you certainly can go to a fancier conference in terms of the quality of the food. I mean, we don't want it to feel opulent because we think that would be wrong for a community conference. But the reality is that, in particular, Seattle has grown so much that it will spin off some meaningful profit this year. And what's nice is that CNCF as an organization, we're part of the Linux Foundation, we're nonprofit. And so we're not, well, first of all, we don't have a way of collecting profits. I don't get a bonus or a commission or anything like that. And so,

but more to the point, our leaders, our membership, and particularly our governing board, which is primarily the platinum members, don't want us to run a significant profit. So we try and keep like a 5% reserve just out of some financial conservatism. And then the rest of the money, we're investing it back into the community. And so one example of that, so I think people might be aware that we've rolled out this. Actually, now that I think about it, I think we were just planning to do it when we spoke a year ago. So let me give you a quick pitch for the certified Kubernetes program. And Kubernetes is open source. It's available for free. Anybody can just download it and run it. But kind of like with Linux, the majority of people who use it are

going to use it via a distribution or via a hosted platform. And so there's this concern that as people make changes to it, does it remain Kubernetes? How can you avoid having it fork in an unhelpful way? And CNCF, working very closely with the Kubernetes community and Kubernetes leadership, put together a conformance program. And what's neat about it is all of the tests for it are open source and are built into Kubernetes itself and are the tests that are always being run. that has a distribution or an installer or a hosted platform like Google Kubernetes Engine or Elastic Kubernetes Service on Amazon can run that conformance suite, upload the test logs to a public GitHub site, and then we mark them as conformant. And that's both a sort of mark that customers should look for. It also gives them the additional permission of using the term Kubernetes in their product name. And we've gotten just insane, fantastic

participation and engagement in this program where we launched it literally a year ago in Austin and now have 67 different companies that have gone through this process. So we've just been able to swoop up the entire industry. And what's neat about it is that although the vendor itself self-certifies and uploads that, any future user can come along and run that same conformance test suite and confirm that nothing has changed since they certified. So there's a kind of a crowdsourced aspect to confirming that and validating that certification. And then in addition, the certification when you do it is good for a year, but it goes away unless you certify a newer version. And so we're specifically trying to

avoid issues where people jump off the release train and don't keep up with the newer features. So both of those have really been quite positive aspects of it. One of the challenges is that there's some technical debt built up in the Kubernetes community. All new features that come along include conformance tests to cover them, but some of the initial features as they were deployed didn't have conformance tests. And so as an example, even though CNCF doesn't normally fund actual engineering development, we do have the resources right now that we're working with an external test development company and trying to fill out some of those conformance tests for earlier work.

And that's just one of the ways that we can kind of help out the community and help all this work better together. What's the motivating factor for the 60-something-odd companies to go through this process? Is it to legitimize their products and services in the eyes of potential customers? Definitely, yeah. You really don't want to be out there with a non-certified version of Kubernetes. It would be the most natural thing for a customer to say, why aren't you certified? Why did you do it? Yeah, because it would almost be as if they were anti-being certified.

What are the motivations for that? That might mean they're sort of anti the direction that CNCF and Kubernetes and Prometheus and all these others are, the directions you're heading, essentially, for some reason they're against it. Figure out why. You mentioned also being able to use the Kubernetes brand name in product services too. Yeah, so that's an extra carrot. There's no requirement to do that. Gotcha. So is the conformance simply technical, the test, pass the tests?

Or is there also like a financial requirement or agree to do certain things? Yeah. Requirement is to be a member of CNCF. And so for a small startup, that's $7,000 a year. But there's actually a couple nonprofit or community distributions of Kubernetes, really pretty neat as its own open source project, and that's called DevStats. contributions and pull requests and issues and aging, really trying to just keep up on the project. And particularly where Kubernetes is now split between about 30 special interest groups, trying to track which of those SIGs are kind of falling behind or might need extra help or need to invest more effort in things. And then also kind of which companies are making contributions, which developers. And how it works is pretty neat where there's a great free service called GitHub Archive that takes all 80 million or so GitHub repos that are public and every event that's happened to any one of those. And what's amazing is we download that terabyte

or so of data, and then we throw out 79.99 million of them and just keep the 80 or so Kubernetes repos plus the 100 or so other repos for the other 25 CNCF projects. And we go through all of those and do a bunch of analysis and put it into a time series database using Postgres and then have a Grafana front end to it that allows you to do these queries and visualizations and such. And so that's a project that we built out. A CNCF contractor works full time on it Lukasz Glecki in Poland. But he and I started this about a year ago, and the initial version was perfectly fine,

but the real value has been iterating it over the course of the last year with the Kubernetes community as they've had sort of very specific detailed requests for understanding different kinds of processes and graphs and such. And so that's just another area where CNCF can invest in development infrastructure that then hopefully allows the community to function better. Yeah, this is very neat.

I'm just pulling it up as you're talking about it and it allows such tracking as hourly activity on GitHub, different stats around the communities, summaries, there's issues, ages, all this kind of metadata around these projects. I can see this being useful in general for any project or anything. Yeah, I would emphasize that it's an open source project on its own. And so for other projects that would like to get these kinds of statistics, we'd really encourage you. There's a couple that have started doing it, but we'd encourage you to give it a try. And if you do run into issues, kind of porting it over to your project, you can just

file open issues on the repo with us, and we're happy to work with you on it. But as an example, we have the statistic that across all 26 CNCF projects, there've been 40,086 unique contributors to them. And it's really pretty amazing to, I mean, that's obviously a massive number, but it's also just neat to be able to track all of that. That's the first time I'm seeing this. This is really,

like you said, they're really useful for not just Kubernetes and CNCF, but other projects as well. This is really cool. Yeah. It also builds on GitDM, which was originally written by John Corbett of Linux Weekly News and Greg Kroll Hartman, the stable kernel maintainer.

And so, I mean, we're building on a lot of other work that was done here. We're using, I mean, obviously all this great open source software like GitHub Archive and Grafana and such, Postgres. And I also will give a shout out to Packet, the bare metal hosting company who contributes free server resources for us to run all this. It's kind of an involved process to go through all of that data. And every now and then we make changes to it and have to rerun everything from scratch. And we can actually do that in just a couple hours

on one of these 48-way servers. Well, we're big fans of GitHub Archive. We've been using that for years to generate our changelog nightly email, where they were only concerned about the most recent 24-hours events, specifically star events. I love seeing other people use the same data set for wildly different ways.

This seems like a very useful way of going about that. Glad it's open source. I think a lot of people can definitely benefit. Check it out. Devstats.cncf.io. Links in the show notes. Click around. If it's interesting, it's kind of like

GitHub Pulse on steroids. Remember the pulses? Trying to get the idea of what's going on with this project lately. Oh, definitely. This is like for the entire history of these things. It's very neat. Well, and particularly for something like Kubernetes, where it's across many different repos. Right. You can aggregate it. You have this, every SIG, every file, all like the 80,000 files or so are supposed to be owned by a specific SIG.

But that mapping isn't transparent. So the fact that we're able to do all that in a more complex project really lets you dive in in a more detailed way. I guess one other project I might mention, I referred to it before, is CNCF's interactive cloud native landscape. And that's at l.cncf.io. And this was kind of a personal passion project where it partly came from getting so many complaints about that crazy static landscape document with more than 500 boxes on it. But also, just as I tried to stay familiar with this space, for any given project that I'd hear about, I would always do kind of the same set of searches of look it up on GitHub and how many stars and contributors did it have, and then look it up on Crunchbase and say, oh, well, the company

behind it, how much funding did they get, when were they founded, that kind of thing. And so this is a, again, a free open source project and service that does all of that for you. And one of the powerful aspects is just a lot of filtering and sorting that we built into it. So if, for example, if you're looking at it and over on the left side under example filters, if you click open source by age, this is, since you're kind of historians of open source, I've been following this space. It's pretty interesting to see, oh, here's the projects in the cloud native space. And then if you click on Postgres, you can see, oh, that was founded 22 years ago, and its latest commit was this week, which is really such an extraordinary level of success and engagement. And then the next two are MariaDB

and MySQL. And of course, they're forks of each other. So they were both founded 18 years ago. And then going forward, you see things like Ceph that 17 years ago and Nginx and MuleSoft and Puppet and others. And so that's one view. But then another one that's kind of fun is click on open source by stars. OK, you can see Kubernetes is number one there with 40,000. But things like Elastic and Ansible, Redis, Serverless, Grafana. And then another neat one is offerings from China. So that you can see that we're up to 55 products and projects that we're tracking.

They have a total of 18,000 stars. The companies behind them have a market cap of a trillion dollars and have raised funding of $158 million. I'm glad you said that because on the top there, I couldn't help but notice it says you are viewing 578 cards with a total of 1,227,438 stars. That's as of right now, I'm assuming. With a market cap, get this, $7.02 trillion and funding of $19.8 billion. Yeah, it's really quite a number. I mean, it's good that it summarizes it, but that's gigantic. You're mentioning just China at a trillion, $7.2 trillion at market cap.

Yeah, and what's fun about it, so as you look at different views that's updated, and then what's neat is that we go to Crunchbase and to Yahoo Finance every night and fetch the updated data. So we're essentially doing a lot of scraping, and then this automatically updates every day. This episode is brought to you by DigitalOcean. They now have CPU optimized droplets with dedicated hyper threads from best in class Intel CPUs for all your machine learning and batch processing needs. You can easily spin up their one-click machine learning and ai application image this gives you immediate access to python 3 r jupiter notebook tensorflow scikit and pytorch use our special link to get a hundred dollar credit for digital ocean and try today for free once again do CEO slash change log so I find kind of interesting looking at this you know interactive landscape is that the economies, the corporate economies out there, which is, you know, in a lot of ways what this represents, it's, you know, sure, it's startups, but it's economies of scale for, you know, different businesses, places of employment, new technologies, but the sheer dependence upon open source and the health of those communities right you see this gigantic market cap which we just sort of like glossed over to some degree and then the investments that went into it to make it

happen but you know while it's very informative to what the landscape represents in terms of the companies and the projects and the influences and the stars and the start dates and all that stuff what it really represents in some cases or maybe behind the scenes, is the significance of the dependence of open source and the reliance on the health of those communities. And CNCF is operating very healthily, but that's what it represents to me. What do you guys think about that? Oh, I totally agree.

And I think you will recall that I helped co-found the Core Infrastructure Initiative four years ago. And you previously had David Wheeler on the show talking about the badge app project. And I co-created that with him. That that's a way of open source projects talking about their health and things like the bus factor and licensing and, and other kinds of stuff.

And, and by the way, for any, any project to graduate and CNCF, they're required to get that passing best practices badge. So the first two projects this year graduated Kubernetes and Prometheus. But I think it is fair to say that I've seen now the entire range of open source projects from extremely unhealthy ones like OpenSSL prior to Heartbleed, when you just had a couple of very underpaid developers and huge, almost universal reliance on it across the

industry, to kind of the most healthiest projects, which Kubernetes basically falls into, where you have dozens and dozens of the biggest companies in the world that are eager to fund it and move it forward. Yeah, the discrepancy between those things. And just thinking about OpenSSL was a blind spot and one that hopefully we all learn from. And a lot of these initiatives came out of heartbleed. It was kind of an eye-opening moment and just thinking you know 20 billion dollars funding these 578 you know uh call them cards here are these repo ask i don't know exactly what the card represents necessarily is it each one a repository

or a grouping of repositories it's a grouping so it's either an open source project or a closed source product. Gotcha. So, you know, 500 plus of those adding up to funding of around $20 billion is a lot of money. And there's so many other projects, maybe because they're not infrastructure, but that are struggling to get, you know, 100 grand scratched together to support what they're doing or heck uh five thousand dollars for uh some of their needs and so i just see this huge discrepancy between kind of the rich and the poor even in open source which makes me a little bit sad but it's just kind of i would love to um to say that uh that whatever that one percent ninety nine percent concept uh doesn't hold but i think it it really does in open source. And of course, if you look at, you know, 80 million open source projects on GitHub, it's only the 0.001% that would ever really be interested in or qualify for coming into CMCF or being a Linux Foundation project

like Node or such. And so I do think there's a lot of interesting efforts out there on crowdfunding and otherwise to try and support this. But certainly the cloud-native community, where it's an infrastructure, fundamentally it's an infrastructure play, and lots of real companies out there are very comfortable paying for infrastructure, the economics seem more solid.

It's just a lot easier to get them on the sale. It doesn't take much. They're used to it, as you said. Whereas others, it may. The reliance on open sources, in a lot of cases, it's informal and it's done through insider working groups. Even CEOs or people in charge are not even that aware. I'm not saying that everyone is like this, but it seems to be some of the cases in non-infrastructure plays, essentially, where you may not really be aware of how much you're depending on open source, and yet, you know, your business thrives because of it.

Yeah, it's my view that it's essentially, there's a nice description of transistors 30 years ago, that you have to waste them or your cost structure will kill you that if you waste millions of them to make your TV screen look slightly nicer. And it's my view today that if you were... So every company is becoming a software company. Software is definitely eating the world. But if you're not building on top of open source, it's essentially going to be impossible for you to stay competitive and to keep up. And so I'm certainly eager to see more solutions that help companies understand all of the open source dependencies, all the library dependencies that they have,

both closed source and open source. I think that's absolutely essential from a security standpoint. And then look at helping to have some funding solutions that go with that. The Linux Foundation is definitely actively investigating that space. It seems like an easier sell as well

in terms of like if I'm upper management at a profitable company and I have a budget for infrastructure costs and I'm used to paying historically licenses or paying for software that is now being provided as open source, that just opened up a huge aspect of my budget. And it's because of open source that it opened it up. And so maybe I don't put the entire budget back into open source, but maybe I divvy it out and say, okay, well,

because I would be paying for licenses for this stuff. And this is better software than probably the proprietary stuff because of the, the wisdom of the crowds or just the, you know, the joint efforts across all these different smart people. Well, it's not much of a stretch to then, you know,

pour, pour back into that and, and really support it. Yeah, I totally agree. So you've had, you've had massive growth both on the member side, which helped me with the verbiage, member

are the companies that are putting their money in, and then you have the project side. Is that what you call it? The Kubernetes and the projects. But also the envoys and Jaeger and Helm and that, so the tasks.

And those are all the open source projects licensed under Apache 2.0 that anyone can engage with. So you've moved from 8 to 26 projects, and from 20 to 59 members, roughly, and those numbers, repeating them back. Oh, that was end user members. Oh, okay. So there's another party. Almost 300 members, 59 of them are end user companies, folks like Bloomberg and eBay and JP Morgan and others that are using these technologies internally, but are not vendors. Okay. All right. So that makes sense.

So 300 members, is that the number then of the people? 292 as of today. Okay. I rounded them. We're almost there. Yeah. I was writing down your stats and i must have rounded that one well point is that you've grown mass like we've we've talked about the massive growth but i want to talk about specifically scaling to the projects and and what's provided you know so far we've talked about you know funding um cncf offers these foundations offer kind of a host of services to the projects. You move from 8 to 26. So is the foundation itself also scaling with regards to operations,

staff, the needs? Are these projects putting more stress and strain on the foundation in order to support them? Oh, definitely. And we've needed to hire more people. And then we've just needed to standardize a lot of processes. So the CNCF started with just Kubernetes. And then it took six months or something for us to get Prometheus. And then I think FluentD was number three after like eight months. So during those phases, if you needed something, you would just send an email to me or our chief operating officer, Chris Sanchak, and say, hey, can you help us with this event? Oh, I need to set up an account for so-and-so.

Oh, I'm having this issue. And that worked fine at first, but I think almost like any organization or software company, you just have to put processes in place going forward. So we have something we call the service desk, and it's just a ticket tracking system. But any of the maintainers of any of those 26 projects can, in principle, ask for anything. And conveniently, we've had the budget so far that we haven't needed to turn them down for a lot or for much at all. But the specific requests tend to be, I mean, a lot of them are just like super minor things like, oh, can we have run a community event for about 250 people. Can you help us organize that, handle all the money for us, for the sponsors that want to come in, help us sell it and such? And so we're very happy to do it. And then, you know, presenting to our end user community, engagement there. All of our projects are very eager to be involved in KubeCon and CloudNativeCon. And so although we do have this competitive track system, we also have slots, intro and deep dive slots for each of the projects. And so they definitely appreciate that opportunity to get in front of the audiences.

We do a lot of work with them on social media, on press relations and analyst relations, on giving them some kind of tracking on how things are going. So, I mean, one way of thinking about it is that if you're a big company like a Red Hat or a Google and you have an open source project that you're trying to promote, you know, for commercial reasons, your company can provide you with a set of services. But what we're suggesting is that for a lot of core cloud-native projects, it's much better for it to be hosted by a neutral foundation, but you're still going to want those services. And so we try and provide a lot of those same things. I mentioned the certification process, and we also offer training courses with it. And then thankfully, it hasn't been that involved yet, but we also offer a variety of legal services around trademarks, contributor license agreement. If they want that, we generally recommend that projects instead go with the DCO, the developer certificate of origin, which, as you may know, originated with Linux.

And so we just work with the projects here. But the sort of bigger picture is that what a foundation provides and needs to provide has certainly changed significantly in the last 20 years, where, you know, when Apache started up, it was a huge deal to have a source code repository, to have a web page, to have some basic kind of continuous integration infrastructure. And today, basically any open source project can get that for free from GitHub, from Travis and CircleCI and similar kinds of services. And we actually encourage them to do that. We don't try and move them over to our infrastructure. But we do try and provide a set of services that remain useful. I saw a headline a few days ago, and I think this question is more so an outsider looking in about google kind of handing over some of since we're talking about you know the infrastructure involved and serving you know

i think it's kubernetes at large not so much cncf and i know you kind of get questions of like like this that might be not exactly cncf and they're more kubernetes and i saw a headline where they stepped away from the infrastructure and donated a bunch of Google Cloud credits. I think it was $9 million in credits, which is huge. But I think it was more so the question I have is around how the responsibility of maintaining is spread across other big players. Is that kind of what that play was about? Is that kind of what that play was about? Is that happening? Is the responsibility of, you know, maintaining Kubernetes on that infrastructure side, you know, held well across the board or is it sort of lopsided? Yeah, let me dive into that. And you saw both the announcement and also kind of an annoying tech crunch.

Yeah. Clickbait headline where they said. They got me. They got me. Yes. Google stepping away from Kubernetes, which is not at all correct. I was like, yeah. Well, yeah. And for what it's worth, even the content of the article didn't have that as well. But obviously, the headline writer gets compensated by clicks.

And that's what, you know, maybe their A-B testing should have gotten. Seems like TechCrunch is moving beyond their core competencies in covering these technical things. I'm not going to go there. Yeah. I see a few articles on there. I'm like, are they writing about this? This seems like nerdier than they're supposed to be writing about. The counter-argument is that the headline writer was completely successful because you saw that headline and not the other 20 that got written up about it. But the first piece of background is that Kubernetes was originally a Google project. It was founded in Google as a piece of background is that Kubernetes was originally a Google project. It was founded in Google as a piece of infrastructure to share a lot of the expertise that they'd built up over the previous 15 years with their internal kernel orchestration system called Borg.

And so I draw the story of saying, well, you know, they came up with Kubernetes, and it was literally just four years ago was the first commit to the repo. So this is not an old piece of software, although the engineering and the ideas behind it were all built on that previous system. And at that moment, they had kind of four directions they could have kept it as an in-house proprietary offering, which would have been analogous to Amazon's Elastic Container Service. And they realized that that would definitely have limited its adoption. They could have open sourced it and kept it under Google control, which is essentially what they've done with Go. And, you know, Go is a fabulously successful language. Many CNCF projects are written in it, many other projects. People have a lot of respect and confidence in Rob Pike's architectural choices. The next level that would have been more open is

they could have come to the Linux Foundation and said, hey, we think this is a really important project. We'd like there to be a Kubernetes foundation. And at the end of the day, the Linux foundation probably would have said, sure, fine, we'll do that for you. But they actually chose what I consider the most open path, which is they said, we would like there to be a foundation. We'd like Kubernetes to be the anchor tenant, but we think that it's only a part,

a core part of the solution. And we'd like to foster a whole ecosystem of projects around it. And so that was the Cloud Native Computing Foundation. And I mean, I think it's fair to say, I've spoken to Craig McLuckie and Sarah Novotny, were two of the key Google people. And through that whole process that CNCF and Kubernetes growth has far, far exceeded their original expectations or even their hopes from when they did that three years ago. But as part of that, it's starting out as a Google project. The Kubernetes community then needed to put together a governance and a process and a leadership structure. And that took them about a year and a half, and they had a lot of arguments and disagreements.

And what's interesting is that CNCF doesn't impose that on any of our projects. There is no CNCF way the same way that there's an Apache way. Instead, we ask that each of our projects come up with a governance process. We are willing to help them with it, and we do help them with it if they ask for it. And we ask that they document it. So they have a governance.md file or the equivalent, and then that they follow that process that they've laid out. So that governance process was the last step for Kubernetes to graduate in March. And when that happened, there's several Google people on the steering committee, which is the ultimately in charge of Kubernetes. But they're not a majority. There's no company that has a majority.

And so they gave up kind of governance control at that point. But then this was the kind of remaining issue where to build Kubernetes, the actual software development infrastructure, is a huge undertaking. Unlike Linux, where most kernel developers can try something and recompile it right on their machine and see the effect of it on their own machine, to really work with Kubernetes often requires a multi-server cluster of machines. And so every pull request that comes in triggers a continuous integration run across many different machines. And that, for historical reasons, had always run on Google infrastructure, Google Cloud infrastructure. And so that meant that because they were internal Google accounts, that no external person from another company could manage that or be involved in it.

So it was a somewhat involved process. And this is exactly the kind of role that CNCF was happy and eager to take. But Google went back and calculated how many runs that they're doing. And it was a little tricky because they were conflating together their own service, Google Kubernetes Engine, GKE, with the Kubernetes project. They hadn't, because they originally hadn't been separated. So they have estimated that they think that $9 million in cloud credits will support the Kubernetes development for the next three years. But the thing to understand is that they essentially have already been spending that money over the last three years as well. They just weren't really

getting credit for it. And so what this announcement is, is kind of externalizing a function that they had already been playing. But that said, I mean, they are real credits. We have an account and it has a lot of zeros on the number of credit available. And then the key thing that it allows is that within the Kubernetes community, there's a SIG testing group, and within that, there'll probably be a new sub-SIG that focuses just on this infrastructure that non-Google people can also participate in that administration. But that said, Google in no way is stepping back. The Google folks who have been responsible for the infrastructure until now continue to actively be involved in it and expect to continue to be indefinitely.

The way you frame it is so much different. And listeners, that's why when you read tech headlines, sometimes I've read good articles on there, but then I've also read ones that are like, I mean, that kind of seems like you're putting words in somebody's mouth. And in this case, you know, based on your response, it totally was because it seemed like a slap in the face, like almost as if they've been putting so much in and now it's time for others to step up which i think was paraphrasing uh paraphrasing some of the content from the article and i was just like i will say if you reread the article it actually got a lot of the tone right it was really the

headline that just puts you in a certain frame of mind. And we do a lot of press outreach, and we've worked with that reporter and others. The reporters don't write their own headlines, but it's just a challenge of operating the space. And obviously, people are busy, so most folks really don't have the time to read the article. That headline did not give a good view on it. But I can confidently say that Google is as engaged as they ever have been. They're thrilled with the growth of the community, the growth, the level of adoption and engagement. And this is really answering a call from the community. And it's essentially the last piece of the Kubernetes project that was Google specific, that now Google does not have any more ownership or control than

anyone else, except that, you know, Google continues to contribute a huge amount of development and pull requests and fixes and such. And so that's the way that anyone has control in an open source project is by doing the work. So I have some pretty awesome news to share. We are now partnered with Algolia. If you've ever searched Hacker News, Teespring, Medium, Twitch, or even Product Hunt, then you've experienced the results of Algolia's search API. And as we expand our content, we knew that one day we'd have to either roll our own search solution on top of Postgres, or we could partner up with Algolia. And I'm happy to

report that phase one of our search is now powered by Algolia. We're able to fine tune our indexing, gain insights from search patterns and analytics we can create custom query rules to influence ranking behavior as well as improve our search experience by adding synonyms and alternative corrections to queries sure we could build search ourselves but that would mean we would be busy doing that instead of shipping shows like you're listening to right now huge thanks to our friends at algolia for working with us check the show notes for a link to get started for free or learn more by heading to algolia.com. And by GoCD.

GoCD is an open source continuous delivery server built by ThoughtWorks. Check them out at gocd.org or on GitHub at github.com slash gocd. GoCD provides continuous delivery out of the box with its built-in pipelines, advanced traceability, and value stream visualization. With GoCD, you can easily model, orchestrate, and visualize complex workflows from end to

end with no problem. They support Kubernetes and modern infrastructure with elastic on-demand agents and cloud deployments. To learn more about GoCD, visit gocd.org slash changelog. It's free to use, and they have professional support and enterprise add-ons available from ThoughtWorks. Once again, go cd.org slash changelog so dan the cncf does as you know because you're part of it, leader of it, a biannual survey that sort of surveys the landscape. And some of the insights from that essentially is, you know, serverless is on the rise. We kind of see that Jared and I as part of this show, you know, on JS Party, we're covering that.

On this show, we're covering that. Kubernetes dominating, which this whole conversation was about the growth. That's clear. But then you also have cloud native production usage exploding. And some of the top challenges not being technically how to deploy containers. What are some of these things you want to dive into that we can kind of cover from this survey that are insights for you that particularly stand out? Yeah, I would love to say that it was just this shocking result and really changed my thinking about where CNCF should be focused and what we should be doing. But I'm kind of pleased to say that it was kind of more of the same. I mean, just the fact that

we see so many actual end users at our conferences, that it's not just vendors talking to each other. And, you know, all the folks that we're talking to each other. And all the folks that we're talking to are talking about, yeah, last year I was really looking at Kubernetes in the lab or originally Docker to try and speed up some of my development processes. But now we're beginning to move these into production and we're looking at how to move more and more of our apps over to it. So I think, yeah, the production usage growing 200 percent, evaluation 372 percent, 40 percent of the enterprise companies we talk to are running Kubernetes in production are all pretty fantastic indicators of the engagement adoption. I guess one other piece that I would mention that I'm particularly passionate about is continuous integration and continuous deployment. That was the keynote that I gave in Copenhagen, arguing that continuous integration is actually probably the most

important part of the cloud-native architecture, that it's the thing that provides the most dramatic value to organizations that are not already doing it. That basic kind of sandy test of, is my software working? Can I redeploy it? Can I quickly make changes or improvements or fixes and get it out there to customers where they can benefit from it. What percentage, if you had a hazard, I guess, of corporations who are involved in the CNCF or that are on your purview are in the category of not having that step, like not having CICD going on and can benefit from it? And how many are doing it today? Oh, I think zero are not doing any kind of CICD. I mean, I think almost the kinds of organizations that are reaching out to CNCF

and getting involved are the ones who realize that this is important and that they need to get engaged and focus on it. We use this crossing the chasm metaphor that you may be familiar with the chart where we talk about our graduated projects as being suitable for the early majority, which are known as the pragmatists, that we really think that 2018 is the year that Kubernetes crossed the chasm. And then we talk about our incubating projects, our 8-inch being the ones that's being suitable for early adopters, and our sandbox projects, the the more immature being used by innovators or techies. But I'm very cognizant of the fact that at least half of businesses out there, those folks that are called the late majority and the laggards

have really not started down this path at all. And they have a huge amount of benefit in front of them. And then they have a big competitive challenge that their competitors are going to be out there with just much faster development velocity. I mean, it's great to say, oh, well, here's the efficiencies of better packing your applications into a fixed number of servers. But we think that the huge change, the huge benefit is just faster update cycles on your software about being able to respond in a more agile way. Yeah, ship on green is a big deal to teams once they get there to be able to, you know, our team is much smaller so, but I only have our example and we do have CI and CD in place here. It changed a lot when we deployed, but very small in comparison to

some of the other projects that may ship hundreds of times in a week. And what a change that is for velocity and for instant gratification towards innovation or getting a win that day or that week rather than when's the next deploy kind of thing. Yeah, and this was my keynote talk in Copenhagen. I'll include a link to the slide deck was titled, How Good Is Your Code? And so in a world where you are dependent on all of these libraries, and a lot of those libraries do have security bugs and issues that come up that you do need to fix. It's just absolutely essential that you be able to redeploy your software. And so I draw the analogy that it's almost like science that you may think it's that you have a hypothesis that you this change you just made to your code is great. But until you can actually pass your tests and redeploy it,

it just isn't a real thing yet. I was just seeing on Twitter, somebody, somebody that we know, Adam, I can't think of their name right now, who it was, you know, talking about deploying on Fridays and how it's a bad idea to deploy on Fridays and all that kind of stuff. And I was thinking, like, aren't you deploying every day, all day? Like, why is Friday special still? I like Etsy got a reputation a few years ago for, first of all, doing more than 50 deploys a day. But one of their ideas is that every new employee, including non-technical ones, would make a commit live to production on their first day of work.

Of course, you have to have a test process and a QA process and other kinds of things that you have the confidence that that can occur without anything breaking. But I think it really is a great model that not that every company can quite live up to that yet, but at least to try and move towards. So as we look a little bit towards the future, Dan, one of the questions we asked Jason McGee of Istio was about this landscape, really a lot of the change that's happening, all of these projects coming in, this idea of different layers of this cloud-native stack and where certain things start to formalize. He mentioned that basically we've come to consensus

that containers are a good thing, right? And that Kubernetes is pretty much winning its layer. Then you have service meshes, you have networking things, you have serverless. There's lots of other stuff that's either patching together lower layers or sitting on top. And one of the things I asked Tim,

and I'll ask you as well, as somebody who's interested in this stuff but does not have a vested interest in figuring out provisioning or figuring out orchestration or service meshes, but would want to eventually... I love the benefits of the cloud-native lifestyle. I want to be a cloud-native, right?

When do you think this is all going to shake out or maybe coagulate around a certain happy path or maybe choose your own adventure? A little bit, but less churn, less friction, less stuff changing all the time. Oh, I definitely think so. And I do think there's huge cognitive overhead in this interactive landscape. I mean, I will tell you that the landscape, the 570 projects, it's been described at times as helpful, as overwhelming, and as the hellscape.

The hellscape. The hellscape. That's one way to paint it. And that's by a leader in our community, I might add. But I'll leave him anonymous for now. But I think the simplest solution for it is, if you, especially if you're a startup, if you're a small organization, if you're coming in from a greenfield perspective, it's very likely that you're going to use a vendor for these things.

And that vendor might be a hosted cloud provider. It might be an enterprise software company that helps you run things on your own bare metal. And one of the great roles that those vendors take is that they pick the projects and the offerings that they think are ideal for their customers. And it's very, very likely as you get started in this space that whatever the vendor puts together for you, maybe your favorite cloud provider, is going to be perfectly fine. That to get up to speed on it, to get your logging working, monitoring, these other kinds of things that you can dive in and work with almost any of them. And then if you just find that your monitoring solution, that maybe it's a proprietary monitoring solution that you're paying too much money for,

or maybe it's the vendor's proprietary monitoring solution on their cloud, and you don't feel like it gives you enough flexibility or doesn't let you hook into all of your services the way you'd like it to, then it's a relatively natural step to look at that CNCF trail map and say, oh, I guess I could be looking at Prometheus. And, you know, maybe your vendor's already just offering a hosted version of Prometheus and you're either using it or it's easy to switch to it. But I really want to avoid this implication that you have to be familiar with all 570 options. There is this concept by actually a former professor of mine at Swarthmore named Barry Schwartz, the tyranny of choice, that having more options does not necessarily make you happier, and certainly makes it just overwhelming to try and make any kinds of decisions.

And so, you know, the CNCF projects in general somewhat represent a happy path where we can confidently say, hey, if you choose our graduated and incubating projects, we know they all work. We know that there's real end users adopting them. We know that there's vendors out there who are eager to support them. Your issues are going to get responded to. Maybe not that your pull request will get accepted. We can't go that far. But it's a pretty safe bet to engage and get invested in those communities. And then that's the other way to look at it, which is, okay, if you want to just go entirely open source, one of my favorite examples here is the company Bloomberg here in New York, who they just don't like working with vendors. They want to have all their expertise internally. They download 100% open source, and they make it work for themselves. And so CNCF represents a great kind of spotlight

and indicator for them of a set of projects that they can have confidence in the communities behind them. That's one thing I see that you do very well, especially with like this interactive landscape and just several other things we've gone through, like the dev stats, is that you're doing a great job of bubbling up the right information to make good choices. And you're not making the choices for the community, you're doing a great job of bubbling up the right information to make good choices. And you're not making the choices for the community. You're making aware of who's getting involved in Cloud Native and all that it is at all levels of the game.

And to me, it's like you're just doing a great job of sharing the right information so that folks like us can say, this is the direction for us to go, or this is a project that makes sense for us or areas where we can get involved or just like you said, have confidence in our choices rather than feeling like the CNCF is just saying, here's the best go use. Yeah. Forcing you to use it.

Yeah. So thank you for that. And I mean, I think it probably comes somewhat from my own perspective of having been the chief technology officer of a couple startups and co-founder of a couple others where it's hard to make these choices. And I've made them in the past. And to some degree, I made them incorrectly. And so there's also some humility built in here that I don't have the confidence that I can guarantee that every project involved with CNCF will be perfect for every end user out there. One of the kind of nice aspects of our philosophy is that we specifically don't have the approach of that there can only be one project per box. So an example right now is Linkerd and Envoy are both very capable service meshes.

But essentially, you're only going to choose one or the other. Or another one is Containerd and Rocket. And when we see that there's multiple offerings out there, we've been very willing, or the technical oversight committee's been willing to adopt multiple ones. Well, I think to rewind a little bit, that's kind of how it began was, you know, the question was, will Kubernetes win, you know, versus the other options?

And eventually, I believe the reason why you can probably stand firm in that is that, you know, the community will eventually choose a winner or select their own that makes sense for them. And maybe there's one or two or three winners, so to speak, but you don't need to choose. Sure. And another way of looking at it is, Mesos kind of had been the winner before Kubernetes came along. And I think Kubernetes has largely supplanted it.

But the reality is that there are still real, very substantial companies out there with massive Mesos implementations. And interestingly, if you're like a legacy brownfield enterprise and you're thinking, oh, I need to containerize and I want to go with Kubernetes, there's a huge advantage to you doing that. You're going to see big efficiency gains in your servers and development velocity and such. But if you've already invested all of this effort to get Mesos up and running, and it runs perfectly well in your data center today, and you've trained your teams on it and everything, the marginal value of you switching is really low. And you'll probably do that eventually. Maybe you'll start with a small

Kubernetes cluster for a few of your apps, and then maybe over time you'll move more and more. Or like Stripe had an interesting story where Mesos was working for them, but the cron functionality that they needed wasn't getting the attention and love it needed in Mesos. And so they switched over to Kubernetes. Julia Evans has a great blog post about that that I'll post in here and have invested in, and that's worked out well for them. But what's nice with the CNCF projects is that even in that scenario, you still can and should evaluate our other offerings. So Prometheus is also the leading monitoring application, not just for Kubernetes, but also for Mesos. Fluentd for logging works great with Mesos. And so we definitely are not trying to lock you into a certain technology choices. The metaphor we use for the landscape and for the trail map is that it's a kind of

preferred path or like a particularly well-trodden, well-lit path, but that all of us are trying to reach the same goal of the cloud native, getting to cloud native. That's the destination. But there's many different paths that you can take to get there. What's upcoming for you or for CNCF or any of the projects involved?

What's maybe something that's either not well-known or something you can tease that's coming up in the near horizon? It's, you know, this is barely September. We're just a few days into it. What's upcoming that you can tease around the show as a close? Sure. So I think the biggest thing that I would say, and that we didn't have a chance to chat about yet so much so far,

is the level of engagement and interest from China. And so that has been somewhat of a surprise to CNCF. And to me, Huawei was a founding Platinum member. But since then, we've added two others, Alibaba and JD.com, the two biggest retailers, e-commerce retailers in China. And then we've added Baidu and Tencent and ZTE as gold members, and then dozens of silver and smaller companies. And so partly as a result from that huge level of engagement, we're launching our first ever KubeCon CloudNativeCon event in Shanghai, November 13th to 15th. And so if you're in China or really anywhere in Asia or Australia, and you haven't yet been willing to come to Europe or the US, I'd love to see you in Shanghai. We're going to have 100% of the talks, the keynotes, and the sessions will

have simultaneous interpretation into English and Chinese. And it's really just a neat process to see. We also just had our first two projects that originated from China, where the TaiKV that was built by a company in Beijing called PinkCap. And so on really all the different levels of engagement with China, training, our service providers, our certified Kubernetes, we're seeing that level of interest from China just skyrocket. And then, as I mentioned before, we would love to have people attend our KubeCon, CloudNativeCon event in Seattle. That's the flagship event. It's probably going to be 7,000 people. We have very good likelihood of selling out so if it is something you're thinking about

if your organization is investing in these technologies or seriously considering it we would love to see you there and definitely would recommend uh signing up so it's cube con k-u-b-e-c-o-n dot io good we'll be there as well that's december 10th and 13th so in seattle at washington state Center, which we've been there. It's great. It's easy to get to. Great city to be in. So if you can, make it out. Dan, thank you so much for your time. It's been a pleasure catching back up with you. Congrats on all the progress to you and the rest of the team.

I know it's a massive team behind you. You're not the only person doing this work. If so, then you'd have some issues. Definitely the case. But definitely you can see the you know the right directions for everything and we love playing a part with you in terms of catching up and being able to update the community on new things happening and where where uh you know where this is heading so awesome thanks for the chat thank you dan thanks dan all right thanks for tuning in this week.

If you enjoy the show, do us a favor. Rate it on iTunes. Tweet about it on Twitter. Share it in your favorite list of podcasts. And thank you to our sponsors, Hired, DigitalOcean, Algolia, and GoCD. Also, thanks to Fastly, our bandwidth partner. Head to fastly.com to learn more. And we catch your errors here at ChangeLog before our users do because of Rollbar. Check them out at rollbar.com. We're hosted on Leno Cloud servers. Thank you. at Breakmaster Cylinder. And you can find more shows just like this at changelog.com slash podcasts.

When you go there, check out our master feed if you want to get all of our shows, changelog.com slash master. Get every show we do, not just the change, but we produce lots of shows I'm sure you'll love. So check it out. And thanks for tuning in. We'll see you next week. Bye.