Kelsey Hightower on His Very Personal Kubernetes Journey

The New Stack will shortly launch its latest edition of “The State of the Kubernetes Ecosystem” after the first edition of the ebook was published in 2017. Ahead of its publication, The New Stack was able to speak with Kelsey Hightower, principal developer advocate at Google Cloud, who is likely one of the most recognized voices in the Kubernetes space.

In this edition of The New Stack Makers podcast hosted by Alex Williams, founder and publisher of The New Stack, Hightower spoke about his role in Kubernetes since the beginning, his thoughts on the project’s leadership today and the challenges that lay ahead.

Kelsey Hightower on His Very Personal Kubernetes Journey

During the early days of Kubernetes, there “were no ebooks available” on the subject, Hightower said. The main goal was to help “raise the profile of the people with the job of trying to manage applications.”

“I think the whole point was when I was showing Kubernetes off [as] a contributor [and] building things around the ecosystem, my product work at CoreOS — we were all trying to solve problems that we all had in the past,” Hightower said. “We were trying to uplift the community. We were pretty sure that technology was going to be okay over time.”

More specific to Kubernetes as a platform, the concern was whether the DevOps community could grasp the concept of how distributed systems functioned in order to use them. Many in the community were familiar with configuration management tools Puppet, Chef and Ansible, for example, and “were getting exposure to things like Docker, in terms of packaging their applications and shipping them to servers in a slightly different way,” Hightower said.

“But not a lot of people really understood this whole distributed systems thing. And I think over the last five years, we’ve had so many people — either through the Kubernetes certification or ebooks — where there’s now enough education and an information ecosystem that’s based on experience and analysis, that we’re now getting people to understand what this stuff is all about.”

Hightower’s “jumping into Kubernetes” began when he was working at CoreOS and heard Kubernetes was about to be announced. On the eve of the launch, Hightower began to learn everything he could about the platform “in one night” after accessing the repository for a blog post.

“I remember going through the codebase and there wasn’t really a good review on how to even install it,” Hightower said. “The first thing that I did was put together what some would consider to be one of the very first installation guides… I had maybe about six to seven hours to write something meaningful about Kubernetes.”

After the publication of his blog post, Hightower began to contribute code for the standard core repository and offered his experience in other ways, eventually “building tools on the outside of Kubernetes and contributing to some of the efforts CoreOS was involved in.”

Today, following the explosion in Kubernetes’ popularity, there has been, in parallel, a surge in software purporting to support or work with the ecosystem. For these kinds of products, the time to value is a key metric.

“A lot of times people are building products on top of Kubernetes and they focus too much on Kubernetes. Like, I don’t really care about Kubernetes, just like I don’t care about having a server — I’m more interested in what your product is and what your product can do,” said Hightower.

“I don’t want 10 pages of instructions. The benefit of having Kubernetes is that as a person making a product, your installation guide has the potential to be super, super streamlined, meaning you already know what Kubernetes can do. If I have a valid Kubernetes cluster, you can check for that immediately, and if you find it, you can almost do a zero configuration.”

The learning curve for developers should decrease as the platform continues to mature. For IP address allocation and database access managing, for example, developers should not have to become Kubernetes network experts to do their work as software engineers, he explained.

“There are better tools to handle this kind of dynamic policy stuff better, but the truth is, the maturity of the community at this point is you just got to meet more people where they’re at. It’s always easy to say “hey, just rewrite your thing or use a more modern tool that knows how to do the things the Kubernetes way,” he said. “… as we expand and mature, there’s a lot of opportunity to go and integrate and meet those systems where they are, and still offer the path forward. But it turns out, it’s not a monumental amount of engineering work to make it work — it’s just that it was a lower priority in the beginning.”