Did you know that the Kubernetes community is not just about distributed systems, it’s also about distributed decision making?

Sarah Novotny is one of the most inspiring leaders in the open source world. She leads the Open Source Strategy group for Google Cloud Platform (GCP). Prior to that she was technology evangelist and community manager at NGINX. I have been following her career for a long time and got an opportunity to meet and interview her at KubeCon. We discussed a wide range of topics around her work at Google and Kubernetes. Here is an edited version of that interview.

Swapnil Bhartiya: Can you talk a bit about the group that you lead at GCP?

Sarah Novotny: The group is working to ensure that open source projects which are strategically important to Google and users on GCP are healthy, sustainable, stable, open, and continue to be able to grow and be strong projects over time.

What kind of engagement does Google have with these projects, how much of it is at code level?

It really depends on the projects. Some of them are at code level, others are at community and governance levels. My team focuses more on the broad health of the community. We have program managers and technical program managers who are looking at the process, the governance and engagement in the community inside projects. Some of these projects are either led or spawned from Google. There are many other projects which already exist and are important to our open source customers.

Right now we are focusing on seven projects, including gRPC, Istio, Kubernetes, Golang, Node.js, Apache Beam, Tensorflow. We are working with the engineers involved with these projects. These engineers can be from Google or from partner companies trying to help grow happy, healthy ecosystems. Sometimes these projects are part of a foundation. In any case, it’s all about bringing forward the open source culture and making sure that it has great strength.

The way we do it is by establishing a culture that is influenced through servant leadership and grows leadership through influence.  – Sarah Novotny

Why does Google open source its technologies? They have all the engineers, they have all the money. They don’t need external help.

Google chooses to open source the project when we want to change the way the industry is having a conversation. It is much harder to change the conversation from a single perspective. Moments ago, you and I were 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.

Kubernetes, for example, began as a partnership between a number of companies – Red Hat, IBM, Google, CoreOS. We all sat down and started working on a way to change the conversation of a portable workload unit for the cloud. Instead of talking about virtual machines or jar files, let’s use containers as the portable workload unit.

Google had already done that internally. Google was using containers as the method of delivery and portable workload units inside for years. But that doesn’t change the industry. Google alone can’t change the industry by simply saying “this is the best way to do it so everyone should do it, too”. There was a need for a broad coalition — a great group of people pulled together to build a project that brought in a lot more influences and perspectives from customers, from other companies, which made this change in the industry, made this change in the way we talk about cloud workload units.

Very true, but I wonder how you then maintain the balance between the business needs and the needs of the community. When you open source a project, you also give up the control, the influence and the direction of the project. Now, the larger community, which you are part of makes decisions about it.

You’ve actually touched on my last two years, the way we do this, the way we try to make sure that these are happy and healthy projects. The way we do it is by establishing a culture that is influenced through servant leadership and grows leadership through influence.

We’ve established core values in our community that include things like chopping wood, carrying water. We make sure that we are not coming to this project as a company who needs a feature. Instead, we are coming as individual developers, contributors, program managers, community leaders who are helping build a better project that meets more needs, it gains ubiquity. That ubiquity is what changes the conversation.

The way Google helped build 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. It was about meeting the end user’s needs of a hybrid cloud. It was about applications and workloads that work on GCP, AWS, Azure, on premises and so on. It was about building a broad partnership across the industry.

Does Open Source also help in creating standards? You don’t need to go to ISO. Open Source creates standards that are supported by the ecosystem. Look at Linux.

Yes, it’s a lot like, or possibly better, than the standards bodies of the nineties. Instead of defining standards and specifications early on, we now instead build open source projects that evolve and find these standards and 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.

If open source kind of creates standards, why was there a need for Kubernetes Conformance?

Conformance is slightly different. There’s a certified conformance and this is actually how we are able to measure, manage and prevent drift of what it means to be “Kubernetes.” Kubernetes as a project needs to allow a broad ecosystem to build around it. That is the only way this makes any sense. Any open source needs to have this broad ecosystem, but this broader ecosystem is built with vendors and interested parties. These are businesses; they need ways to make monetize from it. Open source is wonderful and it’s a huge cultural change in the way software is developed, but we are still companies building products and services.

Our Steering Committee and Architecture Community are working on making Kubernetes core itself smaller while making the Kubernetes ecosystem bigger.

Very true, open source is a software development model, not a business model. That said, different vendors implementing their own versions of the same open source project may lead to interoperability issues or even vendor lock-in.

We do need to make space for the ecosystem to grow. There are a couple of ways we can do that. One is making sure that when we say Kubernetes we mean the same thing. When you run Ubuntu Kubernetes, Heptio Kubernetes, Red Hat OpenShift or run it on GKE, Azure or AWS, you should have the same expectations. You can interact with Kubernetes in the same way.

That’s what our certified Kubernetes conformance is. We have a set of conformance tests and if you meet those tests, you can use the Kubernetes brand. That’s one way to grow a healthy ecosystem. Another way the ecosystem grows is through all the tooling around Kubernetes – APIs and extensibilities.

Our Steering Committee and Architecture Community are working on making Kubernetes core itself smaller while making the Kubernetes ecosystem bigger.

You have made it easier for me to transition to my next question. While Kubernetes is getting wider adoption it also risks losing its focus, we have seen that earlier with open source projects. So how do you ensure you won’t make the same mistakes that others did while Kubernetes continues to remain a very focused project, you also enable the ecosystem around it to continue to grow?

We’re hoping that we always make new mistakes because that is one of the core values. Our culture is learning from what we’ve done, what others have done.

We are working as a community to define, a shrinking Kubernetes core. We are trying to move more pieces of the code base out of Kubernetes and potentially into their own projects, into their own repositories within the Kubernetes organization to keep Kubernetes really crisp and moving at a pace.

But that’s Kubernetes core, not Kubernetes the ecosystem. The ecosystem continues to grow and evolve. A smaller Kubernetes core means that we have more innovation, more engagement and more opportunity for businesses and for communities to grow around Kubernetes. That work is happening in the Special Interest Group (SIG) architecture, a lot of conversations around culture, community and leadership are happening in the steering committee.

Kubernetes as a project has grown massively in the last two years. We just got a governing body that’s working to distribute all of the decision making. We want to make it more clear and codify it better. We also want to be able to empower all these different groups to do all the amazing things they want to do around the core of Kubernetes.

Distributed decision making! I have heard that before. Can you elaborate a bit on it? What does it mean?

We try to push the decisions closer to the people that are working on the code. A distributed decision-making system would be make sure that decisions about APIs – even though they are cutting across the whole project- are made within the SIG API machinery group. The Helm group makes their own decisions, without needing to the steering committee. 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.

But as these groups work, if I may use the pun, within their own containerized group won’t that create some kind of integration problem?

Maybe, but that is part of how the steering committee is trying to improve the system.

Let’s change the topic. Kubernetes is being used in so many different and new use cases. With huge adoption comes huge challenges, what are the big challenges that you see?

Making sure that we have a way for interested, excited people to interact with the project. Our biggest challenge right now is making sure that we have a clean definition of what is Kubernetes and then making sure that the edges are really easy to engage. We want to make sure that Kubernetes is a project where people can innovate easily on top of it.

We all know that orchestration is becoming a commodity, which also means it’s going to become boring. So, do you keep the technology boring the discussions around it interesting?

I think that’s actually the right way for it to move. Dan Kohn, the executive director of CNCF quoted Tim Hockin and said: ‘It’s an exciting time for boring infrastructure’. The more we can make this good infrastructure solid, boring and commoditized, the better that will be for the project allowing the ecosystem to flourish.

How is Google making discussions around Kubernetes interesting in some unorthodox manner?

Google has put out a comic about Kubernetes created by famed Scott McCloud. It’s called ‘Smooth Sailing With Kubernetes’. Google is actually taking a look at how to use visual displays of information in order to teach and to share. 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 adventure with Kubernetes.