Behind designing Kubernetes' APIs | Brian Grant (Google)
"APIs are forever", the keys to evangelizing impactful projects, and being an Uber Tech at Google
As the original architect and API design lead of Kubernetes, Brian joins the show to chat about why "APIs are forever", the keys to evangelizing impactful projects, and being an Uber Tech at Google, and more.
Ronak & Guang’s Picks
#1 “API versioning *conceptually* exists”
While many aspects of software engineering are iterative, Brian makes the point that often you only have one shot to get things right when designing APIs.
“One thing that happens is you have to get stuff right in the beginning, or you can't change it because it's too expensive—that it's not worth it. It's kind of sad because it's like a wart on the side for all history, but the ecosystem of stuff that's been built, and everybody's configurations that are using the current API, is just too large for it to be worth changing.”
For a project as complex as Kubernetes, and as it evolved over the years to support huge clusters and broad use cases, it's no small feat that the architecture and APIs haven't significantly changed since the 1.0 release. And one big reason for this foresight in design comes from the lessons Brian learned building and running Borg and Omega at Google.
#2 The keys to evangelizing a project
Throughout his career, Brian has been consistently good at proposing and evangelizing new projects that have had a significant impact. Here are the keys to making it happen:
The environment matters: Unlike a company culture that's top-down driven, customer-focused, or revenue-driven, having a strong bottom-up engineering culture makes it easier to propose initiatives as an engineer.
Before working on Borg, Brian identified the subproblems, wrote documentation, and started an education program to evangelize moving all the C code at Google from single-threading to multi-threading.
Build trust and start with a prototype: “If you come in from the outside to the company or to the organization and you propose an idea, there's less trust in your judgment, then you have to make a much stronger case.
You have to find business metrics, and it may be very difficult to get concrete data, or you may need to do experiments first to get the data. So, there may be a chicken-and-egg scenario.”
Leading up to the creation of Kubernetes, the unified compute working group was formed at Google, which brought in folks from cloud and Borg to discuss “if one was going to build a cloud product like Borg, something Google could use, what would that look like?” After working on this for a few months, Brian presented the initial API design, and Brendan built a prototype for it that eventually led to the open-source proposal.
Be a good role model: “Everybody saw me writing all these sections of the user guide. I didn't get pushback from anybody asked to write a section—not even a single person. So, if you show people that you think it's important enough that you're going to spend your time on it, that seems to work.”
Segments:
(00:03:01) Internship with Mark Ewing
(00:07:10) “Mark and Brian's Excellent Environment” manual
(00:11:58) Poker on VT100 terminals
(00:14:46) Grad school and research
(00:17:23) The value of studying computer science
(00:21:07) Intuition and learning
(00:24:06) Reflecting on career patterns
(00:26:37) Hypergrowth and learning at Transmeta
(00:28:37) Debugging at the atomic level
(00:34:27) Evangelizing multithreading at Google
(00:39:56) The humble beginnings of Borg and Kubernetes
(00:47:10) The concept of inertia in system design
(00:50:07) The genesis of Kubernetes
(00:53:45) The open-source proposal
(00:57:25) The Unified Compute Working Group
(01:02:16) Designing the Kubernetes API
(01:05:03) AIP.dev and API design conventions
(01:08:02) The vision for a declarative model in Kubernetes
(01:17:25) Kubernetes as a DIY platform
(01:19:07) The evolution of Kubernetes
(01:21:40) The complexity of building a platform
(01:25:11) Style guides?
(01:28:23) Gotchas in Kubernetes workload APIs
(01:32:02) Understanding your thinking style
(01:35:37) Reflections on Kubernetes design choices
(01:44:08) The importance of getting it right the first time
(01:48:13) Designing for flexibility
(01:51:16) Collaboration and leadership
(01:52:21) The role of an Uber tech lead at Google
(01:56:33) “Giving away the Legos”
(02:02:29) Picking the right person to hand off
(02:06:41) Overcoming writer's block
Show Notes:
API Design conventions: https://google.aip.dev/
Brian’s blog: https://medium.com/@bgrant0607
Stay in touch:
👋 Make Ronak’s day by leaving us a review and let us know who we should talk to next! hello@softwaremisadventures.com
Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en