ADAM GLICK: Hi, and welcome to the Kubernetes Podcast from Google. I'm Adam Glick.

CRAIG BOX: And I'm Craig Box.

[MUSIC PLAYING]

CRAIG BOX: Happy holiday weekend to many people in the Northern Hemisphere.

ADAM GLICK: Indeed, it's Memorial Day here in the United States, or at least as we're recording, it is. So I want to say thank you to all of you who have served or are helping support members of your family who are serving. We do appreciate that.

CRAIG BOX: It's Spring Bank Holiday Day in the UK, a day that they don't really have a purpose for, other than they have a certain number that they want to make up. And they think spring is generally a nice time to have one.

ADAM GLICK: Is that the title of the holiday?

CRAIG BOX: It is officially "Spring Bank Holiday".

ADAM GLICK: I love it. [CHUCKLES]

CRAIG BOX: They have two bank holidays in May. The first one's called May Day, and this one is sometimes called "the second one".

ADAM GLICK: And what have you done with this fine holiday?

CRAIG BOX: Well, I've chatted to you obviously.

ADAM GLICK: Oh, excellent use.

CRAIG BOX: To all our colleagues at Google, we hope you enjoyed Sundar Day. One of the newer holidays, but still, we hope it will be on the calendar every year.

ADAM GLICK: Yes, indeed. I was chatting with my team and sent out a picture of what I was doing with my day, which was getting a chance to play with my daughter and giving my wife a little bit of time away from taking care of the kid. And I just tagged that hashtag-#SundarDay.

CRAIG BOX: I know you like puzzles, and I do on occasion get time to do puzzles. But something that's popped up on my YouTube feed recently is a YouTube channel called Cracking the Cryptic. And it's two guys, one of them in particular who's become quite famous over the last few weeks. He solved Sudokus in 20 odd minutes or so. He's a world Sudoku champion type.

But he's given up his job as a trader, and he's got four million views on one of his most recent videos. And all these people are just transfixed at the idea of watching this guy whiz through these interesting puzzles. Thoroughly recommend it. I warn you that it's something that even if you don't solve Sudokus as a general rule, you might just get hooked on it and find yourself watching this guy over and over again, twice a day maybe.

ADAM GLICK: I'm curious to see this. I caught another interesting puzzle thing this weekend where I've gotten into these puzzle boxes, and you know the various puzzles you people see, bar puzzles and such? And someone actually goes and builds them out of Legos, which I just think is phenomenal and astounding.

And he has the whole build that he does on his YouTube channel, the various boxes that he's built. And so there's both videos of people trying to solve his boxes, as well as him doing the actual creation and design of the boxes. And if you ever thought about what it takes to build something like that and you've got a big bucket of Legos from your kids, you want to try some of these, it's a great channel full of builds for these interesting puzzle boxes.

CRAIG BOX: So now we shall solve the puzzle of how we get to the news?

ADAM GLICK: [LAUGHS] Oh, smooth as butter segue there. Let's get to the news.

[MUSIC PLAYING]

CRAIG BOX: Istio 1.6 is out. This new release brings further improvements to the installation process and mesh upgrades, including support for running multiple versions of the control plane concurrently to allow canary testing of upgrades.

A new workload entry resource makes it easier to add VM workloads to the mesh. And experimental support has been introduced for the Kubernetes Service APIs, as discussed on the last week's show. This week also marks three years since the first release of the Istio project.

ADAM GLICK: At the virtual build event last week, Microsoft announced the Azure Arc preview, now includes Kubernetes support. Arc lets you register clusters that appear in Azure portal, have an Azure resource manager ID, and have a managed identity. All clusters are supported, but partners for the launch are Red Hat, Canonical, and Rancher.

Additionally, this week's release of Azure Kubernetes Service brings Windows Server container support to GA on Azure Government Cloud, integration with Azure Resource Health, and support for generation 2 VMs in public preview.

CRAIG BOX: GKE has added container threat detection in beta. This tool can detect the most common container runtime attacks and alert you in the Cloud Security Command Center or cloud logging. Container threat detection includes several detection capabilities, an analysis tool, and an API.

ADAM GLICK: TriggerMesh has released a public preview of EveryBridge, their serverless event bus. First announced in November, EveryBridge connects a number of events sources, including legacy message queues, cloud infrastructure, SaaS apps, e-commerce systems, and source control, and allows them to trigger functions running in the cloud or on Kubernetes.

CRAIG BOX: MinIO has released KES, a stateless and distributed key management system that runs in Kubernetes. KES isn't a KMS in and of itself but instead is a bridge between a cloud or software key management system and your cloud native apps. The introductory post says that this makes the KMS technologies easier to use, more portable from developing machines to production, and easier to scale. KES is open source and available under the AGPLv3 license.

ADAM GLICK: StackRox has added new features to their Kubernetes security platform to help with incident response and analysis. The features include timeline views and compliance checks for US federal benchmarks.

CRAIG BOX: The Open Policy Agent project released results of a recent survey. The creators suggest that most organizations use OPA for multiple use cases, with application authorization becoming a dominant use case. The plurality of respondents had over 100 microservices, which suggests that the project is most popular with people running at scale. OPA-created Styra have also released an update to their commercial product named Declarative Authorization Service to add support for microservices authorization. Learn more about OPA and Styra in episode 101.

ADAM GLICK: Rancher has announced Rancher Academy, an online training and certification program. The vendor is currently offering a Level 1 course which deals with installing Rancher Kubernetes Engine. Docker and Kubernetes fundamentals are explicitly excluded, as those skills are taught elsewhere. The course is a self-paced five-week course with knowledge checks and a final test. Recertification is required on a yearly basis.

CRAIG BOX: Google Cloud has posted more information about their bare metal plans for Anthos. Users will have a choice of running on Red Hat Enterprise Linux, CentOS, or Ubuntu, all of which will be supported and validated by Google. Google also announced an expansion to their Anthos-ready partner initiative to include bare metal technologies and partners.

ADAM GLICK: Security vendor Snyk announced a partnership with Docker to build their security tools into Docker Desktop. The joint solution will integrate scanning on Docker Desktop so that developers can check for security issues while they are writing code and adding new dependencies. Docker Hub integration will allow the whole team to see any vulnerabilities once images are pushed to the hub.

CRAIG BOX: Finally, tech blog of the week is from Atomist, where David Dooling looks at all the different kubectl commands that can be used to mutate a Kubernetes object. Apply, edit, patch, and replace all use the HTTP PATCH verb under the hood but all behave in different ways. His post explains the various approaches and when to use each, as well as when you should just replace an object rather than patching it.

ADAM GLICK: And that's the news.

[MUSIC PLAYING]

CRAIG BOX: Chip Childers is the executive director at the Cloud Foundry Foundation. His past roles have included various product and engineering leadership positions in the web development, infrastructure software, and hosting industries. He is a member of the Apache Software Foundation and a past board member of the DMTF standards organization. Welcome to the show, Chip.

CHIP CHILDERS: Thanks for having me. Happy to be here.

CRAIG BOX: Adam and I were both very excited when we heard that you were involved in the DMTF, so I wanted to start by asking you what your favorite touchtone was?

CHIP CHILDERS: [LAUGH] Yes, yes, what was that, the little bit of "lysdexia" that's kicked in? The DMTF is the Distributed Management Task Force. It's a standards organization that I was involved in briefly that's very focused on operational APIs for data center infrastructure.

CRAIG BOX: But still equally important, I'm sure.

CHIP CHILDERS: Perhaps less so. We all need our phones these days.

ADAM GLICK: True enough, though we make phone calls on them less and less, I find. My phone is now more like a Star Trek universal communicator than it is like an actual telephone because the last time I actually put it up to my head and spoke into it was probably a couple of years ago.

CHIP CHILDERS: Absolutely. There's been a video that's been floating around where it looks like two parents challenged their teenage children to figure out how to use a rotary phone.

[LAUGHTER]

And they recorded it. This is the type of thing that we're doing now that we're all at home, right? So they put it there, and then they wrote down a phone number to call. And they handed the phone number to them and said, please try to figure out how to call that number. And it was five minutes of hilarity. They needed a lot of hints.

ADAM GLICK: Excellent. I can just hear someone out there just listening to this and thinking, "OK, boomers".

[LAUGHTER]

CHIP CHILDERS: That's fine.

ADAM GLICK: Your career started before cloud, speaking of back in the day. How did cloud first come into your career in your time?

CHIP CHILDERS: My career started back in the late '90s. But the concept of cloud started to come in when I was at a hosting provider. And Amazon first launched EC2, and it was kind of like, oh, that's kind of interesting, great. It's a hosting service. But they started to grow and grow and grow their capabilities. And what we had to do was to figure out how to transition a lot of our business to a much more automated system.

And kind of to that point, we had been dealing with things like MPLS backbone automation, making sure that we could do things like connectivity between different data centers. And that's where a lot of our automation work was happening. But then we had to kind of pivot a bit, retool, and spend a lot of time thinking about virtual machine automation, virtual network configuration.

We had plenty of battles with lots of the network vendors that really just didn't understand why we wanted an API in order to communicate with the devices that they were selling us.

CRAIG BOX: Was this where you first came across the CloudStack project?

CHIP CHILDERS: Yeah, it was a little bit after. Things move fast in enterprise tech, right? Especially when open source movements start rising. And so we ended up, before we embraced using open source, we'd basically build our own infrastructure as a service platform. It was quite useful. It dealt with a lot of the idiosyncratic nature of network storage devices that were just fundamentally not designed for this use case. Trying to kind of work around, how do you interact with the CLI in a way that might be deterministic? And so that was pretty fascinating.

We got involved in CloudStack when we sort of took a moment-- take a beat, right? Sometimes you create things because they don't otherwise exist, and then opensource catches up. There was CloudStack, Eucalyptus, OpenStack was growing. It was less mature at the time. And I guess a smattering of other kind of relevant open source initiatives.

And we did this whole bake off. We ended up picking CloudStack, which served our purpose, frankly, because it wasn't a lot of complexity. And really the job of infrastructure software-- and this is something that gets forgotten a lot. The job of infrastructure software is to be boring and work. And that sounds funny to say, oh, people forget that.

But we do, right? We get all excited about the latest flavor of infrastructure software. And there might be new capabilities. There might be new possibilities that open up. We can have waves of innovation on top of these things. But that really doesn't happen until it starts to get boring. And then you have the new exciting thing on top of it. And that's something that carried forward even today when I talk to people about the state of things, state of projects, state of markets and ecosystems. When it gets boring, that's when it gets interesting on top of it.

CRAIG BOX: That's a bit paradoxical.

CHIP CHILDERS: Well, I think it's natural, right? You need to build a stable foundation. Otherwise, what are you doing? You don't want to spend a lot of time worrying about the trim on the house if you've built the foundation on mud and it's sinking. You have to build from something stable.

CRAIG BOX: It was a bit more like it sounded like you were saying that Bert from Sesame Street, he's really into paperclips. It's like there are some people for whom the boring and the mundane is really the thing that they're interested in.

CHIP CHILDERS: [LAUGH] Well, no, I'm not implying that the work is simple. I'm not implying that the challenges aren't there. I'm just implying that there is a maturation process that enterprise software has to get through. And the more exciting it is, the more likely that it's not quite mature. But then as things settle down, you're reaching a point of maturity, and then new waves of innovation can happen on top of it.

CRAIG BOX: A potted history of the CloudStack project: it was developed by a startup called Cloud.com, who probably would've made a lot of money selling that domain name.

CHIP CHILDERS: Yeah. A friend of mine, Peder Ulander, still talks about how he's the guy who bought Cloud.com.

CRAIG BOX: The project was open sourced in 2010, and then the company was acquired by Citrix, who donated the project to the Apache Software Foundation. How did you get involved with that governance piece?

CHIP CHILDERS: It was actually in conversations with Citrix about potentially making the CloudStack open source software part of our infrastructure as a service offering. One of our criteria as part of doing that was that they moved it into a place where there could be some neutral governance around it. Lots of reasons for that. Our primary reason, though, was just simply to ensure that as an end user-- actually as a customer of Citrix, we wanted to effectively hedge our bets, to say that if Citrix were to have a change in their commercial strategy and direction, that it would have been prepositioned so that users and potentially other vendors could build off of it.

And while infrastructure as a service has become not really that interesting in the open source space-- we've sort of moved to the container version of it-- CloudStack's a very healthy open source project if you were to measure it by is it being maintained? Are end users engaged in the project? And has it become boring and stable?

It's still out there. It's being used in quite a number of places globally, not so much in the US, but definitely a lot in South America, Europe, and some of the countries in Asia.

ADAM GLICK: You were previously the VP of CloudStack at the Apache Software Foundation.

CHIP CHILDERS: That is correct, yeah.

ADAM GLICK: What does it mean to be a vice president of an Apache project?

CHIP CHILDERS: No responsibilities here whatsoever.

[LAUGHTER]

CRAIG BOX: Did they give you a business card, at least?

CHIP CHILDERS: Absolutely not. I mean, I'm sure I could create one. And so ASF's really interesting as a study in the way that-- one very healthy approach to open source. There's lots of different approaches to open source. It has a particular approach. And that approach makes a presumption that individuals make up the community. And they do have a slight hierarchy of individuals, but there's no single person who's responsible for making decisions.

The reality, though, is that the ASF exists as a corporation as a charity. It's a charity that has to benefit the public good. And so therefore there are some things that it has to have in place in order for the protections that that corporation can provide to the community to actually exist. This kind of gets in the weeds a little bit.

But you could think of the VP of any particular ASF as someone who's, yeah, maybe they're willing to be the spokesperson because sometimes you talk to the press. You have a title. That makes it easy. But in reality, you're the officer of the corporation who can do things like make an agreement on behalf of the project within the organization.

But the actual community operates on a committee-based model. So the project management committee and then the group of committers. There's rules about who can veto things, how you bring new features into the community, new features into the project. The vice president or chair of the PMC has no ability to say what can and should be done. It's really just kind of a back office thing.

ADAM GLICK: Kind of like the queen in England, technically responsible for all legislation and things that happen. But as a functional matter, the parliament actually makes the decisions.

CRAIG BOX: Careful, Adam, she could still have me killed.

[LAUGHTER]

CHIP CHILDERS: I do think that's a good analogy, though. Yeah.

CRAIG BOX: As you say, the Apache Software Foundation is a charity, so presumably it doesn't pay its staff and you were still working a day job at this stage.

CHIP CHILDERS: Well yeah, absolutely. Those two things aren't necessarily correlated, right? There's no causation there. So the charities hire people all the time. The ASF happens to be structured with a strong bias toward all volunteerism. If you look at the ASF today, though, they do have paid staff for things like infrastructure services.

But there are so many projects. Being an officer in the ASF within the context of a project and many of the functions of the foundation like trademark management, the legal committee, those are all volunteer positions. The ASF is just choosing to use the donations that they receive to fund the types of roles where you have to be available 24/7. So think about those infrastructure services, the marketing and PR person. She gets some funding. But beyond that, it's a very volunteer-driven organization.

ADAM GLICK: At the creation of the Cloud Foundry Foundation in January 2015, you joined as the CTO. What was your experience with Cloud Foundry before that?

CHIP CHILDERS: When I was back at the service provider-- and I'll skip the one year at a startup that was a great learning experience, but I picked the wrong year to join because it was their last year.

[LAUGHTER]

So back at the service provider, I remember watching the first demonstration of Cloud Foundry and knowing that it was going to be opened up and realizing that as I was dealing with an infrastructure problem, the industry and the need of companies was moving up the stack to finding ways to provide cloud services that were thinking about applications and not thinking about virtualizing infrastructure.

Because that was really the first wave was virtualizing infrastructure at a larger scale than let's just say a V sphere or a XenServer cluster. So that's when I started paying attention to it. Now I ended up making a service broker that could tie into it and toying with it a few years later. But you're right. My first introduction in a much more material way was when I joined Sam Ramji as we kind of got that foundation off the ground.

It was effectively a handoff from at the time Pivotal as they had gathered a group of other companies around them. We took the handoff from Pivotal and kind of helped build the community around the project.

CRAIG BOX: What was the history of Cloud Foundry before it joined its own foundation?

CHIP CHILDERS: It's a long and winding history that starts with Derek Collison really leading the development of it. He should be pretty well known now because he continues to work on, promote, and participate in the development of NATS, the messaging framework.

CRAIG BOX: Yes.

CHIP CHILDERS: Yeah, so he'd come from Google. He went into VMware, as well as a bunch of others. Again, I was not there. But as the story goes, they had a vision. And this vision was to be the open version of Heroku. And so that's really what they were emulating. They were looking at Heroku as the platform as a service model saying, we can create an open version of this. We can take a lot of the engineering practices that Derek and others had brought in from their time at Google and other places.

And they started this project called B29. That was named after the building they were in.

CRAIG BOX: I was going to ask, it wasn't named after the war plane?

CHIP CHILDERS: [CHUCKLES] The story goes-- I mean, you'd have to ask Derek, but every time he's told the story, it's been about the building. So they built this platform as a service. It was kind of not directly tied to a lot of the strategy of VMware at its core. Now we have to step back and we have to start talking about corporate merger acquisition and spin out activities.

So EMC owns most of VMware at this time, EMC decides, along with VMware, decide they're going to take some of their assets and people and some of VMware's assets and people, and they're going to go create Pivotal Software, so Pivotal Software. Now they get some investment from GE, and Pivotal sets up a strategy where they're looking at selling data services, things that kind of revolve around Greenplum, what became Apache GemFire, and some of their partnerships with Hortonworks around the Hadoop space.

The second pillar of that leg was the application developer space. So that was the Cloud Foundry platform. That was the spring framework and a bunch of the kind of relevant projects. And the third was Pivotal Labs that was all about agile development, transforming businesses for digital transformation, that sort of thing.

Fast forward. Fast forward. Cloud Foundry starts to get a bunch of participation from IBM, SAP, Hewlett Packard, some startups wrapped around it. And there was a push to get Pivotal to donate the project, kind of like I described with Citrix in CloudStack, but to donate the project into some sort of neutral place that would allow for there to be more open governance that would ensure that as companies built their products around this thing that they'd be able to have sustainability.

Now we've seen this pattern happen a bunch of other times in a bunch of other examples. But that basically is what played out, and that's what created the need to create the Cloud Foundry Foundation.

CRAIG BOX: Most people who use Cloud Foundry commercially will have purchased it from Pivotal. And there was a distinction between Pivotal Cloud Foundry and the Cloud Foundry Project. But there weren't a lot of other vendors operating it at the time or making it available.

CHIP CHILDERS: Yeah, absolutely.

CRAIG BOX: Why do you think Pivotal would do this?

CHIP CHILDERS: So you're actually incorrect about the most people part. Most of the case studies, certainly, Pivotal has been very public about. And their clients were very public about their use of Pivotal Cloud Foundry. But if you look at IBM, they have hundreds of thousands of customers actually using it. So revenue versus volume.

CRAIG BOX: So they just had a better marketing department?

CHIP CHILDERS: Pivotal was very focused on the Cloud Foundry brand, and they did strong association of Pivotal and the brand. IBM at the time wasn't calling it Cloud Foundry. When they launched, it was called IBM Bluemix. SAP similarly, it was the SAP HANA Cloud Platform. And so, yeah, there's sort of a brand association that rightfully was still attached to Pivotal because they donated it.

So I think your question was, why did Pivotal agree? Well, I think it's the same reason any company eventually agrees to move some software that's open source into a vendor neutral environment. It has to do with the goal of building a bigger ecosystem that you're going to be able to participate in as well.

Understanding that you get engineering help. You get marketing help. You get all kinds of different healthy from your competitors if you move that open source code into a place that is set up to enable that type of collaboration. You can go fight it out in the market, but in a number of things, you're collaborating together.

ADAM GLICK: Why the decision to form a new foundation versus putting the project into one of the existing open source foundations?

CHIP CHILDERS: Well, I wasn't there, so I can't answer that. However I can maybe help with some misperceptions there. So first, I'm employed by the Linux Foundation. And so the way the CFF came to be was it was following a pattern that the Linux Foundation had created. So the ASF is about being a charity. And there's lots of other examples. There's also Eclipse. There's Python Software Fund. I mean, there's tons of different foundations. And they all have different spins on what their role is, how they think about open source as a collective act.

And what the Linux Foundation is set up to do is to support not just the open source software development activity, but to support the ecosystem around it. And so that's by event management. That's by doing training and professional certification. That's by doing trademark management. There's a bunch of services that a reasonably sized open source project would benefit from having.

And so that's what the Linux Foundation is designed to do. And so it has a number of different what are called collaborative projects that are underneath it. The CFF is one of them. The Open Container Initiative is another. CNCF, the home of Kubernetes, that's another one. And there's many more. There's LF Edge, LF AI, LF Networking.

And we just actually continue to kind of find new ways to form collectives of companies around one or more key projects. Some of them are larger. Some of them are midsize. Some of them are smaller. But each one of them is a combination of open source software development, community support, and ecosystem support around that development.

CRAIG BOX: You mentioned there the Cloud Native Computing Foundation. It was formed in June of 2015, which is five or six months after the Cloud Foundry Foundation launched. You were there at the time. Did you see the team who were launching the CNCF reach out to you and look for-- how you'd operated, whether it made sense to do that? Was one a model for the other?

CHIP CHILDERS: I think they were both modeled fairly independently. Craig spent--

CRAIG BOX: Craig McLuckie, not me.

CHIP CHILDERS: Yeah, Craig McLuckie. He spent quite a lot of time back then contemplating-- he and Joe-- how Google at the time could see the CNCF happen. The other important event that occurred in between the founding of the CFF and then CNCF was the Open Container Initiative. That was really important because Docker was a massive player commercially. And so everybody was thinking about Docker as a single-vendor owner of a bunch of open source that a whole new wave of innovation was being based on.

So when the OCI was created to take some of the Docker code base and put that into a vendor neutral place, starting with the spec and the runC library, that was kind of the beginning of Docker loosening up, starting to find the right balance for how that was maintained. And then when CNCF was created, that was kind of Kubernetes now being drawn from Google, now being put out into the same type of environment.

And it just really accelerated from there. So it was kind of like a one-two-three hit, and then things started to accelerate.

ADAM GLICK: Does the Linux Foundation specify any particular set of governance or rules as you form a foundation underneath them? Or is that left up to the individual foundation to choose what's best for them in terms of governance and support?

CHIP CHILDERS: Let's say there's some rough outline rules. And there's a few things that are very important. The first is that there needs to be a clear distinction between the business governance of the entity that's going to fund all of those ecosystem activities and the technical governance of the projects themselves. So the open source software development part of the community needs to have a separate governance from the funders of event management and all of those other activities.

So as long as those things are separate, and as long as the open source development activity is done in a very transparent way, there is a lot of flexibility that's in place. There does need to be good IP, Intellectual Property cleanliness. So there's some rules about that. But there's lots of different models that can be followed. It could be developer certificate of origin. It could be CLA based. Lots of different license options are available.

So the LF is designed to have a lot of flexibility in what it's going to support so that each ecosystem is able to create an environment that works best for them. And for example, just you can compare and contrast. The Academy Software Foundation, that is the Academy of Motion Picture Arts and a bunch of software that they built together, which that's another LF collaborative project. And their needs are very different from, let's say, the CNCF. And they could have very different models, and it's designed to be able to support them.

CRAIG BOX: This foundation takes the work that's contributed by members who write Cloud Foundry. You mentioned obviously a number of things the foundation does in terms of event strategy and to the governance things and so on. So I understand the role of an executive director or a CEO in this environment. What does a CTO do?

CHIP CHILDERS: So have you heard about this concept of herding cats?

CRAIG BOX: Conceptually.

[LAUGHTER]

CHIP CHILDERS: Yeah. It's funny. The CTO, first of all, generally has no meaning whatsoever in the industry. Because you could be talking about a CTO that just could be a high-level sales engineer, spends a lot of time with big clients. You could have a CTO who is the visionary, kind of pointing in the direction that we're all headed. You can have CTOs that are in fact VPs of engineering at a startup. So there's a lot of variation in that particular title.

CRAIG BOX: It's really just people wanting something better on their business card.

CHIP CHILDERS: Yeah, absolutely.

ADAM GLICK: My personal favorite is the CTO that doesn't exist where you have an office of the CTO, but no CTO that any of them report to.

CHIP CHILDERS: Yeah, yeah. So the interesting thing about the role of someone with big technical background that has nobody who works for them that actually writes the code is that it's really all about helping to show the participants where there are opportunities for collaboration that they may not be able to see themselves. Because if you think about any either individual team or company, sometimes it can be very hard to take the blinders off from what your goals are, what your commercial outcomes are, and step back and realize, for example, that your competitor has the exact same need.

And so one of the most important things that I spent time on was trying to create these moments of opportunity for collaboration, which would then build into an area of development for the project. Then we kind of split that time with also being responsible for running around the globe talking about the work of the community and trying to contextualize it for analysts and press and kind of share the work.

CRAIG BOX: You mentioned Sam Ramji before, who was our guest on episode 98. He was the founding CEO of the Cloud Foundry Foundation.

CHIP CHILDERS: Yeah.

CRAIG BOX: When he moved on to a cloud company of no particular importance. then Abby Kearns became the new executive director. She's moved on recently, and you've stepped into that role. You've moved from the CTO to the CEO role. Do you still wear both hats?

CHIP CHILDERS: I do. I do. At this point, the community's needs are such that it makes sense for the executive director to kind of do both of these things.

CRAIG BOX: So what responsibilities have you added as part of this change?

CHIP CHILDERS: Well, all the business side aspects, right? Things like making a decision as to whether or not we're going to move an event virtual or working with new members, working with our board of directors to think about what are the steps that we need to take in the broader ecosystem that are going to result in the best commercial outcomes for the group? What are the things that we can do to better collaborate with the CNCF, with the Continuous Delivery Foundation? So really a number of things that have to do with the running of the organization itself got bolted on to the mechanics of the community operating.

ADAM GLICK: What did you learn about running an open source foundation from your experience working with the Apache Software Foundation?

CHIP CHILDERS: They're very different. The ASF was a learning experience that was predominantly revolving around what makes a healthy project and a healthy community. That's really what the ASF is focused on. As you go through the incubation process, because projects enter the ASF through the incubator. They're what are called podlings. They are then taught through some combination of reading documentation, being mentored, and a little bit of osmosis, I think.

They're kind of taught what it means to be a project to the ASF. The community learns how to operate as a healthy community of individuals. So there was a great background in how to operate in an open community, some of the pros and cons of the different ways you can approach things. And so I've been able to bring that forward. It's been a very good kind of guide. It's not the same exact model that we employ within the projects, but it sort of represents a good place to turn to look if you're trying to figure out how the behaviors of the group are playing out within one of the CFF projects.

ADAM GLICK: Recently the Cloud Foundry Foundation announced that they were building a version of Cloud Foundry that would run on top of Kubernetes, re-platform there. That was kind of a surprising announcement, and I'd love to know more about how that decision was made.

CHIP CHILDERS: What's interesting is that it shouldn't have been surprising. We've been working on this for actually multiple years now. Let's just go through a little but of history quickly, technologically. When Cloud Foundry was initially developed, then it was kind of rewritten when Pivotal took it from VMware and they open sourced it. It was already including containers. So this is before Docker existed. It was dealing with all of those Linux kernel features that we now call containers.

And that was necessary because that's how you create a multi-tenant environment where you have apps from different developers running on the same host without using virtualization to do that. And so just using that as an example, the CF code base has been in this continual process of evolution. Since its inception, the community has had to build things because they don't exist somewhere else. And they've made the choice to build just what is needed, not a general-purpose solution, because our focus is on the developer experience, enabling developers to have a really good platform experience.

And at the time, that involved going all the way down the stack to mucking with virtual infrastructure as a service APIs. And all of that is in service of a developer experience. So over the last five years, we've been, when possible, adopting open source code from other communities that are targeting a more general-purpose solution that fits into the architecture. So outside of Docker, we were fast to adopt runC from the Open Container Initiative. We were very quick to adopt containerd. We were very quick to adopt a bunch of other components that exist in other open source communities.

However, those moves to make those steps, those moves to adopt the other projects were made thoughtfully largely because there was such a big install base. So I'll give you an example. There's a large telecom company who runs 100% of their billing on top of apps running on Cloud Foundry. Most banks run enormous amounts of their customer engagement software on top of Cloud Foundry. And so there's just a lot of commerce that occurs on it. It's also in very secure environments.

So our community has to be super thoughtful about when they make a major change to the architecture. So one of the criticisms has been, why didn't you adopt Kubernetes earlier? And I would say, well, because Kubernetes was not ready to be adopted at the time. It just factually wasn't. It did not have the features we needed.

When it reached the point that it was time to do that, IBM was the first to step up to say, we're going to start testing this out and prove it. And so they did. They demonstrated that it would work. Then our community began a process of continually testing and evolving what that initial spike looked like. At the same time, they had to keep moving, because customer demand and user demand was still there. So that purpose-built layer-- terms like Diego and Garden exists there. That purpose-built layer had to continue to evolve.

So fast forward. Here we are today. We're in a position where we have the whole community right now very focused on making this a complete transition. We've done a similar transition like this in the past. We're going to do it in a way that brings the whole ecosystem along for the ride. All the distributions will have time to make the shift. All of the capabilities of the current production-grade architecture are going to be proven out in a Kube-based architecture.

And our community is spending an awful lot of time-- and it's frankly the same community-- working within the context of Kubernetes, working in the context of Istio. Istio is the other project that we're very deeply integrating into the CF architecture. So there's a lot of work that goes into taking the CF use cases, the CF scale requirements and the CF security requirements for multi-tenancy, and working with these components that get brought into the architecture, working with those communities to make sure that we have what we need.

ADAM GLICK: So to reference our earlier conversation, basically it got boring enough to build on.

CHIP CHILDERS: Yeah, absolutely. I mean, it didn't get boring. Kubernetes is actually still very exciting, right? But--

ADAM GLICK: No, I absolutely think that. But in the discussion, you were talking about building a foundation and a strong enough foundation to build on and that being the boring stuff.

CHIP CHILDERS: That's absolutely right. I would say Kubernetes matured to the point that it provided the capabilities that were necessary. And in fact, when the Cloud Foundry community started really pushing on this hard late in 2018 and throughout 2019, it was clear that the Windows platform, the Windows-based version of Kubernetes was lagging significantly. And we're really happy to see that that is starting to catch up with the Linux-based Kubernetes distros.

Because that's a large percentage-- Windows-based hosts are a large percentage of the environments in the large enterprise. We tend to think about Linux only for a lot of these projects, but Windows still is a material need in a large number of end users.

CRAIG BOX: Is that true for current Cloud Foundry users?

CHIP CHILDERS: That is.

CRAIG BOX: You mentioned before writing specific tools and then looking to see when the general tools mature enough. There is an opportunity cost here. So you can take the thing that you've built that solves your exact problem and then pull it out, and then basically you've taken your round peg out and left a round hole, which you now have to squish this square thing in. Was there resistance to this, especially from the people who wrote the original round peg?

CHIP CHILDERS: In some ways, there's always some resistance. But our community is remarkably good at understanding this notion that every line of code that a company or a project maintains is a liability. We tend to think of lines of code as being assets, but an asset like owning a house. You have to spend money to maintain it. And a better way to look at a house is to look at it as both an asset and a liability.

So let's apply that to code for a second. When you think about code, code has to serve a functional purpose, but you also have to do care and feeding. Because if you don't touch it, it's going to experience bit rot, and there's nothing you can do about that. This is just simply entropy, and it's going to enter the system. Underlying libraries are going to change. Interfaces are going to change. You're going to have to patch stuff.

So if you come from the approach that the core to what you're creating is the user experience or the core to what you're creating is an operator experience, then how you provide that experience architecturally, what exact lines of code created by whom, they start to matter a lot less. And so our community is very good at thinking about the question of architectural evolution using that as the frame.

ADAM GLICK: What has been the user reaction to this change to building on Kubernetes?

CHIP CHILDERS: User reaction's great. So it opens up a few possibilities for us. So first of all, if you look at the Cloud Foundry user base, Kubernetes plus Cloud Foundry has always been the way that it's been used. And it's been a challenge, because while there have been some approaches to just package CF up and put it on top of Kubernetes, from a user standpoint, you don't really care so much how these things are stacked. What you care about is being able to access the Kubernetes APIs in order to push software.

So a common use case is bespoke software, the custom software that your teams are writing, go into the Cloud Foundry platform. And ISV software, other open source packages, things are delivered to you as containers, container images, get pushed into the Kube-based platform. That's a super common pattern that we see in a lot of organizations.

So for a while, they're having to kind of run them side by side and then dealing with kind of communication networking back and forth. And so if you talk to a big company that uses both, they love the idea of taking that developer experience, moving it on top of the same infrastructure that their other stuff gets put into, and making it less complicated operationally. So that's one view.

The second view is as we do that, we're able to create a smaller form factor of the Cloud Foundry experience, and we're able to get that into more environments. CF's always been built for kind of the large enterprise or service provider use case. Default releases, highly available, highly redundant. Lots of EMs have to be spun up. A Kube-based form factor, container-based form factor, it lets us get that great developer experience to maybe a small development team that just has a small Kube cluster that they want to use it with.

So it's going to be really interesting to see how this changes the adoption patterns from predominately large companies, or you have to go to as a service provider.

CRAIG BOX: There are two different open source projects that address the Cloud Foundry and Kubernetes integration. There's KubeCF, as I understand it, that uses the BOSH deployment tooling that existing in Cloud Foundry today. And then there's cf-for-k8s, which uses Kubernetes and feels like it's a bit more experimental. Do you see these as stepping stones to a journey where Cloud Foundry is just an application that gets deployed and you no longer care for BOSH? You no longer need to have that infrastructure creation tooling in Cloud Foundry itself?

CHIP CHILDERS: Yeah. KubeCF doesn't use BOSH itself. What it does is you can think of it more like a bridge. We didn't talk about BOSH. bosh is kind of based on Borg. If you go back to that DataStax episode with Sam, I think he mentioned this back in that episode for you. So it's a virtual machine infrastructure, provisioning, and released management tool chain. So it thinks in terms of VMs.

The way that most of the Cloud Foundry projects have been releasing their software is via what's called a BOSH release. It's a YAML manifest because it's not cloud native if it's not YAML, right? So you have this YAML manifest that describes what you're releasing, and then you're able to use BOSH to deploy that to virtual machines.

So what KubeCF is is it's the concept that was initially created by the team that's at SUSE, that offers Cloud Foundry for SUSE. They said, well, we want to commercialize by taking those bits, and we want to move that into a container and then have a Helm chart and some helper scripts and deploy that into Kubernetes clusters. So as an upstream project, KubeCF is like a bridge from the architecture that is released as a virtual machine-centric architecture over to a Kubernetes-centric architecture.

cf-for-k8s is taking a different spin. And we'll get to how these two relate to each other in a minute. cf-for-k8s is an overall effort to look at each component of the CF architecture individually and reimagine how it would work in a Kubernetes-based architecture. So it's less about a lift and shift in order to solve a problem today, and it's more about creating the architecture of tomorrow.

Now the nice thing is they're both converging. because the KubeCF project, as the components of the rest of CF, they rethink themselves, it's taking those changes, and it's going to no longer rely on the BOSH release version. So you can imagine eventually these things are going to converge. And what we're kind of left with is some opinions about, do you use Helm charts for deployment, or do you use something else?

But that's going to end up being an implementation detail. There are two efforts. They're highly collaborative. They just solve a slightly different problem. One is get the whole CF experience moved over immediately. The other is, we're going to kind of baby step to the full CF experience by re-implementing a lot of the components.

CRAIG BOX: One of the things that the foundation does is control who's allowed to use the trademark Cloud Foundry. Are we now leading to a point where anyone using that trademark, anyone with a product branded this way, will be running Kubernetes by default, by requirement?

CHIP CHILDERS: That's hard to say because that's predicting the future and generally highly dangerous.

CRAIG BOX: But a fun game for the weekend.

CHIP CHILDERS: It's a fun game for the weekend. Well, if I were to be a gambler, I would gamble and say that, yeah, probably. In the next several years, there'll probably be a strong expectation. Although I will caution, we've done architectural changes like this that have been dramatic. And in some of these massive deployments, it takes a lot of work for them to change the big multi-tenant environments that are out there.

We are not going to strand large users of the software. That's a commitment that our community has made to itself. So making it a requirement is the moment where you recognize that nobody is stranded. Everybody's been able to transition.

CRAIG BOX: Is there a multi-year deprecation period on versions of Cloud Foundry?

CHIP CHILDERS: Generally. So we try to keep the pace up. The certified versions of the platform, the requirements change each year. So we do an annual bump on those requirements. This year, we are allowing Kubernetes to be the underlying container orchestration layer as an option. You could also use the existing Diego layer as an option.

We don't care whether it's packaged to run on Kubernetes or not. But the part of the architecture where CF talks to a container layer, it could be either/or. I don't know whether 2021 will represent the time where you have to be using Kube. Maybe it's 2022. But again, we're not going to strand part of the ecosystem of either users or vendors or customers of the vendors. We believe in bringing everybody along this journey.

ADAM GLICK: Once this migration is done, what comes next for the Cloud Foundry Foundation?

CHIP CHILDERS: All kinds of exciting work. Anytime you get a wave of innovation occurring around the next level of abstraction, there's a lot of opportunity to learn from the broad ecosystem of open source efforts that are out there. The Cloud Foundry quintessential developer experience is to push code into the platform. And it works remarkably well.

One of the areas that's already being worked on but I think is a good example of the type of work that's going to continue is figuring out how new capabilities from these now general purpose tools as opposed to bespoke tools, these general purpose components of our architecture can be exposed to a developer most effectively.

So let's talk about Istio as the example there. You don't necessarily want to give the full power of Istio to the typical enterprise developer, frankly the typical developer. Now, it might be fun for them to dig into it, but also that's a big cognitive load that you have to put on someone who's really-- they should be focused on business problems, right? So what does the developer experience to do things like weighted routing? What does the developer experience to do more advance release engineering rollout patterns?

So there are ways to make advanced capabilities more consumable just for your own sanity as a developer. Or if you're looking at it as an organization who wants to maintain development velocity, it's basically getting the stuff that shouldn't matter to your developers out of the way. Make it easy for them to do very powerful, very complex things. So that's where our community spirit really lies. It's where a lot of the innovative ideas that are being explored, that's where they're happening.

The underlying architecture change, super important. They're going to unlock new possibilities. But at the same time, it's kind of the stuff that's hidden, right? We want to get to giving more value to those developers.

CRAIG BOX: Well, we're excited to see how these two communities come together. And with that, it just remains to say thank you very much for joining us today.

CHIP CHILDERS: It was great to be here.

CRAIG BOX: You can find chip on Twitter @ChipChilders, and you can find Cloud Foundry at cloudfoundry.org.

[MUSIC PLAYING]

ADAM GLICK: Thanks for listening. If you haven't subscribed yet, please do so in your favorite podcast app. As always, if you've enjoyed the show, please help us spread the word and tell a friend. If you have any feedback for us, you can find us on Twitter @KubernetesPod, or reach us by email at kubernetespodcast.google.com.

CRAIG BOX: You can also check out our website at kubernetespodcast.com, where you will find transcripts and show notes. Until next week, take care.

ADAM GLICK: Catch you next week.

[MUSIC PLAYING]