 Hello, welcome to TFIR where we talk about open source technologies that are powering the ongoing fourth industrial revolution. I'm your host, Swapin Bhartya and today's guest is Sara Nawatni of Google's open source strategy group. Sara is one of my favorite leaders in the open source world and today we are going to talk about a lot of different topics. We are going to discuss a wide range of topics including the role of her group and if you look at Google, I mean it's a huge company, they can afford to hire whoever they want. They don't need contributions from their competitors so why do they open source their project? What does Google gain by giving away their technologies like Kubernetes? And if you look at Kubernetes itself, it has become one of the most successful and widely adopted projects. What is the secret sauce? While I was discussing with Sara, one more point that caught my attention was that community is as much about distributed system as it's about distributed decision-making. What is distributed decision-making? That's exactly what we are going to discuss today. So let's get started with this interview. Hello Sara, before we deep dive into this interview, can you tell us a bit about the group that you're heading there? I'd be happy to. So I lead the open source strategy group for Google Cloud Platform and that group is working to make sure that open source projects which are strategically important to Google and Google users on Google Cloud Platform are healthy, sustainable, stable, open and continue to be able to grow and be strong projects over time. Excellent but Google does a lot of open source. When we look at your group, what kind of engagement is there with these open source projects? How much of it is at the code level itself? So it depends on the project and some of them are at code level, some of them are at community and governance levels. My team focuses more on the broad health of the community. So my team is program managers and technical program managers who are going and looking at the process and the governance and the engagement in the community inside projects and they are projects that may be led or spawned from Google and they are projects which are exist and are important to our open source customers. So our eight projects right now that we're focusing on are GRPC and Istio, Kubernetes, Golang, Node.js, Apache Beam, I'm sure I'm forgetting when I said eight and then I'm not going to get the whole list right but we are looking at those those communities and those projects and working with the engineers that are working on them both inside Google and from other partner companies and trying to help them grow a happy healthy ecosystem. Sometimes that's in a foundation, sometimes that's outside a foundation but in any case it's bringing forward the open source culture and making sure that that has great strength. I mean as I said earlier Google is a big company they can hire anyone they want so why do companies the size of Google or Microsoft or Facebook the open source what do you get by giving away your technologies to the community? Why? Why would we do this? So frequently Google chooses to open source a project when we want to change the way the industry is having a conversation because there it is much harder to change a conversation from a single perspective. A few moments ago we're talking about broader culture and how having more perspectives makes for a more empathetic and more engaged group. It also makes for a more whole perspective of an end user experience. So Kubernetes as an example since we're at KubeCon we might as well talk about that. So Kubernetes as an example began as a partnership of a number of companies and those number those companies Red Hat, IBM, Google, CoreOS all sat down and started working on a way to change the conversation of a portable workload unit for the cloud. So let's stop talking about VMs as the way we talk about a portable workload unit or a jar file. Let's use containers as the portable workload unit. But in order to make that change Google already did it internally. Google has already used containers as the method of delivery and portable workload unit inside for years but that doesn't change the industry. And Google alone is not able to say this is the best way to do it and then have everyone change. So there is a need for a broad coalition of great group of people pulled together to build a project that brought in lots more influences and perspectives from customers from other companies and then made this change in the industry made this change in the way we talk about cloud workload units. One point is that when you do donate or give away your technologies, you kind of lose control over it. Now a wider community is making those decisions and not you. But you're still a consumer of those technologies as you have customers who are consuming it. I mean, that's the reason that you developed it in the first place. So how do you really maintain that balance between what you need as a provider versus what the wider community needs? So and one more thing, do you stay upstream means in terms of the Kubernetes usage within Google? So GKE is a fully upstream version of Kubernetes. So we run Kubernetes as it comes off of our releases. And the way you've actually touched on my last two years, the way we do this, the way we try to make sure that these are good projects and happy projects is to establish a culture that is influenced through leadership and leadership through influence. We've established core values in our community that include things like chopping wood, carrying water. Like you've heard this probably a couple of times this week, making sure that we are not coming to this project as a company who needs a feature, but we are coming as individual developers, contributors, program managers, community leaders who are helping build a better project. And that better project meets more needs. And that better project gains ubiquity. And that ubiquity is what changes the conversation. So our our goal and the way Google handled this in moving Kubernetes to a foundation and in fact building a foundation around Kubernetes was to make sure that the conversation was very broad. It was about customer needs. It was about container and cloud workloads, not how to best run containers on Google Cloud Platform. We wanted this to meet the end user needs of a hybrid cloud. How can we have applications and workloads that work on on premises on Amazon, on Azure? And we have this broad, broad partnership across the industry. It's a lot like the like only better than the standards bodies of the 90s. Instead of defining standards and specifications early on, we now instead build open source projects that evolve and define these standards and these specifications as we build them with code. So it's not spec first. In most cases, it's code first. And then we find and coalesce around a standard. And that happens in a way that changes the industry. And that was going to be my next question. If open source kind of builds or creates standards at the code level. Why was there a need for CNCF to come out with the Kubernetes certification program? And I understand there was a risk of, you know, different vendors doing their own implementation of Kubernetes that might have created some fragmentation. So can you talk about that a bit? Conformant Kubernetes, slightly different. So there's a certified conformance. And this is actually how we are able to measure and manage and prevent sprawl because Kubernetes as a project needs to allow a broad ecosystem to build around it. Like that is the only way this makes any sense. Any open source project exactly needs to have this broad ecosystem. But this broad ecosystem is built with with vendors and interested parties, and they all have mortgages to pay, you know, rent to pay, they have kids to put through college. So they need ways to make money out of this. So open source is wonderful. And it's a huge cultural change in the way software is developed. But we are still all actually companies building things. But business still needs to exist in it. Right, who is consuming it, who is building it, it doesn't exist. So we need to need it to make space for that ecosystem. And there are a couple of ways we can do that. One is making sure that when we say Kubernetes, we mean the same thing. So making sure that when you run an Ubuntu Kubernetes or a Heptio Kubernetes or OpenShift or run on GKE or in Azure or in Amazon, you have the same expectations. And you have the same, your expectations are met, you can interact with Kubernetes in the same way. And so that's what our certified Kubernetes conformance is. It's not, it's something where we have a set of tests, set of conformance tests. And if you read those tests, you can use the Kubernetes brand. Now, that also gives, that's one way the ecosystem grows. Another way the ecosystem grows is all the tooling around Kubernetes. And we have a huge ecosystem in that space. And that is built through strong, strong contracts, strong APIs, and lots of edges of extensibility and a nice tight core. And so that is one of the things that our steering committee and architecture committee are working on right now is how can we make Kubernetes at some level smaller while making the Kubernetes ecosystem bigger? Right. And as the Kubernetes ecosystem becomes bigger and bigger, a lot of new players will come in and they may want to do their own things. We have seen it has happened with other very popular open source projects. They lost their focus as they were overwhelmed by that option. So what are you doing to ensure that you don't make the same mistake? How do you ensure that Kubernetes community doesn't lose its focus? Well, we're hoping that we always make new mistakes. Because that is that is one of the core values in our culture is learning from what we've done and growing and learning from what others have done. So we are working as a community to define, as I said, a shrinking Kubernetes core. So we're trying to move more pieces of the code base out of Kubernetes and potentially into their own projects, potentially into their own repositories within the Kubernetes organization. And making what is Kubernetes a really crisp, slower moving space. Now again, that's Kubernetes core, not Kubernetes, the ecosystem. We want Kubernetes, the ecosystem to continue to grow and evolve and be very, very composable. We've built a distributed compute platform. We want it to be distributed. So if we can make the core smaller, that's great, because that means that we have more innovation and more engagement and more opportunity for businesses and for communities to grow around Kubernetes. So that works happening in the special interest group architecture currently, as well as a lot of the more cultural and community and leadership conversations are happening in the steering committee, which only got seated in October. So we're starting to see some of that work and some of that conversation happen. It's a project, as a project, it's grown massively in the last two years. And so we have a lot of that work that is, we've just gotten a body together that is an explicit governing body, that governing body is supposed to be distributing all of the decision making, it is distributing it. We've already had a distributed decision making system. We want to make it more clear and codify it better. And then we also want to be able to empower all these different groups to be doing all the amazing things they are around the core of Kubernetes. Wait, wait, wait, wait. I do know distributed systems for computers. What is distributed system for decision making? Distributed system of decision making. So we try to push the decision making very much like Diane Marsh's Netflix keynote the other day. We try to push the decisions closer to the people that are working on the code. So a distributed decision making system would be making sure that decisions about APIs, even though they're cutting across the whole the whole of the project, they are being worked and discussed and then ultimately decided in the SIG API machinery group with input from other special interest groups, including the architecture group. The Helm group makes the decisions about Helm. They don't need to go ask the special interest or they don't need to ask the steering committee, can we change the way we're doing something? So we're trying to make sure that those decisions are pushed closer to where the code and the people that are most engaged with those pieces of code and pieces of the project have the most influence. I just wonder that since all of these groups work independent of each other, won't there be integration problem? No, well, there may be. Like I said, we're always looking to make new new mistake. There may be but that is part of how what the steering committee is trying to do right now. Going back to the point of growing the ecosystem, as more new players are entering the ecosystem. What are the new challenges that you see for the new Kubernetes community? Making sure that we have a way for interested people, excited people to interact with it. So this is that strong edge cases, strong integration points, great extension points. So someone we want to make Kubernetes a space where people can innovate easily on top of it. So that is our biggest challenge right now is the making sure that we have a clean definition of what is Kubernetes and then making sure that the edges are really easy to engage with. One last question before we wrap up this interview, unless there is one more last question that may pop up from your answer, we all know orchestration is becoming boring. It's commoditized now, which also means that Kubernetes will also become boring. So how do you plan to keep the conversations around Kubernetes interesting, exciting while the technology itself becomes boring? I think that that's actually the right way for it to move. I think that somebody quoted Tim Hawken the other day is it's an exciting time for boring infrastructure. The more we can make this good infrastructure solid and boring and commoditized, the better that means the project has succeeded. So like the better it is, that was great. I ran out of questions. Do you have any concluding thoughts before we wrap up this interview? I want to say that I want to just touch on one thing, which is Google has put out a comic about Kubernetes just yesterday and I'll have to send you the link so you can put it under my name or you know, in the video, but Yeah, I'm not the cartoonist. No, I wish I was the cartoonist. No, the cartoonist is actually Scott McLeod, who is known for writing the book called Understanding Comics. And Google is actually taking a look at how to use visual displays of information in order to teach and to share. So there's a comic about GKE and sorry a comic about Kubernetes, which which then has a little embedded GKE playground basically at the bottom and there's research happening on the floor the show floor today about this, but I would love to have just the URL in there to say like take a look at this comic because I am such a nerd about Scott McLeod's comics and understanding comics that I'm excited that Google is looking at that visual display and that artistic engagement with how to share information. And it's really fun to have it be part of this part of this adventure with Kubernetes as well. Awesome. Thank you so much Sarah. Hopefully I'll see you again at the next open source conference. Sounds good. I will be around, I'm sure. And back to our audiences. Thanks for sticking around. Please don't forget to subscribe to our channel. Like us and share us with your friends and colleagues. Bye for now. See you next time.