Kubernetes Co-Creator Burns Rejects AI Career Pivots, Predicts System's Demise

Ryan Peterman

Engineers should pursue work that genuinely energizes them rather than chasing AI hype or corporate career plans, while remaining ready to discard any software—including Kubernetes—because all code inevitably dies or fades into invisible infrastructure.

AI-assisted summary of Co-Creator of Kubernetes: Is a PhD Worth It & Career Reflections | Brendan Burns — original source. Check the original for full context.

Source published: 2026-10-03

Key ideas

Pursuing a PhD versus entering industry immediately yielded identical corporate engineering levels for Brendan Burns, but academia imparted crucial communication and pedagogical skills essential for launching Kubernetes. (0:00)
Burns cautions engineers against chasing hyped domains like AI without genuine interest, emphasizing that sustaining deep engagement matters far more than rigid career planning. (2:52)
Because all software inevitably faces death, developers must resist falling in love with their code and remain comfortable discarding or rewriting systems entirely. (4:43)
Kubernetes will likely decline either by being replaced with simpler abstractions like natural language interfaces or by becoming invisible infrastructure deep in the stack underneath AI workloads. (4:43)

Detailed notes

## Background Published on YouTube by Ryan Peterman on September 30, 2026, this video features a focused conversation with Kubernetes co-creator and Microsoft Technical Fellow Brendan Burns. According to the description, the discussion covers Burns's experience building Kubernetes at Google, securing internal buy-in, lessons learned along the way, and retrospective advice on education and career growth.

## TL;DR Brendan Burns reflects on the practical trade-offs of earning a PhD, explaining that while it did not grant him an industry level advantage over peers who bypassed academia, it instilled crucial communication, teaching, and debate skills necessary to pitch and popularize Kubernetes. He advises early-career engineers against chasing trend-driven career plans like artificial intelligence, urging them instead to follow whatever subjects genuinely energize them to learn deeply. Finally, Burns elaborates on his belief that software's inevitable fate is obsolescence and death, warning developers never to fall in love with their code as Kubernetes itself gradually transitions toward commoditization, invisible infrastructure, or replacement by simpler natural-language abstractions.

## Atmosphere & style The conversation carries a relaxed, reflective, and pragmatic mentorship vibe, marked by Burns's unpretentious candor and dry, self-effacing humor. Free from corporate jargon or tech evangelism, the dialogue feels like an honest fireside chat where an industry veteran demystifies career ladders, laughs off rigid five-year plans, and comfortably acknowledges the impermanence of his own landmark creations.

## Bulletin - [00:00](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=0s) Pursuing a PhD versus entering industry immediately yielded identical corporate engineering levels for Brendan Burns, but academia imparted crucial communication and pedagogical skills essential for launching Kubernetes. - [02:52](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=172s) Burns cautions engineers against chasing hyped domains like AI without genuine interest, emphasizing that sustaining deep engagement matters far more than rigid career planning. - [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) Because all software inevitably faces death, developers must resist falling in love with their code and remain comfortable discarding or rewriting systems entirely. - [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) Kubernetes will likely decline either by being replaced with simpler abstractions like natural language interfaces or by becoming invisible infrastructure deep in the stack underneath AI workloads.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=0s) On paper, completing an academic PhD or going directly into industry often results in identical corporate engineering levels over the same timeframe. - [00:00](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=0s) Doctoral research under an advisor provides foundational training in structuring arguments and communicating ideas clearly in writing and speech. - [00:00](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=0s) Clear communication skills proved decisive during the six-month internal campaign at Google to gain approval for open-sourcing Kubernetes. - [00:00](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=0s) Teaching introductory computer science classes gave Burns the empathy and pedagogical framing needed to explain containers and orchestration to an unfamiliar industry. - [02:52](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=172s) Early-career engineers should prioritize whatever topic energizes them enough to sustain deep focus rather than forcing themselves into trendy fields like AI. - [02:52](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=172s) Having no rigid career plan and pursuing interesting, useful problems allows engineers to organically connect disparate career experiences backwards. - [02:52](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=172s) Career paths that initially feel like mistakes or dead ends often impart the exact skills needed for major future accomplishments. - [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) Engineers should avoid falling in love with their software, as attachment prevents them from letting systems go when their lifespan expires. - [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) Codebases must be treated as ephemeral; the initial Kubernetes implementation has already undergone multiple rewrites over the past decade. - [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) Declarative YAML manifests could eventually be superseded by natural language interfaces that deliver reliable web services with lower cognitive overhead. - [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) Kubernetes is increasingly becoming commoditized infrastructure that sits quietly beneath AI workloads, with baseline system churn largely plateauing. - [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) Predicting long-term technological horizons is difficult because shifts either materialize far faster than anticipated—like ARM64 and GPUs on servers—or stall for decades.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=0s) The Value of a PhD: Career Parity vs. Core Communication Skills

When asked whether getting a PhD is worth it—one of the top five or ten questions he is asked most frequently—Brendan Burns frames his perspective through two contrasting stories. In the first story, Burns recounts running into a former classmate from his undergraduate years while working at the same company. They had graduated in the exact same year with the exact same degree. While Burns went off into academia to pursue a PhD in robotics, his friend went straight into startups and navigated the standard tech industry path. Upon reuniting at the company, Burns realized they were sitting at the exact same corporate engineering level. Viewed purely through that lens, Burns shrugs off the academic credential with an indifferent *"Eh?"*, pointing out that on paper, doing the PhD or going straight to industry probably makes little difference to career trajectory.

However, Burns turns that conclusion around by highlighting the personal and professional upside that industry experience does not naturally provide. First, he genuinely enjoyed doing a robotics PhD: *"I had a lot of fun doing a PhD in robotics. So that's worth it to me."* More importantly, working under his PhD advisor taught him how to structure ideas, present arguments, and communicate clearly in written and oral form. Those specific communication skills proved essential later in his career, particularly during the intense six-month period at Google where he and his team had to argue internally for permission to open-source Kubernetes.

Additionally, Burns spent a couple of years as a professor teaching CS 101. Having to break down computing fundamentals for freshmen who knew nothing about computer science directly shaped how he structured and introduced the early Kubernetes ecosystem. When developers first encountered Kubernetes, the concepts were entirely foreign—people were constantly asking what a container was, what orchestration meant, and how any of it worked. His teaching background gave him the empathy and instructional structure needed to teach an entirely new paradigm to the software community.

[02:52](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=172s) Learning What Energizes You and the Myth of Career Planning

When asked about the single question he hears most often, Burns points to early-career engineers and interns asking: *"How do I know what I should learn?"* With the massive hype around artificial intelligence, people repeatedly ask whether they should pivot to AI because it is hot, even if their actual passion lies in systems engineering. Burns's answer is blunt: *"I actually kind of don't care what you learn. I care that you're learning."* He advises people to pursue whatever energizes them enough to work on it instead of procrastinating by watching YouTube. Forcing oneself to learn AI without genuine interest guarantees mediocre learning and wasted time, whereas throwing passion into systems engineering still yields tremendous value because the industry will always need strong systems engineers.

```mermaid flowchart TD accTitle: Burns Career Learning Philosophy accDescr: Diagram illustrating how intrinsic excitement drives deep learning and retrospective career value.

subgraph Mindset["Internal Driver"] Interest["Follow Genuine Excitement<br/>(e.g., Systems vs. AI)"] DeepEffort["Deep Energy & Sustained Focus<br/>(Choose over passive distraction)"] end

subgraph Outcome["Career Impact"] Mastery["True Technical Depth"] Retrospective["Retrospective Value<br/>(Apparent 'dead ends' build critical skills)"] end

Interest --> DeepEffort DeepEffort --> Mastery Mastery --> Retrospective ```

Burns identifies a widespread anxiety among junior engineers—a persistent fear of making the "wrong decision." He counters this mindset by confessing that he has never once had a grand plan for his career: *"There was no plan. I've never had a plan for my career. Like never ever ever."* Instead, he simply chased problems that seemed useful, fun, or interesting at the time. Echoing the themes of Steve Jobs's famous Stanford commencement address about connecting dots backwards, Burns notes that paths that appear to be mistakes or dead ends often turn out to be the exact experiences that teach someone their most indispensable skills.

[04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) "The Inevitable Trajectory of Software Is Death"

Ryan Peterman brings up a striking line Burns once wrote: *"The inevitable trajectory of software is death."* Burns laughs and confirms he stands fully behind the statement, adding the critical preceding thought: engineers should never fall in love with their software, because falling in love prevents them from letting it go when its lifespan is over. Software should never be preserved merely because someone spent time writing it; engineers must always remain willing to throw code away. Even within Kubernetes, the original codebase Burns wrote over a decade ago has been rewritten multiple times.

When considering what the end of Kubernetes looks like, Burns outlines two distinct trajectories for software obsolescence: - **Replacement by simpler abstractions:** A technology arrives that accomplishes the same operational goals with significantly less complexity and higher utility. Burns points out that natural language interfaces could eventually displace declarative manifests: it is inherently easier to tell an interface *"I would like reliable web service"* than to churn out endless lines of *"YAML YAML YAML YAML YAML"*. - **Commoditization and total invisibility:** Rather than disappearing entirely, a layer becomes so deep in the stack that everyone takes it for granted and stops interacting with it directly. Just as Linux sits largely unseen beneath Kubernetes, and silicon processors sit beneath Linux, Kubernetes may simply fade into the deep background beneath AI workloads. Burns observes this shift is already occurring—overall system churn has plateaued, and AI support remains the primary area driving fresh development.

Looking out over a century-long horizon, Burns remarks that he would be shocked if Kubernetes were still actively running 100 years from now. Predicting technological longevity is notoriously difficult because paradigm shifts often unfold at unexpected speeds. Six years ago, predicting the decline of x86 on the server seemed far-fetched, yet today massive processing has shifted to GPUs, and ARM64 has become a major server platform due to power efficiency. Technology either arrives vastly faster than anticipated or stalls indefinitely—much like self-driving cars, which Burns notes have famously been *"5 years away for like the last 15 years."*

## Notable quotes > [00:00](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=0s) Eh? — Brendan Burns

> [00:00](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=0s) I had a lot of fun doing a PhD in robotics. So that's worth it to me. — Brendan Burns

> [02:52](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=172s) How do I know what I should learn? — Brendan Burns

> [02:52](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=172s) I actually kind of don't care what you learn. I care that you're learning. — Brendan Burns

> [02:52](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=172s) There was no plan. I've never had a plan for my career. Like never ever ever. — Brendan Burns

> [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) The inevitable trajectory of software is death. — Brendan Burns

> [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) I would like reliable web service — Brendan Burns

> [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) YAML YAML YAML YAML YAML — Brendan Burns

> [04:43](https://www.youtube.com/watch?v=KZ70tKLbOEo&t=283s) 5 years away for like the last 15 years. — Brendan Burns

## Mentioned Brendan Burns, Ryan Peterman, Kubernetes, Microsoft, Azure, Google, YouTube, Steve Jobs, Stanford, YAML, Linux, x86, ARM64

## Video description This is a conversation with Brendan Burns, co-creator of Kubernetes and current technical fellow at Microsoft working on Azure. We discussed what it was like building it at Google, how he got buy-in, and what he learned along the way.

Watch the full conversation: https://www.youtube.com/watch?v=FKijpCEH9D8

[Source](https://www.youtube.com/watch?v=KZ70tKLbOEo)

中文简报

Kubernetes联合创始人Burns反对盲目转行AI，并预测该系统终将走向消亡工程师应投身于真正能激发自身活力的工作，而非追逐AI炒作或企业的职业规划；同时要随时准备舍弃包括Kubernetes在内的任何软件，因为所有代码终将不可避免地消亡或隐入底层基础设施。 Brendan Burns回顾了攻读博士学位的现实得失，他解释说，尽管这并未让他在行业职级上比直接就业的同龄人更具优势，但学术界培养了他至关重要的沟通、教学和辩论能力，这些对于推销和普及Kubernetes必不可少。他建议处于职业生涯早期的工程师不要追逐人工智能等受潮流驱动的职业规划，而是敦促他们追随那些真正能激发自身活力并促使其深入学习的领域。最后，Burns阐述了他的观点，即软件不可避免的命运是过时与消亡，并告诫开发者永远不要迷恋自己的代码，因为Kubernetes本身也正逐渐走向同质化、成为隐形的基础设施，或被更简单的自然语言抽象层所取代。对Brendan Burns而言，攻读博士学位与直接进入工业界最终获得的企业工程师职级相同，但学术界赋予了他至关重要的沟通和教学技能，这对推出Kubernetes必不可少。 (0:00) Burns告诫工程师不要在缺乏真正兴趣的情况下追逐AI等被热炒的领域，并强调保持深度投入远比刻板的职业规划更重要。 (2:52) 由于所有软件都不可避免地面临消亡，开发者必须避免迷恋自己的代码，并坦然接受彻底舍弃或重写系统。 (4:43) Kubernetes未来可能会走向衰落，要么被自然语言交互界面等更简单的抽象层所取代，要么成为AI工作负载之下深藏于技术栈中的隐形基础设施。 (4:43)

Reading summary

Kubernetes co-creator Brendan Burns argues that engineering careers are best driven by intrinsic curiosity and communication skills rather than rigid planning or credentials, while cautioning that all software—including Kubernetes—inevitably faces obsolescence. Academic Training and Communication Over Credentials (0:00) Evaluating whether a PhD is worthwhile, Burns observes that formal academic credentials offer little comparative advantage on paper. After completing a doctorate in robotics, he re-encountered an undergraduate classmate who had entered startups immediately; both occupied the exact same corporate engineering level. Burns views the academic pedigree itself with indifference regarding pure career progression. However, Burns credits the doctorate and his subsequent experience as a CS 101 professor with cultivating skills that industry work rarely instills. His doctoral research taught him to structure ideas and communicate persuasive arguments, which proved crucial during a six-month internal effort at Google to win approval for open-sourcing Kubernetes. Furthermore, teaching computing fundamentals to freshmen provided the pedagogical structure and empathy needed to explain unfamiliar concepts like containers and orchestration to developers when Kubernetes first launched. Intrinsic Engagement Versus Strategic Career Planning (2:52) When addressing junior engineers anxious about whether to pivot toward artificial intelligence or stick with fields like systems engineering, Burns advises following whatever topic sustains energy rather than pursuing hype. In his view, forcing oneself to learn a popular subject without genuine interest results in mediocre comprehension, whereas persistent demand ensures strong systems engineers will remain valuable. Burns counters the common fear of making incorrect career moves by stating he has never operated with a long-term plan. He advocates pursuing problems that seem useful or interesting in the moment, noting that seemingly disjointed experiences or career dead ends often provide the foundational capabilities required for future breakthroughs. Software Obsolescence and the Fate of Kubernetes (4:43) Revisiting his statement that "the inevitable trajectory of software is death," Burns cautions developers against falling in love with their code, noting that the original Kubernetes codebase has already been rewritten several times. Engineers must remain prepared to discard systems once their utility fades. Burns outlines two paths for obsolescence: replacement by simpler abstractions, such as natural language interfaces supplanting complex declarative YAML manifests, or commoditization into an invisible infrastructure layer beneath AI workloads, comparable to Linux running beneath Kubernetes. With Kubernetes development plateauing outside AI integrations, Burns doubts the platform will persist over a 100-year horizon, noting how unforeseen architectural shifts—such as the rapid rise of ARM64 and GPUs over x86—consistently disrupt technological longevity. Burns emphasizes that technological forecasting remains volatile, with paradigms either stalling indefinitely or transforming stacks far faster than expected. Consequently, engineers are better served by mastering communication and adaptable fundamentals than by anchoring their identities to specific technologies.

Source quotes

[0:00] Brendan Burns: Eh? [0:00] Brendan Burns: I had a lot of fun doing a PhD in robotics. So that's worth it to me. [2:52] Brendan Burns: How do I know what I should learn? [2:52] Brendan Burns: I actually kind of don't care what you learn. I care that you're learning. [2:52] Brendan Burns: There was no plan. I've never had a plan for my career. Like never ever ever. [4:43] Brendan Burns: The inevitable trajectory of software is death. [4:43] Brendan Burns: I would like reliable web service [4:43] Brendan Burns: YAML YAML YAML YAML YAML [4:43] Brendan Burns: 5 years away for like the last 15 years.

Original transcript

[0:00] You mentioned that you had a PhD in [0:01] robotics and I hear a lot of people say [0:04] they don't recommend PhD. Some people [0:06] do. Curious what your take on on getting [0:08] a PhD is. [0:09] >> Yeah, that's probably like like if I had [0:11] to have a top 10 questions or top five [0:13] questions that people ask me, [0:15] that's definitely in the top five top 10 [0:17] questions. Um and I guess I'll I'll I'll [0:20] answer it with two different stories. [0:22] Um One story is that [0:25] at one point in my career, I ran into a [0:28] guy same company, this guy who I'd went [0:31] to undergrad with. [0:33] Um and he'd gone off and done startups [0:36] and you know, done the tech industry [0:38] thing and ended up in the same company [0:40] that I was working at. And I'd gone off [0:41] and done my PhD and come back into the [0:43] industry and and we were the exact same [0:45] level. We graduated the exact same year, [0:47] same degree, and we were at the exact [0:49] same level in this company. And so I [0:52] guess that's one way of me saying like, [0:54] "Eh?" [0:55] You know, like it probably doesn't [0:56] matter. It probably doesn't matter one [0:58] way or the other. Um [1:01] but I'll also turn it around and say, [1:04] "A, I had a lot of fun." [1:06] Right? So like I had a lot of fun doing [1:07] a PhD in robotics. So [1:10] that's worth it to me. Um [1:13] and then two, I think I learned a lot [1:16] about how to [1:18] I think from the PhD and my PhD adviser, [1:21] I learned a lot about how to write and [1:23] put my ideas forth in both written and [1:25] presentation form. [1:28] That you don't necessarily learn in the [1:29] industry. [1:31] Um and I think that benefited me. I [1:32] think that benefited my ability to you [1:35] know, argue. We talked about that [1:36] six-month period where we were arguing [1:38] for like why we should be allowed to [1:40] open source this thing. Um [1:42] I think the thing the skills I learned [1:43] in terms of presentation and in terms of [1:45] writing [1:46] benefited me during that time. [1:49] Um [1:50] and have continued to benefit me. [1:52] Um [1:53] and and then I think [1:55] you know, when I went out I was a [1:56] professor for a couple years, Um [1:58] teaching CS 101 and having to like [2:00] explain stuff to students who didn't [2:02] really know anything about computers, um [2:06] I think really helped me organize the [2:08] the in the initial parts of the [2:11] Kubernetes project so that somebody [2:12] could learn about Kubernetes cuz people [2:13] were coming in and being like, "What is [2:14] a container? What is orchestration? How [2:16] do I do this?" Like, there's a lot of [2:18] like just teaching that you had to do [2:20] and and I think that experience as a [2:21] professor thinking about how do I teach [2:23] students something really help me do a [2:26] good job um [2:28] with, you know, teaching Kubernetes to [2:30] people. [2:31] Um [2:31] and so I think those things were really [2:33] beneficial and so I guess there's [2:34] there's, you know, the two different [2:35] arguments, which is one is like [2:38] doesn't matter. The other is I learned a [2:40] ton of stuff that I think was pretty [2:41] useful to my career [2:43] um [2:44] and I had some fun. [2:45] >> Earlier you said a top questions that [2:48] people ask you and I'm kind of curious, [2:50] what's the top question? [2:52] >> I think the one the other one that I get [2:54] a lot um [2:56] is uh [2:58] how do I know what I should learn? [3:00] Like, a lot of a lot of especially when [3:01] I talk to the interns for the first [3:03] couple years, [3:05] you know, a lot of the questions were [3:06] right revolving around like, "AI seems [3:08] really hot right now, but I'm really [3:09] interested in systems. Like, should I [3:11] like go learn AI cuz it's hot or should [3:14] I learn systems cuz I think systems are [3:16] interesting?" I actually kind of don't [3:17] care what you learn. I care that you're [3:19] learning. [3:20] Um and and so the most important thing [3:23] is to find something that you're excited [3:25] about and energized about um [3:27] because, you know, you'll do that [3:29] instead of watching YouTube. [3:31] Uh you know, so if you're not excited [3:32] about AI, like, well, you're probably [3:34] not going to do a very good job learning [3:36] AI, which means that you're kind of [3:38] going to waste your time. [3:39] Um but if you're really excited about [3:41] systems, you'll probably put a lot of [3:43] passion and energy into it and, you [3:45] know, we still need systems engineers. [3:47] Like, so [3:48] um [3:49] uh you know, I think that's the that's [3:51] kind of a pretty popular question. I [3:53] think there's a lot of [3:55] I sense anyway a lot of like [3:57] fear [snorts] of making the wrong [3:58] decision. [4:00] And [4:02] uh [4:03] I will tell everybody like there was no [4:04] plan. [4:05] I've never had a plan for my career. [4:07] Like never ever ever. [4:09] Like I've always just chased after [4:10] things that I thought were useful and or [4:12] fun and interesting. [4:14] Um [4:15] and [4:17] and you know, obviously like that can [4:19] work out badly for people. I'm sure it's [4:21] good to have a plan probably for some [4:22] people, but like I also want to make [4:24] sure people understand that like [4:26] when you look back [4:27] sometimes the things you think were [4:29] mistakes or dead ends like actually were [4:32] critical things that taught you stuff. [4:34] Um [4:35] and so like worrying about did I choose [4:37] the wrong thing? Am I going to choose [4:39] the wrong thing? Like [4:41] as long as you're learning, you're [4:42] probably doing okay. [4:43] >> I mean what you're describing it reminds [4:45] me of I don't know if you've seen that [4:47] Steve Jobs commencement speech, but he [4:50] he literally says exactly that. You [4:53] wrote down somewhere. I I don't fully [4:55] remember where you wrote this down, but [4:56] I have this in my notes. It says [4:58] the inevitable trajectory of software is [5:01] death. [5:01] >> [laughter] [5:02] >> And I just can't imagine Kubernetes [5:04] dying, but I how do you see that [5:07] happening and you know, what what what [5:08] do you think about that if it did? [5:11] >> I mean I definitely stick by that [5:14] that statement. Um [5:16] although I think that [5:17] the sentence before I said that was you [5:20] really should never fall in love with [5:22] your software [5:23] because the inevitable [5:25] trajectory of software is death. I am [5:28] it's which means don't stick with it. [5:30] Don't stick with it past when it's [5:31] dying, right? I am [5:34] like you should always be willing to [5:35] throw away stuff. Just don't stick with [5:36] it just cuz you wrote it. You should [5:38] always be willing to throw it away. [5:40] But like obviously I think if you look [5:42] historically across the industry, it's [5:44] it's true too, right? Like like Um and [5:48] quite frankly like even within [5:49] Kubernetes like [5:51] the source code that I wrote has been [5:53] rewritten a number of times. [5:55] Um [5:57] over the 10 plus years history of the [5:58] project. Um [6:00] so what does it look like? I mean I [6:01] think it looks like uh [6:03] something coming along that achieves [6:05] similar things but easier with more uh [6:10] you know with with less complexity and [6:11] and more utility. [6:13] Um and and I think that [6:15] you know I can imagine what that looks [6:17] like. Like I think some of these natural [6:19] language stuff if you could actually [6:21] really get it to be an interface that [6:22] worked 100% of the time. Like obviously [6:25] it's way easier to come in and say [6:27] I would like reliable web service than [6:29] it is to say YAML YAML YAML YAML YAML. [6:32] You know, I I think sometimes I I think [6:34] it's sort of your two different [6:34] trajectories. Like sometimes the [6:35] trajectory is it it goes away. Sometimes [6:38] it just becomes so hidden that nobody [6:40] sees it. [6:41] Right? Like underneath Linux there's [6:44] I mean excuse me, underneath Kubernetes [6:46] there's Linux. And underneath Linux [6:48] there's a processor. But you know, [6:49] people don't pay much attention to that. [6:51] Um [6:52] and there's a lot of attention now on AI [6:54] and underneath a lot of the AI is Linux [6:55] but it could be that people's focus so [6:57] much on the AI that they forget about [6:59] the Kubernetes part. [7:01] Um and I think that's happening already [7:03] honestly. Like I feel like [7:05] if I look at the volume of changes and [7:07] things like that like I think it's you [7:08] know I think we've sort of plateaued in [7:10] terms of like the amount of change [7:12] that's driving through the system. Um [7:15] stuff needed to support AI is kind of [7:16] like the [7:17] exception to that category. [7:19] Um [7:21] but you know, I [7:24] I I'd be shocked. I mean I guess put it [7:25] this way like let me take the long view [7:26] and say [7:28] in a 100 years [7:29] is Kubernetes still going to be running? [7:31] I'd be pretty surprised. [7:33] >> [laughter] [7:33] >> Right? Uh no way. It's hard to imagine, [7:36] right? Um that that that would be true. [7:38] I mean I don't know. We haven't had [7:39] computing systems for long enough to [7:41] maybe know for certain. [7:42] Um [7:44] And And there are things that we still [7:46] use. I mean, there is some stuff that we [7:48] still use from back then. Plugs are [7:50] still the same shape-ish, stuff like [7:52] that. [7:53] Um [7:54] so maybe. [7:55] But even like something like x86, like [7:56] if you'd asked me 6 years ago and said, [7:59] "Is the x86 processor going away?" [8:01] I'd say like, "Well, maybe on I mean, [8:04] obviously on mobile it did, but like in [8:06] the server? [8:08] Maybe not." Um but now two things have [8:11] happened. One is all the processing is [8:12] on GPU now. And two, like arm64 is now [8:17] pretty important platform on the server [8:18] for energy usage and other reasons, [8:20] right? And so [8:22] it's pretty dangerous to predict the [8:24] future cuz like it has a tendency of [8:26] show up sooner than you you you predict. [8:29] So, or or longer than you predict, too, [8:31] right? Self-driving cars, like I've [8:32] heard I've heard self-driving cars were [8:34] 5 years away for like the last 15 years.