Kelsey Hightower is a towering personality in the Kubernetes world. His official title is staff developer advocate at Google.

A friendly person, who is always ready to help, Hightower is also one of the cochairs of KubeCon, the biggest Kubernetes conference. I sat down with him to talk about the history of Kubernetes, its evolution, and new challenges. We also touched on his personal journey as a developer and the culture of the open source world.

Linux of the Cloud

Kubernetes is touted as the Linux of the cloud. It has gained popularity and adoption in a much shorter time than Linux. One reason behind the Kubernetes' popularity is that, although it's a relatively new project, the ideas behind it are well established.

"These are practices from the large web-scale companies," said Hightower. "I think the reason why you see adoption across the cloud providers is because they understand these ideas. They know that they could probably implement them themselves."

"I think this is why it has such a widespread adoption, because it actually solves real problems that people have."

Rapid Expansion

Within four years of inception, a massive ecosystem of vendors, partners, and providers has grown around Kubernetes. It's backed and used by titans like Red Hat and Microsoft. Even companies that once saw it as a competitor have embraced it, including Docker and Mesosphere. At one point, Kubernetes was known as the "everyone but AWS" club, but even AWS has joined the Cloud Native Computing Foundation (CNCF), Kubernetes' parent organization.

As the adoption of Kubernetes grows, the concerns around it losing focus and getting bloated have begun to rise. It's quite challenging, especially for open source projects, to maintain a balance between what the ever growing community needs versus what should remain the project's core focus.

The Kubernetes community realized these potential problems early on. "We've already identified ourselves as a platform for building platforms," said Hightower. "As a project we know our scope; we have drawn a line."

While the core Kubernetes project has a very tight focus, it supports new use cases and users without touching the core. "Kubernetes empowers you to realize your vision, whether it's building PaaS, Serverless, or self-driving cars. Your vision won't cause friction with the core Kubernetes itself," said Hightower.

Today, a booming ecosystem allows companies to sell services around Kubernetes. That does create another set of problems: interoperability, vendor lock-in, and fragmentation.

To eliminate any possibility of fragmentation and interoperability, CNCF has created the Certified Kubernetes Conformance Program to standardize Kubernetes deployments. In CNCF's own words, it "guarantees interoperability from one Kubernetes installation to the next. It allows them flexibility and vendor independence."

Build vs. Buy

Now you have a large ecosystem of vendors selling services around Kubernetes, but you also have a fully open source project that you can use to build yourself, so the question that pops up is when to build versus when to buy.

Hightower said that it really depends on where you are in your infrastructure journey. A large company like GitHub that's relatively good at infrastructure and has great experience with bare metal already knows how to manage those systems. When they see Kubernetes, they see all the right sets of patterns required to solve their own problems. "In case of companies like GitHub, building made complete sense given their line of business and expertise. They can get more value from building from the open source project," said Hightower.

He pointed to the other side of the spectrum, where companies running grocery stores have back-end systems, have company websites, and may even be using machine learning for inventory, supply, and demand. However, running and managing infrastructure is not their core business and doesn't add value to their business.

"In cases like these, it makes more sense to have a technology partner," said Hightower. You need someone who understands your business, so sometimes you'll pick a vendor based on the vertical that they operate in."

There may be specialized vendors for governments, for airlines, and for financial industries. "I'm going to work with these vendors even though they may leverage technology that's provided by a larger community." Hightower doesn't see the diversity of vendors as fragmentation. "To me, vendors will always be there. I don't think of [this] as fragmentation. I think it is the only way to serve as a global market," added Hightower.

One more aspect of buyer versus builder is to look at who actually helps the community. Hightower sees the importance of both the buyers and the builders. Code itself can't keep any project sustainable; cash is equally important. "Sometimes your best contribution could be buying a product to support these things," said Hightower. If you are buying, you are contributing to the code indirectly. The technology partner you are working with may be contributing to the upstream. "So no matter whether you're contributing directly or indirectly, we're all going to end up benefiting."