Podcast appearances and mentions of kelsey hightower

In this segment of the My Open Source Experience podcast, Kelsey Hightower shares his current adventures, which includes a home improvement project.As Kelsey is now advising startups, rather than working in 9-5 jobs, he highlights the importance to keep your energy and drive, no matter when you retire, and how someone can't stop sharing once they started.While Kelsey talks about his adventures to install new bidets in his house, he also drives analogies to software development and decision making. Always remember before you start refactoring something:- You need to be careful to avoid breaking things- It needs to be backwards compatible- It needs to look better than beforeKelsey and Phil draw an analogy and describe engineers being somewhere between tradesmen and artists. Can you relate?But, does Kelsey have any working bidets in his house yet? Hosted on Acast. See acast.com/privacy for more information.

Building a business strategy is hard in general, and when open source becomes part of the equation it can get even more challenging.In the recent past there were multiple examples of companies changing the license on their open source project to something less or not at all open. This is often harmful to the companies themselves and the pattern is always harmful tot he open source ecosystem.In this episode of the My Open Source Experience podcast Gregory Kurtzer and Kelsey Hightower share their experiences to dig deeper into the challenges and solutions to building a business around open source.You will learn the following:- How to evaluate if your company is ready to get involved in an open source project or open up one of their internal ones- Why it matters who owns an open source project's trademark- Why is lock out sometimes worse than lock in- How to identify the business value when relying on open source projects- How to figure out which open source project is viable to build a business around- Empty promises don't work long term Hosted on Acast. See acast.com/privacy for more information.

We have stories to share, guests joining us, insights from our week at Planet Nix, and Brent's big bombshell.Sponsored By:Tailscale: Tailscale is a programmable networking software that is private and secure by default - get it free on up to 100 devices! 1Password Extended Access Management: 1Password Extended Access Management is a device trust solution for companies with Okta, and they ensure that if a device isn't trusted and secure, it can't log into your cloud apps. River: River is the most trusted place in the U.S. for individuals and businesses to buy, sell, send, and receive Bitcoin. Support LINUX UnpluggedLinks:

We're pre-gaming two of the biggest Linux events of the year. Engineers, organizers, and surprise guests are dropping by to give us the scoop before it all begins.Sponsored By:Tailscale: Tailscale is a programmable networking software that is private and secure by default - get it free on up to 100 devices! 1Password Extended Access Management: 1Password Extended Access Management is a device trust solution for companies with Okta, and they ensure that if a device isn't trusted and secure, it can't log into your cloud apps. River: River is the most trusted place in the U.S. for individuals and businesses to buy, sell, send, and receive Bitcoin. Support LINUX UnpluggedLinks:

Getting involved and investing time and resources into upstream projects can be a complicated decision and process for individuals and companies alike. Have you experienced this already?In this episode of the MOSE podcast, Kelsey Hightower talks about his open source journey, and shares tips and tricks to ensure a successful and sustainable engagement in the ecosystem. He has a versatile background, as he's been an enterprenour, a full-time employee, and creator and contributor of open source projects. He's always been driven to learn, including new tech just as much as building fundamental knowledge, and this approach became key to be successful at his work in companies and communities.Kelsey shares some of the key findings he's had throughout his career:- Incentives to invest in upstream work, both in personl and corporate context- Temporary checkpoint concept- How to make the right decision in a given moment, and then re-evaluate it- Transparency and clear communication Hosted on Acast. See acast.com/privacy for more information.

In this never-published recording, Keith Townsend, Chief Technology Advisor, talks with Kelsey Hightower, fresh off his then promotion to Google Distinguished Engineer. The two explore the trajectory that brought Kelsey to this prestigious title.

In this insightful episode of Teaching Python, hosts Sean Tibor and Kelly Schuster-Paredes engage in a dynamic conversation with the eminent Kelsey Hightower. The episode delves into Hightower's journey from self-taught programmer to distinguished engineer at Google, touching on the significance of lifelong learning and the non-traditional paths that many successful technologists follow. Hightower's anecdotes are not only inspiring but also provide valuable lessons on perseverance and the importance of staying curious. The episode tackles key themes around the entrepreneurial mindset, advising both students and educators on how to take calculated risks and break away from conventional norms. Hightower shares his unique insights on how thinking like an entrepreneur can lead to personal and professional growth, and how these principles can be applied even in structured educational environments. His stories about facing and overcoming challenges offer a blueprint for anyone looking to innovate within their current roles. For educators, Hightower's discussion emphasizes the need to look beyond the standard curriculum and foster an environment where students feel empowered to explore and experiment. The episode is rich with ideas on how to cultivate a nurturing yet challenging atmosphere that encourages students to think independently and embrace failure as a stepping stone to success. Whether you are a teacher, student, or tech enthusiast, this episode provides a wealth of wisdom on nurturing potential and achieving excellence.

Kelsey Hightower is a legend. He regularly gives live software demos in front of tens of thousands of people, improvising them like it's jazz. He's a master storyteller and a master craftsman. He helped evangelize and establish Kubernetes and recently retired (at 42!) from Google where he was a distinguished engineer. Kelsey loves to level people up and in this conversation we discuss the power of innovation that happens after going from Zero to One. Or, as Kelsey puts it, “From Hello, World to Hello, Revenue” — and why those boring innovations show true grit and craftsmanship. We also discuss the art of the demo, how Kelsey engages crowds with his humanity, and how you can, too. And Kelsey shares what he's learned in his first year of retirement. He's actually quite busy and has to remind folks that “I'm retired; not tired.” He's fixing up his house, making time for others, and “learning how to live.” We get into what that means… This episode is very special. Enjoy!Key Moments:[03:06] “I'm retired; not tired.” – What Kelsey's been up to in his first year off the job — and why he refuses to mount his TV over the fireplace[04:51] “How do the makers mature?” — Kelsey's thoughts on how developers can advance their careers by getting good at innovating after, sometimes long after, going from zero to one[08:53] Keeping an open mindset: how developers integrate new technologies, e.g. Docker [17:13] “Creating good software is very emotional”[20:40] The art of the live demo[25:39] Humans are natural storytellers – embrace it! [27:31] Vulnerability and how Kelsey learned to be so confident on stage[30:38] The time Kelsey nearly bombed on stage, but turned it around into an “extra dope” moment on stage at a Google keynote[36:15] “A lot of people don't realize how much power they have until way later in life” – why even the really little things (like saying hello to a stranger) matter[39:28] Representation matters: being a black man in tech[42:15] The power of open source[45:04] “What is my actual impact on society?” — why Kelsey retired: [47:46] Kelsey's hopes for the future — and why we should be more excited about human intelligence, not just artificial intelligence***CRAFTED. is brought to you in partnership with Docker, which helps developers build, share, run and verify applications anywhere – without environment confirmation or management. More than 20 million developers worldwide use Docker's suite of development tools, services and automations to accelerate the delivery of secure applications. CRAFTED. is produced by Modern Product Minds, where CRAFTED. host Dan Blumberg and team can help you take a new product from zero to one... and beyond. We specialize in early stage product discovery, growth, and experimentation. Learn more at modernproductminds.com Subscribe to CRAFTED., follow the show, and sign up for the newsletter

Meet Angie Jones

Redis is no longer open source. Just a few months ago, in March 2024, the project was relicensed, leaving its vast community confused. But the community did not give up, and started work to fork Redis to keep it open.  In this episode, we delve into the Valkey project, a prominent fork of Redis, established under the Linux Foundation, which brought together important figures from the Redis community, as well as leading industry giants including AWS, Google Cloud, Oracle and others. Valkey has rapidly gained momentum and just reached General Availability (GA).  Join us as we explore the motivations behind Valkey's creation, hear first-hand stories on its foundation and journey to GA, and learn of its Redis compatibility, roadmap and implications for the open-source community.  Valkey's first Contributor Summit is taking place June 5-6 in Seattle and we will bring you announcements and updates hot off the summit. Our guest is Kyle Davis, the Senior Developer Advocate on the Valkey project, and a past contributor for Redis.  Kyle currently works at AWS, a founding member of Valkey, and has a long history with open source and with forks. He was a founding contributor to the OpenSearch project, which started as a fork of Elasticsearch and Kibana after the latter's relicensing off OSS. Most recently Kyle worked to build a community around Bottlerocket OSS project.   The episode was live-streamed on 10 June 2024 and the video is available at youtube.com/live/HQ7TAdQpxu4 OpenObservability Talks episodes are released monthly, on the last Thursday of each month and are available for listening on your favorite podcast app and on YouTube. We live-stream the episodes on Twitch and YouTube Live - tune in to see us live, and chime in with your comments and questions on the live chat. ⁠⁠https://www.youtube.com/@openobservabilitytalks⁠   https://www.twitch.tv/openobservability⁠ Show Notes: 01:12 - Episode intro, Kyle Davis' Redis background  05:43 - Redis relicensing off open source  10:10 - Valkey vs. other Redis open source forks 16:50 - drop-in replacement of Redis 19:35 - Redis user experience during the relicensing 28:50 - From fork to GA in less than a month 34:00 - Valkey roadmap and Contributor Summit updates 40:00 - Valkey's Technical Steering Committee and leadership 44:14 - what Valkey latest GA is about  Resources: Valkey announced: https://www.linkedin.com/posts/horovits_redis-opensource-activity-7179186700470861824-Gghq Valkey first GA and new member companies: https://www.linkedin.com/posts/horovits_redis-valkey-valkey-activity-7186263342041198593-fsY3 Announcements from Valkey's first Contributor Summit: https://www.linkedin.com/posts/horovits_valkey-welcomes-new-partners-amid-growing-activity-7209084153718362112-OfdI/ For Kubernetes 10th anniversary - special episode with Kelsey Hightower: https://logz.io/blog/kubernetes-and-beyond-2023-reflection/?utm_source=devrel&utm_medium=devrel Socials: Twitter:⁠ https://twitter.com/OpenObserv⁠ YouTube: ⁠https://www.youtube.com/@openobservabilitytalks⁠ Dotan Horovits ============ Twitter: @horovits LinkedIn: in/horovits Mastodon: @horovits@fosstodon Kyle Davis ======== LinkedIn: linkedin.com/in/kyle-davis-linux/ Mastodon: @linux_mclinuxface@fosstodon.org

“Learn the difference between activities and impact. Sometimes we spend our career trying to get really great at activities. Always ask yourself, what is the impact of the work I'm doing?” From Google Distinguished Engineer to early retirement, Kelsey Hightower has a career journey filled with lessons for tech professionals at every stage. In this episode, Kelsey reflects on his journey, revealing why he decided to retire early, and offering valuable insights and lessons learned. Discover the importance of an entrepreneurial mindset, differentiating between activity and impact, and building a strong personal brand. Kelsey reveals his top strategies for becoming a confident public speaker and shares his thoughts on staying engaged and planning your career path. Plus, we touch on the impact of AI on software developers' careers. Don't miss this opportunity to learn from one of the industry's most respected figures and gain a unique perspective on achieving career success and fulfillment.   Listen out for: Career Journey - [00:01:35] Entrepreneurial Mindset - [00:04:15] Taking Risks in Our Role - [00:07:50] Activity vs Impact - [00:11:45] Thinking in Bigger Impact - [00:16:04] Impact of AI - [00:24:52] Getting Good at Public Speaking - [00:31:23] Building a Personal Brand - [00:38:05] Retiring Early - [00:44:04] Getting Engaged in Our Career - [00:50:49] Tech Lead Wisdom - [00:57:48] _____ Kelsey Hightower's BioKelsey has worn every hat possible throughout his career in tech and enjoys leadership roles focused on making things happen and shipping software. Prior to his retirement, he was a Distinguished Engineer at Google, where he worked on Google Cloud Platform. He is a strong open source advocate with a focus on building great software as well as great communities around them. He is also an accomplished author and keynote speaker with a knack for demystifying complex topics, doing live demos and enabling others to succeed. When he is not writing code, you can catch him giving technical workshops covering everything from programming to system administration. Follow Kelsey: Twitter / X – @kelseyhightower LinkedIn – linkedin.com/in/kelsey-hightower-849b342b1 Email – kelsey.hightower@gmail.com _____ Our Sponsors Enjoy an exceptional developer experience with JetBrains. Whatever programming language and technology you use, JetBrains IDEs provide the tools you need to go beyond simple code editing and excel as a developer.Check out FREE coding software options and special offers on jetbrains.com/store/#discounts.Make it happen. With code. Manning Publications is a premier publisher of technical books on computer and software development topics for both experienced developers and new learners alike. Manning prides itself on being independently owned and operated, and for paving the way for innovative initiatives, such as early access book content and protection-free PDF formats that are now industry standard.Get a 40% discount for Tech Lead Journal listeners by using the code techlead24 for all products in all formats. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/180. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

It's not a conference unless you can confer, right? POSETTE organizers Teresa Giacomini and Aaron Wislang join Claire Giordano on the Path To Citus Con podcast to share backstage perspectives on the making of POSETTE: An Event for Postgres. How do you feel about captions: love or hate? Should livestream talks be pre-recorded or presented live? Why rename from Citus Con to POSETTE? Where did the inspiration for POSETTE come from? And can the hallway track at a conference actually be fun—if it is virtual? Also discussed: Avett Brothers lyrics, the surprising number of POSETTE speakers with chickens, and the existential question of whether the work in organizing a conference is worth it.Links mentioned in this episode: Blog post: What's in a name? About the naming of POSETTE: An Event for PostgresFOSDEM: the conference whose name inspired the POSETTE namePlaylist of all 42 talks from POSETTE: An Event for Postgres 2024Playlist of the 4 unique livestreams from POSETTE 2024 CFP is open: PGDay Lowlands 2024 Call for Papers will close July 9, 2024Virtual conference that POSETTE organizers were inspired by: P99 ConfDiscord: Microsoft Open Source Discord, Home for virtual hallway track for #posetteconfAdam Wølk's speaker page for POSETTESpeaker interview with Polina Bungina at POSETTEBlog post: About Talk Selection for POSETTE: An Event for Postgres 2024, by Claire GiordanoBlog post: Building the PGConf.dev Programme, by Paul RamseypgDay Paris 2024 note about talk selection processKeynote: All The Postgres Things at Microsoft, POSETTE edition, by Charles FeddersenKeynote: The Open Source Geospatial Community, PostGIS, & Postgres, by Regina ObeKeynote: Why I love open source development & what I learned from K8s, by Sarah NovotnyKeynote: A Walking Tour of PostgreSQL, by Thomas MunroLyrics from The Perfect Space by The Avett BrothersVideo: Lessons Learned benchmarking & profiling distributed PostgreSQL, by Lotte FeliusVideo: Postgres Storytelling: Support in the Darkest Hour | Citus Con 2023, by Boriss Mejías Video: Postgres Storytelling: What's going on with Synchronous Replication?, by Boriss MejíasVideo: Vindicating ZFS with PostgreSQL: Unleashing the Power of Scalability, includes a bit of jazz music by Federico CampoliBlog post: Ultimate Guide to POSETTE: An Event for Postgres, 2024 editionSocial post: Tweet by Kelsey Hightower with advice to conference organizersVideo from PGConfEU 2023: So you want a PGDay in your city, by Henrietta Dombrovskaya & Teresa GiacominiBlog post: The Story Behind the Activity Book for Postgres, by Teresa Giacomini

Kelsey Hightower is back to share more of his wisdom. This time it's one year after his retirement from Google. But guess what? He might be “retired,” but he's not tired. In this episode Kelsey shares what drives him, what he fears, and how he thinks through his life choices and parenting. This is a good one.

Kelsey Hightower is back to share more of his wisdom. This time it's one year after his retirement from Google. But guess what? He might be “retired,” but he's not tired. In this episode Kelsey shares what drives him, what he fears, and how he thinks through his life choices and parenting. This is a good one.

Welcome to the second episode of the 4 part special series for the Kubernetes 10 year anniversary. In this episode we spoke to two very influential people in Kubernetes' history. Tim Hockin and Kelsey Hightower Both have been involved with the project since its inception and both had, and continue to have, impact on the project and the community.   Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod   Chatter of the week KuberTenes Regional Events Kubernetes Twitter Account News of the week Kubernetes introduces hydrophone AKS Automatic CKS Changes after Sept 12, 2024 KubeCon and CloudNativeCon CFP Closes June 9th KubeCon Co-Located events CFP Closes June 14, 2024 Links from the interview Google Borg Google Omega Let Me Contain That For You Kubernetes Sidecars Why Service Is the Worst API in Kubernetes Kubernetes Maintainers Read Mean Comments Kubernetes The Hard Way Kelsey retirement announcement Redpanda Crossplane Llama 3 Open-core model Lets Encrypt Google's infrastructure for everyone else Kubernetes: Up and Running CNI Kubernetes Networking Kubernetes Resource Model (KRM)

We're super excited to have Kelsey back on the show! Our last conversation was around his incredible career journey - from working at McDonald's after school to starting his own computer store, to hacking on python infrastructure with the core developers, to meeting Satya Nadella for an interview. In part two of this conversation, we dive deep into Kelsey's experiences learning in public and writing “Kubernetes: Up and Running”: The biggest barrier to getting started with learning in public and a step-by-step guide to overcome it Cautionary tale of the “JavaScript sucks” guy Developing the skill of crafting good analogies The business and economics of writing a book Much more   Segments: [0:01:12] Writing and learning in public. [0:10:58] Writing "Kubernetes: Up and Running." [0:16:05] The business and economics of writing a book. [0:21:27] Why your first book should not exceed 100 pages. [0:23:36] What prevented Kelsey from giving up on the book. [0:26:15] Being intentional about building an audience and the cautionary tale of the "JavaScript sucks" guy. [0:36:44] Authenticity does not guarantee success. [0:39:09] Developing the skill of crafting effective analogies. [0:47:47] Advice for engineers to leverage their technical skills outside of the nine-to-five.   Show Notes: Kelsey on twitter: https://twitter.com/kelseyhightower Our previous conversation with Kelsey about retiring as Distinguished Engineer from Google at 42: https://softwaremisadventures.com/p/kelsey-hightower-on-retiring-as-distinguished-057   Stay in touch:

By challenging assumptions and embracing experimentation, individuals and teams can unlock fresh ideas. To this end, collaboration fueled by diverse perspectives further strengthens this innovation cycle. In this episode, Kelsey Hightower shares his experiences, from challenging the status quo in large organizations to embracing the collaborative spirit of open-source communities. Discover how Kelsey's contributions to Puppet and his role in the development of Kubernetes shaped the landscape of modern infrastructure.Listen to the full episode or read the transcript on the Semaphore blog.Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.

We're super excited to have Kelsey back on the show! Our last conversation was around his incredible career journey - from working at McDonald's after school to starting his own computer store, to hacking on python infrastructure with the core developers, to meeting Satya Nadella for an interview. In part one of this conversation, we dive deep into Kelsey's experiences and expertise as a startup advisor: How to break into advising when you don't have a lot of connections How to influence without authority Passive vs. active advising How to add value as an advisor Setting boundaries and expectations Much more   Segments: [0:01:53] Being a "junior retiree" [0:11:00] How Kelsey got started with startup advising. [0:17:43] How to avoid mismatches in advisory engagements? [0:27:23] How to influence without authority as an advisor? [0:32:58] How to establish boundaries as an advisor. [0:38:29] Actions engineers can take today to prepare themselves for future startup advising roles. [0:42:55] How to manage the balance between advising and your primary job. [0:44:32] How to cultivate perspectives beyond engineering.   Show Notes: Kelsey on twitter: https://twitter.com/kelseyhightower Our previous conversation with Kelsey about retiring as Distinguished Engineer from Google at 42: https://softwaremisadventures.com/p/kelsey-hightower-on-retiring-as-distinguished-057   Stay in touch:

Kelsey is a pioneer in cloud computing and has led many advances in the implementation and adoption of cloud based software. He is a significant contributor to open source software, involved in many incredibly popular open source projects, including, but not limited to Kubernetes. Kelsey not only helped implement Kubernetes, but also helped to promote and spread its adoption and to build the community around it. In this episode Kelsey and Dave discuss a range of topics, centred on cloud computing, but also exploring software engineering and its nature in more detail. Find out if Dave and Kelsey disagree about stateful serverless and asynchrony.xx⭐ PATREON: Join the Continuous Delivery community and access extra perks & content! JOIN HERE ➡️ https://bit.ly/ContinuousDeliveryPatreon

Jason Lengstorf, a developer media producer and host of the show Learn with Jason, joins Corey on this week's episode of Screaming in the Cloud to layout his ideas for creative developer content. Jason explains how devTV can have way more reach than webinars, the lack of inspiration he experiences at conferences these days, and why companies should be focused on hiring specialists before putting DevRels on the payroll. Plus, Corey and Jason discuss walking the line between claiming you're good at everything and not painting yourself into a corner as a DevRel and marketer.About JasonJason Lengstorf helps tech companies connect with developer communities through better media. He advocates for continued learning through collaboration and play and regularly live streams coding with experts on his show, Learn With Jason. He lives in Portland, Oregon.Links Referenced:Learn with Jason: https://www.learnwithjason.dev/Personal Website Links: https://jason.energy/linksTranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Before I went to re:Invent, I snuck out of the house for a couple of days to GitHub Universe. While I was there, I discovered all kinds of fascinating things. A conference that wasn't predicated on being as cheap as humanly possible was one of them, and a company that understood how developer experience might play out was another.And I also got to meet people I don't normally get to cross paths with. My guest today is just one such person. Jason Lengstorf is a developer media producer at Learn with Jason, which I have to assume is named after yourself.Jason: [laugh] It is yes.Corey: Or it's a dramatic mispronunciation on my part, like, no, no, it's ‘Learn with JSON' and it's basically this insane way of doing weird interchange formats, and you just try to sneak it through because you know I happen to be an XML purist.Jason: [laugh] Right, I'm just going to throw you a bunch of YAML today. That's all I want to talk about.Corey: Exactly. It keeps things entertaining, we're going to play with it. So, let's back up a sec. What do you do? Where do you start and where do you stop?Jason: I'm still learning how to answer this question, but I help companies do a better job of speaking to developer audiences. I was an engineer for a really long time, I went from engineering into developer advocacy and developer experience, and as of the last year, I'm doing that independently, with a big focus on the media that companies produce because I think that what used to work isn't working, and that there's a big opportunity ahead of us that I am really excited to help companies move into.Corey: It feels like this has been an ongoing area of focus for an awful lot of folks. How do you successfully engage with developer audiences? And if I'm being direct and more than a little bit cynical, a big part of it is that historically, the ways that a company marketed to folks was obnoxious. And for better or worse, when you're talking about highly technical topics and you're being loudly incorrect, a technical audience is not beholden to some of the more common business norms, and will absolutely call you out in the middle of you basically lying to them. “Oh, crap, what do we do now,” seemed to be a large approach. And the answer that a lot of folks seem to have come up with was DevRel, which… I've talked about it before in a bunch of different ways, and my one-liner is generally, “If you work in DevRel, that means you work in marketing, but they're scared to tell you that.”Jason: [laugh] I don't think you're wrong. And you know, the joke that I've made for a long time is that they always say that developers hate marketing. But I don't think developers hate marketing; they just hate the way that your company does it. And—Corey: Oh, wholeheartedly agree. Marketing done right is engaging and fun. A lot of what I do in public is marketing. Like, “Well, that's not true. You're just talking about whatever dumb thing AWS did this week.” “Well, yes, but then you stick around to see what else I say, and I just become sort of synonymous with ‘Oh, yeah, that's the guy that fixes AWS bills.'” That is where our business comes from, believe it or not.Jason: Ri—and I think this was sort of the heart of DevRel is that people understood this. They understood that the best way to get an audience engaged is to have somebody who's part of that audience engage with them because you want to talk to them on the level that they work. You're not—you know, a marketing message from somebody who doesn't understand what you do is almost never going to land. It just doesn't feel relatable. But if you talk to somebody who's done the thing that you do for work, and they can tell you a story that's engaging about the thing that you do for work, you want to hear more. You—you know, you're looking for a community, and I think that DevRel, the aim was to sort of create that community and give people a space to hang out with the added bonus of putting the company that employs that DevRel as an adjacent player to get some of that extra shine from wherever this community is doing well.Corey: It felt like 2019 was peak DevRel, and that's where I started to really see that you had, effectively, a lot of community conferences were taken over by DevRel, and you wound up with DevRel pitching to DevRel. And it became so many talks that were aligned with almost imagined problems. I think one of the challenges of working in DevRel is, if you're not careful, you stop being a practitioner for long enough that you can no longer relate to what the audience is actually dealing with. I can sit here and complain about data center travails that I had back in 2011, but are those still accurate in what's about to be 2024? Probably not.Jason: And I think the other problem that happens too is that when you work in DevRel, you are beholden to the company's goals, if the company employees you. And where I think we got really wrong is companies have to make money. We have to charge customers or the company ceases to exist, so when we go out and tell stories, we're encouraged by the company to focus on the stories that have the highest ROI for the company. And that means that I'm up on stage talking about some, like, far-future, large-scale enterprise thing that very few companies need, but most of the paying customers of my company would need. And it becomes less relatable, and I think that leads to some of the collapse that we saw that you mentioned, where dev events feel less like they're for devs and more like they're partner events where DevRel is talking to other DevRel is trying to get opportunities to schmooze partners, and grow our partner pipeline.Corey: That's a big part of it, where it seems, on some level, that so much of what DevRel does, when I see them talking about DevRel, it doesn't get around to DevRel is. Instead, it gets stuck in the weeds of what DevRel is not“. We are not shills for our employer.” Okay, I believe you, but also, I don't ever see you saying anything that directly contravenes what your employer does. Now, let me be clear: neither do I, but I'm also in a position where I can control what my employer does because I have the control to move in directions that align with my beliefs.I'm not saying that it's impossible to be authentic and true to yourself if you work for an employer, but I have seen a couple of egregious examples of people changing companies and then their position on topics they've previously been very vocal on pulled an entire one-eighty, where it's… it really left a bad taste in my mouth.Jason: Yeah. And I think that's sort of the trick of being a career DevRel is you have to sort of walk this line of realizing that a DevRel career is probably short at every company. Because if you're going to go there and be the face of a company, and you're not the owner of that company, they're almost inevitably going to start moving in a direction as business develops, that's not going to line up with your core values. And you can either decide, like, okay that's fine, they pay me well enough, I'm just going to suck it up and do this thing that I don't care about that much, or you have to leave. And so, if you're being honest with yourself, and you know that you're probably going to spend between 12 and 24 months at any given company as a DevRel, which—by the history I'm seeing, that seems to be pretty accurate—you need to be positioning and talking about things in a way that isn't painting you into that corner where you have to completely about-face, if you switch companies. But that also works against your goals as a DevRel at the company. So, it's—I think we've made some big mistakes in the DevRel industry, but I will pause to take a breath here [laugh].Corey: No, no, it's fine. Like, it's weird that I view a lot of what I do is being very similar to DevRel, but I would never call myself that. And part of it is because, for better or worse, it is not a title that tends to engender a level of respect from business owners, decision makers, et cetera because it is such a mixed bag. You have people who have been strategic advisors across the board becoming developer advocates. That's great.You also see people six months out of a boot camp who have decided don't like writing code very much, so they're going to just pivot to talking about writing code, and invariably, they believe, more or less, whatever their employer tells them because they don't have the history and the gravitas to say, “Wait a minute, that sounds like horse pucky to me.” And it's a very broad continuum. I just don't like blending in.Jason: Where I think we got a lot of this wrong is that we never did define what DevRel is. As you say, we mostly define what DevRel is not, and that puts us in a weird position where companies see other companies do DevRel, and they mostly pay attention to the ones who do DevRel really well. And they or their investors or other companies say, “You need a great DevRel program. This is the secret to growth.” Because we look at companies that have done it effectively, and we see their growth, and we say, “Clearly this has a strong correlation. We should invest in this.” But they don't—they haven't done it themselves. They don't understand which part of it is that works, so they just say, “We're hiring for DevRel.” The job description is nine different careers in a trench coat. And the people applying—Corey: Oh, absolutely. It's nine different things and people wind up subdividing into it, like, “I'm an events planner. I'm not a content writer.”Jason: Right.Corey: Okay, great, but then why not bill yourself as a con—as an events planner, and not have to wear the DevRel cloak?Jason: Exactly. And this is sort of what I've seen is that when you put up a DevRel job, they list everything, and then when you apply for a DevRel job, you also don't want to paint yourself into a corner and say, “My specialty is content,” or, “My specialty is public speaking,” or whatever it is. And therefore you say, “I do DevRel,” to give yourself more latitude as an employee. Which obviously I want to keep optionality anywhere I go. I would like to be able to evolve without being painted into a small box of, like, this is all I'm allowed to do, but it does put us in this really precarious position.And what I've noticed a lot of companies do is they hire DevRel—undefined, poorly written job description, poor understanding of the field. They get a DevRel who has a completely different understanding of what DevRel is compared to the people with the role open. Both of them think they're doing DevRel, they completely disagree on what those fundamentals are, and it leads to a mismatch, to burnout, to frustration, to, you know, this high turnover rate in this field. And everybody then starts to say, well, “DevRel is the problem.” But really, the problem is that we're not—we're defining a category, not a job, and I think that's the part that we really screwed up as an industry.Corey: Yeah. I wish there were a better way around there, but I don't know what that might be. Because it requires getting a bunch of people to change some cornerstone of what's become their identity.Jason: This is the part where I—this is probably my spiciest take, but I think that DevRel is marketing, but it is a different kind of marketing. And so, in a perfect world—like, where things start to fall apart is you try to slot DevRel into engineering, or you try to slot it into marketing, as a team on these broader organizations, but the challenge then becomes, if you have DevRel, in marketing, it will inevitably push more toward marketing goals, enterprise goals, top-of-funnel, qualified leads, et cetera. If you put them into engineering, then they have more engineering goals. They want to do developer experience reviews. They want to get out there and do demos. You know, it's much more engineering-focused—or if you're doing it right, is much more engineering-focused.But the best DevRel teams are doing both of those with a really good measure, and really clear metrics that don't line up with engineering or marketing. So, in a perfect world, you would just have an enterprise marketing team, and a developer marketing team, and that developer marketing team would be an organization that is DevRel today. And you would hire specialists—event planners, great speakers, great demo writers, probably put your docs team in there—and treat it as an actual responsibility that requires a larger team than just three or four ex-developers who are now speaking at conferences.Corey: There were massive layoffs across DevRel when the current macroeconomic correction hit, and I'd been worried about it for years in advance because—Jason: Mm-hm.Corey: So, many of these folks spent so much time talking about how they were not marketing, they were absolutely not involved in that. But marketing is the only department that really knows how to describe the value of these sorts of things without having hard metrics tied to it. DevRel spent a lot of time talking about how every metric used to measure them was somehow wrong, and if you took it to its logical conclusion, you would basically give these people a bunch of money—because they are expensive—and about that much money again in annual budget to travel more or less anywhere they want to go, and every time something good happened, as a result, to the company, they had some hand in it nebulously, but you could never do anything to measure their performance, so just trust that they're doing a good job. This is tremendously untenable.Jason: Mm-hm. Yeah, I think when I was running the developer experience org at Netlify, most of my meetings were justifying the existence of the team because there weren't good metrics. You can't put sales qualified leads on DevRel. It doesn't make any sense because there are too many links in the chain after DevRel opens the door, where somebody has to go from, ‘I'm aware of this company' to ‘I've interacted with the landing page' to ‘I've actually signed up for something' to ‘now I'm a customer,' before you can get them to a lead. And so, to have DevRel take credit is actually removing credit from the marketing team.And similarly, if somebody goes through onboarding, a lot of that onboarding can be guided by DevRel. The APIs that new developers interface with can be—the feedback can come from DevRel, but ultimately, the engineering team did that work the product team did that work. So, DevRel is this very interesting thing. I've described it as a turbocharger, where if you put it on an engine that runs well, you get better performance out of that engine. If you just plop one on the table, not a lot happens.Corey: Yeah, it's a good way of putting it. I see very early stage startups looking to hire a developer advocate or DevRel person in their seed stage or Series A, and it's… there's something else you're looking for here. Hire that instead. You're putting the cart before the horse.Jason: What a lot of people saw is they saw—what they're thinking of as DevRel is what they saw from very public founders. And when you get a company that's got this very public-facing, very engaging, charismatic founder, that's what DevRel feels like. It is, you know, this is the face of the company, we're showing you what we do on the inside, we're exposing our process, we're sharing the behind the scenes, and proving to you that we really are great engineers, and we care a lot. Look at all this cool stuff we're doing. And that founder up on stage was, I think, the original DevRel.That's what we used to love about conferences is we would go there and we would see somebody showing this thing they invented, or this new product they had built, and it felt so cool because it was these inspirational moments of watching somebody brilliant do something brilliant. And you got to follow along for that journey. And then we try to—Corey: Yeah I mean, that's natural, but you see booths at conferences, the small company startup booths, a lot of times you'll be able to talk to the founders directly. As the booths get bigger, your likelihood of being able to spend time talking to anyone who's materially involved in the strategic direction of that company gets smaller and smaller. Like, the CEO of GitHub isn't going to be sitting around at the GitHub booth at re:Invent. They're going to be, you know, talking to other folks—if they're there—and going to meetings and whatnot. And then you wind up with this larger and larger company. It's a sign of success, truly, but it also means that you've lost something along the way.Jason: Yeah, I think, you know, it's the perils of scale. And I think that when you start looking at the function of DevRel, it should sort of be looked at as, like, when we can't handle this anymore by ourselves, we should look for a specialty the same way that you do for any other function inside of a company. You know, it wouldn't make sense on day one of a startup to hire a reliability engineer. You're not at the point where that makes sense. It's a very expensive person to hire, and you don't have enough product or community or load to justify that role yet. And hopefully, you will.And I think DevRel is sort of the same way. Like, when you first start out your company, your DevRel should be the founding team. It should be your engineers, sharing the things that they're building so that the community can see the brilliance of your engineering team, sharing with the community, obviously, being invested in that community. And when you get big enough that those folks can no longer manage that and their day-to-day work, great, then look into adding specialists. But I think you're right that it's cart before the horse to, you know, make a DevRel your day-one hire. You just don't have enough yet.Corey: Yeah, I wish that there were an easy way to skin the cat. I'm not sure there is. I think instead we wind up with people doing what they think is going to work. But I don't know what the truth is.Jason: Mmm.Corey: At least. That's where I land on it.Jason: [laugh] Yeah, I mean, every company is unique, and every experience is going to be unique, so I think to say, “Do it exactly like this,” is—that's got a lot of survivorship bias, and do as I say—but at the same time, I do think there's some universal truths. Like, it doesn't really make sense to hire a specialist before you've proven that specialty is the secret sauce of your business. And I think you grow when it's time to grow, not just in case. I think companies that over-hire end up doing some pretty painful layoffs down the road. And, you know, obviously, there's an opposite end of that spectrum where you can grow too slowly and bury your team and burn everybody out, but I think, you know—we, [laugh] leading into the pandemic, I guess, we had a lot of free money, and I think people were thinking, let's go build an empire and we'll grow into that empire. And I think that is a lot of why we're seeing this really painful downsizing right now, is companies hired just in case and then realized that actually, that in case didn't come to be.Corey: What is the future of this look like? Easy enough to look back and say, well, that didn't work? Well, sure. What is the future?Jason: The playbook that we saw before—in, like, 2019 and before—was very event-driven, very, like, webinar-driven. And as we went into 2020, and people were at home, we couldn't travel, we got real sick of Zoom calls. We don't want to get on another video call again. And that led to that playbook not working anymore. You know, I don't want to get on a webinar with a company. I don't want to go travel to a company event, you know, or at least not very many of them. I want to go see the friends I haven't seen in three years.So, travel priorities changed, video call fatigue is huge, so we need something that people want to do, that is interesting, and that is, you know, it's worth making in its own right, so that people will engage with it, and then you work in the company goals as an incidental. Not as a minor incidental, but you know, it's got to be part of the story; it can't be the purpose. People won't sign up for a webinar willingly these days, I don't think, unless they have exactly the problem that your webinar purports to solve.Corey: And even if they do, it becomes a different story.Jason: Right.Corey: It's [high buying 00:19:03] signal, but people are constantly besieged by requests for attention. This is complicated by what I've seen over the last year. When marketing budgets get—cut, arguably too much, but okay—you see now that there's this follow-on approach where, okay, what are we going to cut? And people cut things that in many cases work, but are harder to attribute success to. Events, for example, are doing very well because you have someone show up at your booth, you scan their badge. Three weeks later, someone from that company winds up signing up for a trial or whatnot, and ah, I can connect those dots.Whereas you advertise on I don't know, a podcast as a hypothetical example that I'm pulling out of what's right in front of me, and someone listening to this and hearing a message from a sponsor, they might be doing something else. They'll be driving, washing dishes, et cetera, and at best they'll think, “Okay, I should Google that when I get back to a computer.” And they start hearing about it a few times, and, “Oh. Okay, now it's time for me to go and start paying serious attention to this because that sounds like it aligns with a problem I have.” They're not going to remember where they initially heard it.They're going to come in off of a Google search, so it sounds like it's all SEO's benefit that this is working, and it is impossible to attribute. I heard some marketer once say that 50% of your marketing budget is wasted, but you'll go bankrupt trying to figure out which half. It all ties together. But I can definitely see why people bias for things that are more easily attributed to the metric you care about.Jason: Yes. And I think that this is where I see the biggest opportunity because I think that we have to embrace that marketing signal is directional, not directly attributable. And if you have a focus campaign, you can see your deviation from baseline signups, and general awareness, and all of the things that you want to be true, but you have to be measuring that thing, right? So, if we launch a campaign where we're going to do some video ads, or we're going to do some other kind of awareness thing, the goal is brand awareness, and you measure that through, like, does your name get mentioned on social media? Do you see a deviation from baseline signups where it is trending upward?And each of those things is signal that the thing you did worked. Can you directly attribute it? No, but I think a functional team can—you know, we did this at Netlify all the time where we would go and look: what were the efforts that were made, what were the ones that got discussion on different social media platforms, and what was the change from baseline? And we saw certain things always drove a non-trivial deviation from baseline in the right direction. And that's one of the reasons that I think the future of this is going to be around how do you go broader with your reach?And my big idea—to nutshell it—is, like, dev TV. I think that developers want to see the things that they're interested in, but they want it to be more interesting than a straight webinar. They want to see other developers using tools and getting a sense of what's possible in an entertaining way. Like, they want stories, they don't want straight demos. So, my thinking here is, let's take this and steer into it.Like, we know that developers love when you put a documentary together. We saw the Vue documentary, and the React documentary, and the GraphQL documentary, and the Kubernetes documentary coming out of the Honeypot team, and they've got hundreds of thousands, and in some cases, millions of views because developers really want to see good stories about us, about our community. So, why not give the dev community a Great British Bake Off, but for web devs? Why not create an Anthony Bourdain Parts Unknown-style travel show that highlights various web communities? Why not get out there and make reality competition shows and little docuseries that help us highlight all the things that we're learning and sharing and building?Every single one of those is going to involve developers talking about the tools they use, talking about the problems they solve, talking about what they were doing before and how they've made it better. That's exactly what a webinar is, that's what a conference talk is, but instead of getting a small audience at a conference, or you know, 15 to 30 people signing up for your webinar, now we've got the potential for hundreds of thousands or even millions of people to watch this thing because it's fun to watch. And then they become aware of the companies involved because it's presented by the company; they see the thing get used or talked about by developers in their community, I think there's a lot of magic and potential in that, and we've seen it work in other verticals.Corey: And part of the problem comes down as well to the idea that, okay, you're going to reach some people in person at events, but the majority of engineers are not going to be at any event or—Jason: Right.Corey: Any event at all, for that matter. They just don't go to events for a variety of excellent reasons. How do you reach out to them? Video can work, but I always find that requires a bit of a different skill than, I don't know, podcasting or writing a newsletter. So, many times, it feels like it's, oh, and now you're just going to basically stare at the camera, maybe with someone else, and it looks like the Zoom call to which the viewer is not invited.Jason: Right.Corey: They get enough of that. There has to be something else.Jason: And I think this is where the new skill set, I think, is going to come in. It exists in other places. We see this happen in a lot of other industries, where they have in-house production teams, they're doing collaborations with actors and athletes and bringing people in to make really entertaining stories that drive underlying narratives. I mean, there's the ones that are really obvious, like, the Nikes of the world, but then there are far less obvious examples.Like, there was this show called Making It. It was… Nick Offerman and Amy Poehler were the hosts. It was the same format as the Great British Bake Off but around DIY and crafting. And one of the permanent judges was the Etsy trend expert, right? And so, every single episode, as they're judging this, the Etsy trend expert is telling all of these crafters and contestants, “You know, what you built here is always a top seller on Etsy. This is such a good idea, it's so well executed, and people love this stuff. It flies off the shelves in Etsy stores.”Every single episode, just perfectly natural product placement, where a celebrity that you know—Nick Offerman and Amy Poehler—are up there, lending—like, you want to see them. They're so funny and engaging, and then you've got the credibility of Etsy's trend expert telling the contestants of the show, “If you do DIY and crafting, you can make a great living on Etsy. Here are the things that will make that possible.” It's such subtle, but brilliant product placement throughout the entire thing. We can do that. Like, we have the money, we just spend it in weird places.And I think that as an industry, if we start getting more creative about this and thinking about different ways we can apply these marketing dollars that we're currently dumping into very expensive partner dinners or billboards or getting, you know, custom swag or funding yet another $150,000 conference sponsorship, we could make a series of a TV show for the same cost as throwing one community event, and we would reach a significantly larger group.Corey: Yeah. Now, there is the other side of it, too, where Lord knows I found this one out the fun way, that creating content requires significant effort and—Jason: Yes.Corey: Focus. And, “Oh, it's a five-minute video. Great, that could take a day or three to wind up putting together, done right.” One of the hardest weeks of my year is putting together a bunch of five-minute videos throughout the course of re:Invent. So much that is done in advance that is basically breaking the backs of the editing team, who are phenomenal, but it still turns into more than that, where you still have this other piece of it of the actual content creation part.And you can't spend all your time on that because pretty soon I feel like you become a talking head who doesn't really do the things that you are talking to the world about. And that content gets pretty easy to see when you start looking at, okay, what did someone actually do? Oh, they were a developer for three years, and they spent the next seven complaining about development, and how everyone is—Jason: [laugh].Corey: Doing it wrong on YouTube. Hmm… it starts to get a little, how accurate is this really? So, for me, it was always critical that I still be hands-on with things that I'm talking about because otherwise I become a disaster.Jason: And I agree. One of the things that my predecessor at Netlify, Sarah Drasner, put in place was a, what she called an exchange program, where we would rotate the DevRel team onto product, and we rotate product onto the DevRel team. And it was a way of keeping the developer experience engineers actually engineers. They would work on the product, they didn't do any DevRel work, they were exclusively focused on doing actual engineering work inside our product to just help keep their skills sharp, keep them up to date on what's going on, build more empathy for the engineers that we talk to every day, build more empathy for our team instead of us—you know, you never want to hear a DevRel throw the engineering team under the bus for not shipping a feature everybody wants.So, these sorts of things are really important, and they're hard to do because we had to—you know, that's a lot of negotiation to say, “Hey, can we take one of your engineers for a quarter, and we'll give you one of our engineers for a quarter, and you got to trust us that's going to work out in your favor.” [laugh] Right? Like, there's a lot that goes into this to make that sort of stuff possible. But I absolutely agree. I don't think you get to make this type of content if you've fully stepped out of engineering. You have to keep it part of your practice.Corey: There's no way around it. You have to be hands-on. I think that's the right way to do it, otherwise, it just leads to, frankly, disaster. Very often, you'll see people who are, like, “Oh, they're great in the DevRel space. What do they do?” And they go to two or three conferences a year, and they have a blog post or so. It's like, okay, what are they doing the rest of that time?Sometimes the answer is fighting internal political fires. Other times it's building things and learning these things and figuring out where they stand. There are some people, I don't want to name names, although an easy one is Kelsey Hightower, who has since really left the stage, that he's retired, but when he went up on stage and said something—despite the fact that he worked at Google—it was eminently clear that he believed in what he was saying, or he would not say it.Jason: Right.Corey: He was someone who was very clearly aware of the technology about which he was speaking. And that was great. I wish that it were not such a standout moment to see him speak and talk about that. But unfortunately, he kind of is. Not as many people do that as well as we'd like.Jason: Agreed. I think it was always a treat to see Kelsey speak. And there are several others that I can think of in the community who, when they get on stage, you want to be in that audience, and you want to sit down and listen. And then there are a lot of others who when they get on stage, it's like that this book could have been a blog post, or this—you know, this could have been an email, that kind of thing. Like you could have sent me this repo because all you did was walk through this repo line-by-line, or something that—it doesn't feel like it came from them; it feels like it's being communicated by them.And I think that's, again, like, when I criticize conferences, a lot of my criticism comes from the fact that, coming up, I feel like every speaker that I saw on stage—and this is maybe just memory… playing favorites for me, but I feel like I saw a lot of people on stage who were genuinely passionate about what they were creating, and they were genuinely putting something new into the world every time they got on stage. And I have noticed that I feel less and less like that. Also, I feel like events have gotten less and less likely to put somebody on stage unless they've got a big name DevRel title. Like, you have to work at a company that somebody's heard of because they're all trying to get that draw because attendance is going down. And—Corey: Right. It's a—like, having run some conferences myself, the trick is, is you definitely want some ringers in there. People you know will do well, but you also need to give space for new voices to arise. And sometimes it's a—it always bugs me when it seems like, oh, they're here because their company is a big sponsor. Of course, they have the keynote. Other times, it's a… like, hate the actual shill talks, which I don't see as much, which I'm thankful for; I'd stop going to those conferences, but jeez.Jason: Yeah, and I think it's definitely one of those, like, this is a thing that we can choose to correct. And I have a suspicion that this is a pendulum not a—not, like, the denouement of—is that the right—how do you say that word? De-NOW-ment? De-NEW-ment? Whatever.Corey: Denouement is my understanding, but that might be the French acc—Jason: Oh, me just—Corey: The French element.Jason: —absolutely butchering that. Yeah [laugh]. I don't think this is the end of conferences, like we're seeing them taper into oblivion. I think this is a lull. I think that we're going to realize that we want to—we really do love being in a place with other developers. I want to do that. I love that.But we need to get back to why we were excited to go to conferences in the first place, which was this sharing of knowledge and inspiration, where you would go see people who were literally moving the world forward in development, and creating new things so that you would walk away with insider info, you had just seen the new thing, up close and personal, had those conversations, and you went back so jazzed to build something new. I feel like these days, I feel more like I went and watched a handful of product demos, and now I'm really just waiting to the hallway track, which is the only, like, actually interesting part at a lot of events these days.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you?Jason: Most of what I share is on learnwithjason.dev, or if you want a big list of links, I have jason.energy/links, which has a whole bunch of fun stuff for you to find.Corey: Awesome. And we will, of course, include links to that in the show notes. Thank you so much for taking the time to speak with me. I really appreciate it.Jason: Yeah, thanks so much for having me. This was a blast.Corey: Jason Lengstorf, developer media producer at Learn with Jason. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that will no doubt become the basis for somebody's conference talk.Jason: [laugh].Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

In this special episode we wrapped up the year 2023 with none other than the cloud-native maestro, Kelsey Hightower! We looked into the highs and lows of the tech landscape, exploring Kelsey's insights on containerization and beyond. Tune in as we unravel the year that was and reflect on what lies ahead for Kubernetes and cloud computing. Kelsey has been there since the birth of Kubernetes, with his contributions to the project as well as his advocacy for containers and cloud native tech and concepts. Join us to conclude 2023 with a look above the clouds. The episode was live-streamed on 5 December 2023 and the video is available at https://www.youtube.com/watch?v=OVSIUMJxtLk OpenObservability Talks episodes are released monthly, on the last Thursday of each month and are available for listening on your favorite podcast app and on YouTube. We live-stream the episodes on Twitch and YouTube Live - tune in to see us live, and chime in with your comments and questions on the live chat. https://www.twitch.tv/openobservability https://www.youtube.com/@openobservabilitytalks   Show Notes: 00:00 - Show intro 01:00 - Episode and guest intro 02:40 - Highlights of 2023, signs of maturity 05:17 - Standardizing on cloud bills 12:09 - Consensus vs. innovation in tech 14:46 - Evolution of OpenTelemetry and telemetry signals 19:33 - Where AI will help DevOps and Observability 25:44 - Where is Kubernetes heading in the coming decade 32:42 - Can Kubernetes serve AI/ML workloads 40:37 - CNCF landscape - transparency vs. complexity 49:05 - Evolution of observability 59:03 - Episode and show outro Resources: Standardizing on cloud bills with FOCUS open specification: https://horovits.medium.com/6e30069f33a0 How to fix Kubernetes monitoring: https://thenewstack.io/how-to-fix-kubernetes-monitoring/ Socials: Twitter:⁠ https://twitter.com/OpenObserv⁠ YouTube: ⁠https://www.youtube.com/@openobservabilitytalks⁠

We are thrilled to unveil the captivating episode "Up Close with Black Excellence" featuring the remarkable Kelsey Hightower!

Today's guest is Kelsey Hightower, a distinguished engineer and developer advocate at Google and speaker known for his work with Kubernetes, open source software and cloud computing.As a curious and motivated self-learner, Kelsey dropped out of College and taught himself the skills required to start his career as an independent contractor for BellSouth – a telecoms company in Atlanta helping the community to get online. From there, Kelsey set up his own business – an electronics store before becoming involved in the open source world, working at New Relic, CoreOS, Puppet Labs, and most recently at Google.A self-taught developer, Kelsey's work on Kubernetes and at Google, from which he just retired, is well-known* so I wanted to focus our conversation on his life - how he got into tech, his love of learning, what drives him, what it means to be hopeful and the one piece of advice he would offer a younger Kelsey.I know I am not meant to have favourites – these conversations are like children - but I have to say this is up there with one of my most loved conversations. I learned so much from Kelsey and I think you will too.Enjoy!Kelsey on TwitterDanielle Twitter / Instagram / NewsletterPhoto of Kelsey is part of the Faces of Open Source Project by Peter Adams*If you want to learn more about Kelsey's work history, give this episode  from Ardan Labs a listen.

“If you gain any expertise in any field of life, the best thing you can do is translate it so the other person understands it too.” - Kelsey Hightower In this insightful episode of Real Talk, we are joined by Kelsey Hightower, a technology leader, innovator, and captivating storyteller. Kelsey, with his unique experiences, seamlessly intertwines tech, philosophy, and the transformative power of stories and skills. Join us as he shares his unique perspectives, personal anecdotes, and invaluable insights that challenge convention. Key moments from this episode: The domino effect of learning: Kelsey underscores the transformative power of skills, emphasizing how they can pave the way to acquiring more, which not only bolsters your professional growth but also enhances problem-solving and adaptability in diverse areas of your life. Open source and the evolution of education: by highlighting the parallels between the decentralized, collaborative ethos of open source and the emerging education paradigm, Kelsey discusses how people from all walks of life are empowered to both learn and teach, reinforcing the idea that continued, self-driven education is the cornerstone of modern learning. Redefining wealth beyond currency: Kelsey profoundly reimagines the traditional understanding of wealth, placing significant emphasis on the acquisition of skills. Learning from falls: embedded within temporary failures are profound lessons, and Kelsey challenges us to view setbacks as growth opportunities. The power of now: living in the present moment and valuing consistent efforts over arbitrary outcomes are key to navigating life's unpredictable nature. Authoring your future: Kelsey's journey from openly declaring his keynote speaking intentions to the world, to realizing them, spotlights the power of self-belief and proactive action. Kelsey Hightower's blend of tech expertise, passion for collaboration and evolving education, and rich life experiences offer us an enlightening journey through this episode. His stories resonate with anyone looking to break boundaries, learn continually, and find joy in the journey of life and work! Make sure to share this episode with someone in your inner circle! With so much love & gratitude, Grace

Ashley Williams and Adam Jacob joined Adam and Bryan to continue their panel discussion with Bryan following up his p99conf talk revisiting open source anti-patterns. Notably, open source has accelerated the distribution of value… without clarity on how contributors can capture that value. Has open source accelerated unequal distribution?In addition to Bryan Cantrill and Adam Leventhal, we were joined by friends of the show Ashley Williams and Adam Jacob.Some of the topics we hit on, in the order that we hit them: Bryan's Talk, Corporate Open Source Anti-Patterns: A Decade Later by Bryan Cantrill, Oxide Subsequent panel with Adam J. and Ashley Oxide and Friends: Open Source Anti-Patterns with Kelsey Hightower from August 28th, 2023 Oxide and Friends: Docker, Inc., an Early Epitaph from September 13th, 2021 If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!

This episode features Kelsey Hightower for a discussion across numerous topics. In this special edition, Kelsey is interviewed by HarperDB's Co-Founder, Stephen Goldberg. Questions covered include:How did it feel to retire from Google this year, what's next?You have, what some would consider, a non-traditional background when it comes to the software engineering world. How has that shaped your view on the industry? How do you think the industry performs at mentoring/cultivating young engineers, including those from non-CS degree backgrounds?What are your thoughts on where distributed vs. monolithic architecture is going? How is “Edge Computing” impacted by this?There has been a focus in the cloud provider space of bringing on new locations, trying to put infrastructure in hard to reach places. Eventually this will reach a saturation point, where do you think they will invest next?When thinking about building platforms and products, what is your advice on how to make a decision to internalize automation within your product vs. using a framework?What are your opinions on running a stateful application that must have data consistency across its replicas, such as a database, on Kubernetes? It comes with a bunch of problems to solve, like auto scaling, data redundancy and replication. It seems that the community is split on whether or not this is a good idea and how to implement it.What advice would you give yourself 20 years ago?Kelsey Hightower is an American software engineer, developer advocate, and speaker known for his work with Kubernetes, open-source software, and cloud computing.

Kelsey Hightower joins Corey on Screaming in the Cloud to discuss his reflections on how the tech industry is progressing. Kelsey describes what he's been getting out of retirement so far, and reflects on what he learned throughout his high-profile career - including why feature sprawl is such a driving force behind the complexity of the cloud environment and the tactics he used to create demos that are engaging for the audience. Corey and Kelsey also discuss the importance of remaining authentic throughout your career, and what it means to truly have an authentic voice in tech. About KelseyKelsey Hightower is a former Distinguished Engineer at Google Cloud, the co-chair of KubeCon, the world's premier Kubernetes conference, and an open source enthusiast. He's also the co-author of Kubernetes Up & Running: Dive into the Future of Infrastructure. Recently, Kelsey announced his retirement after a 25-year career in tech.Links Referenced:Twitter: https://twitter.com/kelseyhightower TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Do you wish there were cheat codes for database optimization? Well, there are – no seriously. If you're using Postgres or MySQL on Amazon Aurora or RDS, OtterTune uses AI to automatically optimize your knobs and indexes and queries and other bits and bobs in databases. OtterTune applies optimal settings and recommendations in the background or surfaces them to you and allows you to do it. The best part is that there's no cost to try it. Get a free, thirty-day trial to take it for a test drive. Go to ottertune dot com to learn more. That's O-T-T-E-R-T-U-N-E dot com.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. You know, there's a great story from the Bible or Torah—Old Testament, regardless—that I was always a big fan of where you wind up with the Israelites walking the desert for 40 years in order to figure out what comes next. And Moses led them but could never enter into what came next. Honestly, I feel like my entire life is sort of going to be that direction. Not the biblical aspects, but rather always wondering what's on the other side of a door that I can never cross, and that door is retirement. Today I'm having returning guest Kelsey Hightower, who is no longer at Google. In fact, is no longer working and has joined the ranks of the gloriously retired. Welcome back, and what's it like?Kelsey: I'm happy to be here. I think retirement is just like work in some ways: you have to learn how to do it. A lot of people have no practice in their adult life what to do with all of their time. We have small dabs in it, like, you get the weekend off, depending on what your work, but you never have enough time to kind of unwind and get into something else. So, I'm being honest with myself. It's going to be a learning curve, what to do with that much time.You're probably still going to do work, but it's going to be a different type of work than you're used to. And so, that's where I am. 30 days into this, I'm in that learning mode, I'm on-the-job training.Corey: What's harder than you expected?Kelsey: It's not the hard part because I think mentally I've been preparing for, like, the last ten years, being a minimalist, learning how to kind of live within my means, learn to appreciate things that are just not work-related or status symbols. And so, to me, it felt like a smooth transition because I started to value my time more than anything else, right? Just waking up the next day became valuable to me. Spending time in the moment, right, you go to these conferences, there's, like, 10,000 people, but you learn to value those one-on-one encounters, those one-off, kind of, let's just go grab lunch situations. So, to me, retirement just makes more room for that, right? I no longer have this calendar that is super full, so I think for me, it was a nice transition in terms of getting more of that valuable time back.Corey: It seems to me that you're in a similar position to the one that I find myself in where the job that you were doing and I still am is tied, more or less, to a sense of identity as opposed to a particular task or particular role that you fill. You were Kelsey Hightower. That was a complete sentence. People didn't necessarily need to hear the rest of what you were working on or what you were going to be talking about at a given conference or whatnot. So, it seemed, at least from the outside, that an awful lot of what you did was quite simply who you were. Do you feel that your sense of identity has changed?Kelsey: So, I think when you have that much influence, when you have that much reputation, the words you say travel further, they tend to come with a little bit more respect, and so when you're working with a team on new product, and you say, “Hey, I think we should change some things.” And when they hear those words coming from someone that they trust or has a name that is attached to reputation, you tend to be able to make a lot of impact with very few words. But what you also find is that no matter what you get involved in—configuration management, distributed systems, serverless, working with customers—it all is helped and aided by the reputation that you bring into that line of work. And so yes, who you are matters, but one thing that I think helped me, kind of greatly, people are paying attention maybe to the last eight years of my career: containers, Kubernetes, but my career stretches back to the converting COBOL into Python days; the dawn of DevOps, Puppet, Chef, and Ansible; the Golang appearance and every tool being rewritten from Ruby to Golang; the Docker era.And so, my identity has stayed with me throughout those transitions. And so, it was very easy for me to walk away from that thing because I've done it three or four times before in the past, so I know who I am. I've never had, like, a Twitter bio that said, “Company X. X person from company X.” I've learned long ago to just decouple who I am from my current employer because that is always subject to change.Corey: I was fortunate enough to not find myself in the public eye until I owned my own company. But I definitely remember times in my previous incarnations where I was, “Oh, today I'm working at this company,” and I believed—usually inaccurately—that this was it. This was where I really found my niche. And then surprise I'm not there anymore six months later for, either their decision, my decision, or mutual agreement. And I was always hesitant about hanging a shingle out that was tied too tightly to any one employer.Even now, I was little worried about doing it when I went independent, just because well, what if it doesn't work? Well, what if, on some level? I think that there's an authenticity that you can bring with you—and you certainly have—where, for a long time now, whenever you say something, I take it seriously, and a lot of people do. It's not that you're unassailably correct, but I've never known you to say something you did not authentically believe in. And that is an opinion that is very broadly shared in this industry. So, if nothing else, you definitely were a terrific object lesson in speaking the truth, as you saw it.Kelsey: I think what you describe is one way that, whether you're an engineer doing QA, working in the sales department, when you can be honest with the team you're working with, when you can be honest with the customers you're selling into when you can be honest with the community you're part of, that's where the authenticity gets built, right? Companies, sometimes on the surface, you believe that they just want you to walk the party line, you know, they give you the lines and you just read them verbatim and you're doing your part. To be honest, you can do that with the website. You can do that with a well-placed ad in the search queries.What people are actually looking for are real people with real experiences, sharing not just fact, but I think when you mix kind of fact and opinion, you get this level of authenticity that you can't get just by pure strategic marketing. And so, having that leverage, I remember back in the day, people used to say, “I'm going to do the right thing and if it gets me fired, then that's just the way it's going to be. I don't want to go around doing the wrong thing because I'm scared I'm going to lose my job.” You want to find yourself in that situation where doing the right thing, is also the best thing for the company, and that's very rare, so when I've either had that opportunity or I've tried to create that opportunity and move from there.Corey: It resonates and it shows. I have never had a lot of respect for people who effectively are saying one thing today and another thing the next week based upon which way they think that the winds are blowing. But there's also something to be said for being able and willing to publicly recant things you have said previously as technology evolves, as your perspective evolves and, in light of new information, I'm now going to change my perspective on something. I've done that already with multi-cloud, for example. I thought it was ridiculous when I heard about it. But there are also expressions of it that basically every company is using, including my own. And it's a nuanced area. Where I find it challenging is when you see a lot of these perspectives that people are espousing that just so happen to deeply align with where their paycheck comes from any given week. That doesn't ring quite as true to me.Kelsey: Yeah, most companies actually don't know how to deal with it either. And now there has been times at any number of companies where my authentic opinion that I put out there is against party line. And you get those emails from directors and VPs. Like, “Hey, I thought we all agree to think this way or to at least say this.” And that's where you have to kind of have that moment of clarity and say, “Listen, that is undeniably wrong. It's so wrong in fact that if you say this in public, whether a small setting or large setting, you are going to instantly lose credibility going forward for yourself. Forget the company for a moment. There's going to be a situation where you will no longer be effective in your job because all of your authenticity is now gone. And so, what I'm trying to do and tell you is don't do that. You're better off saying nothing.”But if you go out there, and you're telling what is obviously misinformation or isn't accurate, people are not dumb. They're going to see through it and you will be classified as a person not to listen to. And so, I think a lot of people struggle with that because they believe that enterprise's consensus should also be theirs.Corey: An argument that I made—we'll call it a prediction—four-and-a-half years ago, was that in five years, nobody would really care about Kubernetes. And people misunderstood that initially, and I've clarified since repeatedly that I'm not suggesting it's going away: “Oh, turns out that was just a ridiculous fever dream and we're all going back to running bare metal with our hands again,” but rather that it would slip below the surface-level of awareness. And I don't know that I got the timing quite right on that, I think it's going to depend on the company and the culture that you find yourself in. But increasingly, when there's an application to run, it's easy to ask someone just, “Oh, great. Where's the Kubernetes cluster live so we can throw this on there and just add it to the rest of the pile?”That is sort of what I was seeing. My intention with that was not purely just to be controversial, as much fun as that might be, but also to act as a bit of a warning, where I've known too many people who let their identities become inextricably tangled with the technology. But technologies rise and fall, and at some point—like, you talk about configuration management days; I learned to speak publicly as a traveling trainer for Puppet. I wrote part of SaltStack once upon a time. But it was clear that that was not the direction the industry was going, so it was time to find something else to focus on. And I fear for people who don't keep an awareness or their feet underneath them and pay attention to broader market trends.Kelsey: Yeah, I think whenever I was personally caught up in linking my identity to technology, like, “I'm a Rubyist,” right?“, I'm a Puppeteer,” and you wear those names proudly. But I remember just thinking to myself, like, “You have to take a step back. What's more important, you or the technology?” And at some point, I realized, like, it's me, that is more important, right? Like, my independent thinking on this, my independent experience with this is far more important than the success of this thing.But also, I think there's a component there. Like when you talked about Kubernetes, you know, maybe being less relevant in five years, there's two things there. One is the success of all infrastructure things equals irrelevancy. When flights don't crash, when bridges just work, you do not think about them. You just use them because they're so stable and they become very boring. That is the success criteria.Corey: Utilities. No one's wondering if the faucet's going to work when they turn it on in the morning.Kelsey: Yeah. So, you know, there's a couple of ways to look at your statement. One is, you believe Kubernetes is on the trajectory that it's going to stabilize itself and hit that success criteria, and then it will be irrelevant. Or there's another part of the irrelevancy where something else comes along and replaces that thing, right? I think Cloud Foundry and Mesos are two good examples of Kubernetes coming along and stealing all of the attention from that because those particular products never gained that mass adoption. Maybe they got to the stable part, but they never got to the mass adoption part. So, I think when it comes to infrastructure, it's going to be irrelevant. It's just what side of that [laugh] coin do you land on?Corey: It's similar to folks who used to have to work at a variety of different companies on very specific Linux kernel subsystems because everyone had to care because there were significant performance impacts. Time went on and now there's still a few of those people that very much need to care, but for the rest of us, it is below the level of things that we have to care about. For me, the signs of the unsustainability were, oh, you can run Kubernetes effectively in production? That's a minimum of a quarter-million dollars a year in comp or up in some cases. Not every company is going to be able to field a team of those people and still remain a going concern in business. Nor frankly, should they have to.Kelsey: I'm going to pull on that thread a little bit because it's about—we're hitting that ten-year mark of Kubernetes. So, when Kubernetes comes out, why were people drawn to it, right? Why did it even get the time of day to begin with? And I think Docker kind of opened Pandora's box there. This idea of Chef, Puppet, Ansible, ten thousand package managers, and honestly, that trajectory was going to continue forever and it was helping no one. It was literally people doing duplicate work depending on the operating system you're dealing with and we were wasting time copying bits to servers—literally—in a very glorified way.So, Docker comes along and gives us this nicer, better abstraction, but it has gaps. It has no orchestration. It's literally this thing where now we've unified the packaging situation, we've learned a lot from Red Hat, YUM, Debian, and the various package repo combinations out there and so we made this universal thing. Great. We also learned a little bit about orchestration through brute force, bash scripts, config management, you name it, and so we serialized that all into this thing we call Kubernetes.It's pretty simple on the surface, but it was probably never worthy of such fanfare, right? But I think a lot of people were relieved that now we finally commoditized this expertise that the Googles, the Facebooks of the world had, right, building these systems that can copy bits to other systems very fast. There you go. We've gotten that piece. But I think what the market actually wants is in the mobile space, if you want to ship software to 300 million people that you don't even know, you can do it with the app store.There's this appetite that the boring stuff should be easy. Let's Encrypt has made SSL certificates beyond easy. It's just so easy to do the right thing. And I think for this problem we call deployments—you know, shipping apps around—at some point we have to get to a point where that is just crazy easy. And it still isn't.So, I think some of the frustration people express ten years later, they're realizing that they're trying to recreate a Rube Goldberg machine with Kubernetes is the base element and we still haven't understood that this whole thing needs to simplify, not ten thousand new pieces so you can build your own adventure.Corey: It's the idea almost of what I'm seeing AWS go through, and to some extent, its large competitors. But building anything on top of AWS from scratch these days is still reminiscent of going to Home Depot—or any hardware store—and walking up and down the aisles and getting all the different components to piece together what you want. Sometimes just want to buy something from Target that's already assembled and you have to do all of that work. I'm not saying there isn't value to having a Home Depot down the street, but it's also not the panacea that solves for all use cases. An awful lot of customers just want to get the job done and I feel that if we cling too tightly to how things used to be, we lose it.Kelsey: I'm going to tell you, being in the cloud business for almost eight years, it's the customers that create this. Now, I'm not blaming the customer, but when you start dealing with thousands of customers with tons of money, you end up in a very different situation. You can have one customer willing to pay you a billion dollars a year and they will dictate things that apply to no one else. “We want this particular set of features that only we will use.” And for a billion bucks a year times ten years, it's probably worth from a business standpoint to add that feature.Now, do this times 500 customers, each major provider. What you end up with is a cloud console that is unbearable, right? Because they also want these things to be first-class citizens. There's always smaller companies trying to mimic larger peers in their segment that you just end up in that chaos machine of unbound features forever. I don't know how to stop it. Unless you really come out maybe more Apple style and you tell people, “This is the one and only true way to do things and if you don't like it, you have to go find an alternative.” The cloud business, I think, still deals with the, “If you have a large payment, we will build it.”Corey: I think that that is a perspective that is not appreciated until you've been in the position of watching how large enterprises really interact with each other. Because it's, “Well, what customer the world is asking for yet another way to run containers?” “Uh, this specific one and their constraints are valid.” Every time I think I've seen everything there is to see in the world of cloud, I just have to go talk to one more customer and I'm learning something new. It's inevitable.I just wish that there was a better way to explain some of this to newcomers, when they're looking at, “Oh, I'm going to learn how this cloud thing works. Oh, my stars, look at how many services there are.” And then they wind up getting lost with analysis paralysis, and every time they get started and ask someone for help, they're pushed in a completely different direction and you keep spinning your wheels getting told to start over time and time again when any of these things can be made to work. But getting there is often harder than it really should be.Kelsey: Yeah. I mean, I think a lot of people don't realize how far you can get with, like, three VMs, a load balancer, and Postgres. My guess is you can probably build pretty much any clone of any service we use today with at least 1 million customers. Most people never reached that level—I don't even want to say the word scale—but that blueprint is there and most people will probably be better served by that level of simplicity than trying to mimic the behaviors of large customers—or large companies—with these elaborate use cases. I don't think they understand the context there. A lot of that stuff is baggage. It's not [laugh] even, like, best-of-breed or great design. It's like happenstance from 20 years of trying to buy everything that's been sold to you.Corey: I agree with that idea wholeheartedly. I was surprising someone the other day when I said that if you were to give me a task of getting some random application up and running by tomorrow, I do a traditional three-tier architecture, some virtual machines, a load balancer, and a database service. And is that the way that all the cool kids are doing it today? Well, they're not talking about it, but mostly. But the point is, is that it's what I know, it's where my background is, and the thing you already know when you're trying to solve a new problem is incredibly helpful, rather than trying to learn everything along that new path that you're forging down. Is that architecture the best approach? No, but it's perfectly sufficient for an awful lot of stuff.Kelsey: Yeah. And so, I mean, look, I've benefited my whole career from people fantasizing about [laugh] infrastructure—Corey: [laugh].Kelsey: And the truth is that in 2023, this stuff is so powerful that you can do almost anything you want to do with the simplest architecture that's available to us. The three-tier architecture has actually gotten better over the years. I think people are forgotten: CPUs are faster, RAM is much bigger quantities, the networks are faster, right, these databases can store more data than ever. It's so good to learn the fundamentals, start there, and worst case, you have a sound architecture people can reason about, and then you can go jump into the deep end, once you learn how to swim.Corey: I think that people would be depressed to understand just how much the common case for the value that Kubernetes brings is, “Oh yeah, now we can lose a drive or a server and the application stays up.” It feels like it's a bit overkill for that one somewhat paltry use case, but that problem has been hounding companies for decades.Kelsey: Yeah, I think at some point, the whole ‘SSH is my only interface into these kinds of systems,' that's a little low level, that's a little bare bones, and there will probably be a feature now where we start to have this not Infrastructure as Code, not cloud where we put infrastructure behind APIs and you pay per use, but I think what Kubernetes hints at is a future where you have APIs that do something. Right now the APIs give you pieces so you can assemble things. In the future, the APIs will just do something, “Run this app. I need it to be available and here's my money budget, my security budget, and reliability budget.” And then that thing will say, “Okay, we know how to do that, and here's roughly what is going to cost.”And I think that's what people actually want because that's how requests actually come down from humans, right? We say, “We want this app or this game to be played by millions of people from Australia to New York.” And then for a person with experience, that means something. You kind of know what architecture you need for that, you know what pieces that need to go there. So, we're just moving into a realm where we're going to have APIs that do things all of a sudden.And so, Kubernetes is the warm-up to that era. And that's why I think that transition is a little rough because it leaks the pieces part, so where you can kind of build all the pieces that you want. But we know what's coming. Serverless also hints at this. But that's what people should be looking for: APIs that actually do something.Corey: This episode is sponsored in part by Panoptica.  Panoptica simplifies container deployment, monitoring, and security, protecting the entire application stack from build to runtime. Scalable across clusters and multi-cloud environments, Panoptica secures containers, serverless APIs, and Kubernetes with a unified view, reducing operational complexity and promoting collaboration by integrating with commonly used developer, SRE, and SecOps tools. Panoptica ensures compliance with regulatory mandates and CIS benchmarks for best practice conformity. Privacy teams can monitor API traffic and identify sensitive data, while identifying open-source components vulnerable to attacks that require patching. Proactively addressing security issues with Panoptica allows businesses to focus on mitigating critical risks and protecting their interests. Learn more about Panoptica today at panoptica.app.Corey: You started the show by talking about how your career began with translating COBOL into Python. I firmly believe someone starting their career today listening to this could absolutely find that by the time their career starts drawing to their own close, that Kubernetes is right in there as far as sounding like the deprecated thing that no one really talks about or thinks about anymore. And I hope so. I want the future to be brighter than the past. I want getting a business or getting software together in a way that helps people to not require the amount of, “First, spend six weeks at a boot camp,” or, “Learn how to write just enough code that you can wind up getting funding and then have it torn apart.”What's the drag-and-drop story? What's the describe the application to a robot and it builds it for you? I'm optimistic about the future of infrastructure, just because based upon its power to potentially make reliability and scale available to folks who have no idea of what's involved with that. That's kind of the point. That's the end game of having won this space.Kelsey: Well, you know what? Kubernetes is providing the metadata to make that possible, right? Like in the early days, people were writing one-off scripts or, you know, writing little for loops to get things in the right place. And then we get config management that kind of formalizes that, but it still had no metadata, right? You'd have things like Puppet report information.But in the world of, like, Kubernetes, or any cloud provider, now you get semantic meaning. “This app needs this volume with this much space with this much memory, I need three of these behind this load balancer with these protocols enabled.” There is now so much metadata about applications, their life cycles, and how they work that if you were to design a new system, you can actually use that data to craft a much better API that made a lot of this boilerplate the defaults. Oh, that's a web application. You do not need to specify all of this boilerplate. Now, we can give you much better nouns and verbs to describe what needs to happen.So, I think this is that transition as all the new people coming up, they're going to be dealing with semantic meaning to infrastructure, where we were dealing with, like, tribal knowledge and intuition, right? “Run this script, pipe it to this thing, and then this should happen. And if it doesn't, run the script again with this flag.” Versus, “Oh, here's the semantic meaning to a working system.” That's a game-changer.Corey: One other topic I wanted to ask you about—I've it's been on my list of things to bring up the next time I ran into you and then you went ahead and retired, making it harder to run into you. But a little while back, I was at a tech conference and someone gave a demo, and it didn't go as well as they had hoped. And a few of us were talking about it afterwards. We've all been speakers, we've all lived that life. Zero shade.But someone brought you up in particular—unprompted; your legend does precede you—and the phrase that they used was that Kelsey's demos were always picture-perfect. He was so lucky with how the demos worked out. And I just have to ask—because you don't strike me as someone who is not careful, particularly when all eyes are upon you—and real experts make things look easy, did you have demos periodically go wrong that the audience just didn't see going wrong along the way? Or did you just actually YOLO all of your demos and got super lucky every single time for the last eight years?Kelsey: There was a musician who said, “Hey, your demos are like jazz. You improvise the whole thing.” There's no script, there's no video. The way I look at the demo is, like, you got this instrument, the command prompt, and the web browser. You can do whatever you want with them.Now, I have working code. I wrote the code, I wrote the deployment scenarios, I delete it all and I put it all back. And so, I know how it's supposed to work from the ground up. And so, what that means is if anything goes wrong, I can improvise. I could go into fixing the code. I can go into doing a redeploy.And I'll give you one good example. The first time Kubernetes came out, there was this small meetup in San Francisco with just the core contributors, right? So, there is no community yet, there's no conference yet, just people hacking on Kubernetes. And so, we decided, we're going to have the first Kubernetes meetup. And everyone got, like, six, seven minutes, max. That's it. You got to move.And so, I was like, “Hey, I noticed that in the lineup, there is no ‘What is Kubernetes?' talk. We're just getting into these nuts and bolts and I don't think that's fair to the people that will be watching this for the first time.” And I said, “All right, Kelsey, you should give maybe an intro to what it is.” I was like, “You know what I'll do? I'm going to build a Kubernetes cluster from the ground up, starting with VMs on my laptop.”And I'm in it and I'm feeling confident. So, confidence is the part that makes it look good, right? Where you're confident in the commands you type. One thing I learned to do is just use your history, just hit the up arrow instead of trying to copy all these things out. So, you hit the up arrow, you find the right command and you talk through it and no one looks at what's happening. You're cycling through the history.Or you have multiple tabs where you know the next up arrow is the right history. So, you give yourself shortcuts. And so, I'm halfway through this demo. We got three minutes left, and it doesn't work. Like, VMware is doing something weird on my laptop and there's a guy calling me off stage, like, “Hey, that's it. Cut it now. You're done.”I'm like, “Oh, nope. Thou shalt not go out like this.” It's time to improvise. And so, I said, “Hey, who wants to see me finish this?” And now everyone is locked in. It's dead silent. And I blow the whole thing away. I bring up the VMs, I [pixie 00:28:20] boot, I installed the kubelet, I install Docker. And everyone's clapping. And it's up, it's going, and I say, “Now, if all of this works, we run this command and it should start running the app.” And I do kubectl apply-f and it comes up and the place goes crazy.And I had more to the demo. But you stop. You've gotten the point across, right? This is what Kubernetes is, here's how it works, and look how you do it from scratch. And I remember saying, “And that's the end of my presentation.” You need to know when to stop, you need to know when to pivot, and you need to have confidence that it's supposed to work, and if you've seen it work a couple of times, your confidence is unshaken.And when I walked off that stage, I remember someone from Red Hat was like—Clayton Coleman; that's his name—Clayton Coleman walked up to me and said, “You planned that. You planned it to fail just like that, so you can show people how to go from scratch all the way up. That was brilliant.” And I was like, “Sure. That's exactly what I did.”Corey: “Yeah, I meant to do that.” I like that approach. I found there's always things I have to plan for in demos. For example, I can never count on having solid WiFi from a conference hall. The show has to go on. It's, okay, the WiFi doesn't work. I've at one point had to give a talk where the projector just wasn't working to a bunch of students. So okay, close the laptop. We're turning this into a bunch of question-and-answer sessions, and it was one of the better talks I've ever given.But the alternative is getting stuck in how you think a talk absolutely needs to go. Now, keynotes are a little harder where everything has been scripted and choreographed and at that point, I've had multiple fallbacks for demos that I've had to switch between. And people never noticed I was doing it for that exact reason. But it takes work to look polished.Kelsey: I will tell you that the last Next keynote I gave was completely irresponsible. No dry runs, no rehearsals, no table reads, no speaker notes. And I think there were 30,000 people at that particular Next. And Diane Greene was still CEO, and I remember when marketing was like, “Yo, at least a backup recording.” I was like, “Nah, I don't have anything.”And that demo was extensive. I mean, I was building an app from scratch, starting with Postgres, adding the schema, building an app, deploying the app. And something went wrong halfway. And there's this joke that I came up with just to pass over the time, they gave me a new Chromebook to do the demo. And so, it's not mine, so none of the default settings were there, I was getting pop-ups all over the place.And I came up with this joke on the way to the conference. I was like, “You know what'd be cool? When I show off the serverless stuff, I would just copy the code from Stack Overflow. That'd be like a really cool joke to say this is what senior engineers do.” And I go to Stack Overflow and it's getting all of these pop-ups and my mouse couldn't highlight the text.So, I'm sitting there like a deer in headlights in front of all of these people and I'm looking down, and marketing is, like, “This is what… this is what we're talking about.” And so, I'm like, “Man do I have to end this thing here?” And I remember I kept trying, I kept trying, and came to me. Once the mouse finally got in there and I cleared up all the popups, I just came up with this joke. I said, “Good developers copy.” And I switched over to my terminal and I took the text from Stack Overflow and I said, “Great developers paste,” and the whole room start laughing.And I had them back. And we kept going and continued. And at the end, there was like this Google Assistant, and when it was finished, I said, “Thank you,” to the Google Assistant and it was talking back through the live system. And it said, “I got to admit, that was kind of dope.” So, I go to the back and Diane Greene walks back there—the CEO of Google Cloud—and she pats me on the shoulder. “Kelsey, that was dope.”But it was the thrill because I had as much thrill as the people watching it. So, in real-time, I was going through all these emotions. But I think people forget, the demo is supposed to convey something. The demo is supposed to tell some story. And I've seen people overdo their demos with way too much code, way too many commands, almost if they're trying to show off their expertise versus telling a story. And so, when I think about the demo, it has to complement the entire narrative. And so, sometimes you don't need as many commands, you don't need as much code. You can keep things simple and that gives you a lot more ins and outs in case something does go crazy.Corey: And I think the key takeaway here that so many people lose sight of is you have to know the material well enough that whatever happens, well, things don't always go the way I planned during the day, either, and talking through that is something that I think serves as a good example. It feels like a bit more of a challenge when you're trying to demo something that a company is trying to sell someone, “Oh, yeah, it didn't work. But that's okay.” But I'm still reminded by probably one of the best conference demo fails I've ever seen on video. One day, someone was attempting to do a talk that hit Amazon S3 and it didn't work.And the audience started shouting at him that yeah, S3 is down right now. Because that was the big day that S3 took a nap for four hours. It was one of those foundational things you'd should never stop to consider. Like, well, what if the internet doesn't work tomorrow when I'm doing my demo? That's a tough one to work around. But rough timing.Kelsey: [breathy sound]Corey: He nailed the rest of the talk, though. You keep going. That's the thing that people miss. They get stuck in the demo that isn't working, they expect the audience knows as much as they do about what's supposed to happen next. You're the one up there telling a story. People forget it's storytelling.Kelsey: Now, I will be remiss to say, I know that the demo gods have been on my side for, like, ten, maybe fifteen years solid. So, I retired from doing live demos. This is why I just don't do them anymore. I know I'm overdue as an understatement. But the thing I've learned though, is that what I found more impressive than the live demo is to be able to convey the same narratives through story alone. No slides. No demo. Nothing. But you can still make people feel where you would try to go with that live demo.And it's insanely hard, especially for technologies people have never seen before. But that's that new challenge that I kind of set up for myself. So, if you see me at a keynote and you've noticed why I've been choosing these fireside chats, it's mainly because I'm also trying to increase my ability to share narrative, technical concepts, but now in a new form. So, this new storytelling format through the fireside chat has been my substitute for the live demo, normally because I think sometimes, unless there's something really to show that people haven't seen before, the live demo isn't as powerful to me. Once the thing is kind of known… the live demo is kind of more of the same. So, I think they really work well when people literally have never seen the thing before, but outside of that, I think you can kind of move on to, like, real-life scenarios and narratives that help people understand the fundamentals and the philosophy behind the tech.Corey: An awful lot of tools and tech that we use on a day-to-day basis as well are thankfully optimized for the people using them and the ergonomics of going about your day. That is orthogonal, in my experience, to looking very impressive on stage. It's the rare company that can have a product that not only works well but also presents well. And that is something I don't tend to index on when I'm selecting a tool to do something with. So, it's always a question of how can I make this more visually entertaining? For while I got out of doing demos entirely, just because talking about things that have more staying power than a screenshot that is going to wind up being irrelevant the next week when they decide to redo the console for some service yet again.Kelsey: But you know what? That was my secret to doing software products and projects. When I was at CoreOS, we used to have these meetups we would used to do every two weeks or so. So, when we were building things like etcd, Fleet was a container management platform that came before Kubernetes, we would always run through them as a user, start install them, use them, and ask how does it feel? These command line flags, they don't feel right. This isn't a narrative you can present with the software alone.But once we could, then the meetups were that much more engaging. Like hey, have you ever tried to distribute configuration to, like, a thousand servers? It's insanely hard. Here's how you do with Puppet. But now I'm going to show you how you do with etcd. And then the narrative will kind of take care of itself because the tool was positioned behind what people would actually do with it versus what the tool could do by itself.Corey: I think that's the missing piece that most marketing doesn't seem to quite grasp is, they talk about the tool and how awesome it is, but that's why I love customer demos so much. They're showing us how they use a tool to solve a real-world problem. And honestly, from my snarky side of the world and the attendant perspective there, I can make an awful lot of fun about basically anything a company decides to show me, but put a customer on stage talking about how whatever they've built is solving a real-world problem for them, that's the point where I generally shut up and listen because I'm going to learn something about a real-world story. Because you don't generally get to tell customers to go on stage and just make up a story that makes us sound good, and have it come off with any sense of reality whatsoever. I haven't seen that one happen yet, but I'm sure it's out there somewhere.Kelsey: I don't know how many founders or people building companies listen in to your podcast, but this is right now, I think the number one problem that especially venture-backed startups have. They tend to have great technology—maybe it's based off some open-source project—with tons of users who just know how that tool works, it's just an ingredient into what they're already trying to do. But that isn't going to ever be your entire customer base. Soon, you'll deal with customers who don't understand the thing you have and they need more than technology, right? They need a product.And most of these companies struggle painting that picture. Here's what you can do with it. Or here's what you can't do now, but you will be able to do if you were to use this. And since they are missing that, a lot of these companies, they produce a lot of code, they ship a lot of open-source stuff, they raise a lot of capital, and then it just goes away, it fades out over time because they can bring on no newcomers. The people who need help the most, they don't have a narrative for them, and so therefore, they're just hoping that the people who have all the skills in the world, the early adopters, but unfortunately, those people are tend to be the ones that don't actually pay. They just kind of do it themselves. It's the people who need the most help.Corey: How do we monetize the bleeding edge of adoption? In many cases you don't. They become your community if you don't hug them to death first.Kelsey: Exactly.Corey: Ugh. None of this is easy. I really want to thank you for taking the time to catch up and talk about how you seen the remains of a career well spent, and now you're going off into that glorious sunset. But I have a sneaking suspicion you'll still be around. Where should people go if they want to follow up on what you're up to these days?Kelsey: Right now I still use… I'm going to keep calling it Twitter.Corey: I agree.Kelsey: I kind of use that for my real-time interactions. And I'm still attending conferences, doing fireside chats, and just meeting people on those conference floors. But that's what where I'll be for now. So yeah, I'll still be around, but maybe not as deep. And I'll be spending more time just doing normal life stuff, maybe less building software.Corey: And we will, of course, put a link to that in the show notes. Thank you so much for taking the time to catch up and share your reflections on how the industry is progressing.Kelsey: Awesome. Thanks for having me, Corey.Corey: Kelsey Hightower, now gloriously retired. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment that you're going to type on stage as part of a conference talk, and then accidentally typo all over yourself while you're doing it.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Kelsey Hightower joined Bryan and Adam to revisit a topic Bryan had spoken about a decade ago: corporate open source anti-patterns. Kelsey brought his typical sagacity to a complex and fraught topic.We've been hosting a live show weekly on Mondays at 5p for about an hour, and recording them all; here is the recording from August 28th, 2023.In addition to Bryan Cantrill and Adam Leventhal, we were joined by Kelsey Hightower.Here is the (lightly edited) live chat from the show: xxxxbubbler: https://www.youtube.com/watch?v=Pm8P4oCIY3g here is Bryan's talk from 1 decade ago, for reference rolipo.li: web3 is going great rolipo.li: https://web3isgoinggreat.com/ ahl0003: Last time Kelsey joined us for predictions blainehansen: "Governance orgies" happen when the governance mechanisms aren't well-designed ha. If they are well-designed then governance is good! jbk: opsware maybe? or tivoli? uptill3: hp openview was one as well sevanj: "they've got us working for trinkets" sevanj: this was mentioned on the bugzilla anouncement regarding funded staff being pulled from working on project in the last 3 years. blainehansen: All open source problems are secretly public goods problems haha carpetbomberz.com: Hashicorp DID do a "thing" blacksmithforlife: Just like taxes fund roads, we should have a internet usage tax that then funds these open source projects that everyone finds value in. The person taxed should get to decide which open source project gets the money kaliszad: The problem is, you can help other people, but first you have to sustain yourself.

Kendall Miller is the Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. The first half of the conversation with host Victoria Guido and special guest host, Joe Ferris, CTO of thoughtbot revolves around the use, adoption, and growth of Kubernetes within the technology industry. The discussion explores Kubernetes' history, influence, and its comparison with other platforms like Heroku and WordPress, emphasizing its adaptability and potential. The second half focuses on more practical aspects of Kubernetes, including its adoption and scalability. It centers on the appropriateness of adopting Kubernetes for different projects and how it can future-proof infrastructure. The importance of translating technical language into business speak is emphasized to influence executives and others in the decision-making process and Kendall also discuss communication and empathy in tech, particularly the skill of framing questions and understanding others' emotional states. __ CTO Lunches (http://ctolunches.com/) Follow CTO Lunches on LinkedIn (https://www.linkedin.com/company/ctolunches/) or Twitter (https://twitter.com/cto_lunches). Follow Kendall Miller on LinkedIn (https://www.linkedin.com/in/kendallamiller/). Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Kendall Miller, Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. Kendall, thank you for joining me. KENDALL: Thanks for having me. I'm excited. VICTORIA: And today, we have a special guest host, Joe Ferris, CTO of thoughtbot. Joe, thank you for joining us. JOE: Hello there. Thank you for having me. KENDALL: Hi, Joe. Thanks for being here. It's exciting. VICTORIA: Yes. It's so exciting. I think this is going to be a great episode. So, Kendall, I met you at a San Diego CTO lunch recently, and I know that's not the only thing that you do. So, you're also an advisor, a board member, and CXO. So, maybe tell us a little bit more about your background. KENDALL: Gosh, my background is complicated. I've been involved in tech for a very long time. In college, I worked for a company that started Twitter about five years too soon, and then worked in the nonprofit space in China for ten years, then came back, got back involved in tech. Today, I'm usually the business guy. So, when technical founders start technical products and want help turning them into successful technical businesses, that's when they call me. So, I have the technical background. I have never been paid to write code, which is probably a good thing. But I can hang in the technical conversations for the most part, but I'm much more interested in the business side and the people leadership side of business. So that tends to be where I play. Every organization hires me to do something different. VICTORIA: Thank you for that. And I'm just curious about the CTO Lunches. Just tell me a little bit more about that. And what's the idea behind it that led you to co-found it? KENDALL: CTO Lunches has actually been around for about eight years. And I didn't start the initial incarnation of it. It was two people that got us started, and I was trying to hire one of them; one thing led to another. Actually, originally, they did not want me to join. I think, at the time, my title was COO at a company that I was working with. About six months later, I took over engineering as VP of engineering, and then they're like, you can join the group now. We're less strict about that [laughs] now. Although it is highly focused on senior engineering leaders, it's not exclusively CTOs. But the group's been in place for a very long time, just intended as a place to network, have conversation with people who are in that senior-most technical position at technical organization. So, the CTO role is a lonely role. CTOs get fired all the time. There's not a technical person at the company that doesn't think they can do the job better than them. So, the CTO is always getting feedback. You're doing this wrong. The trade-offs you're making are wrong. This isn't going where it should be going. We should automate that. Why haven't we automated that? We should switch to this other tool. I've used it before; it's 100 times better. Joe, let me know if I'm getting any of this wrong. But that's the experience that I've had. Having a place where people can get together and, you know, half the time just complain to each other, hey, this is hard, is really why the networking group exists. So, it's a listserv. And there are local lunches that started in Boulder, Colorado. It's gotten pretty global. About a year ago, a little over a year ago, I was talking with one of the people who'd gotten it started. I've been involved in the Denver chapter for most of those eight years. And I was suggesting to him that he change a few things about it, to monetize it so that he could invest in it further. And he came back a few months later and said, "I want to take your advice and do this, but I want you to come do it with me." So, we founded the company officially...I think in December is when paperwork went into place. And we started investing in it a little bit more heavily. I was living in Europe last year, so we went and put on lunches in Paris, and Lisbon, and London, and, gosh, all over the place. I'm sure I'm missing some, Amsterdam. But there's been chapters all over the U.S. and a couple of other parts of the world for a long time. VICTORIA: That reflects my experience attending a CTO lunch. It's just very casual, like, just get together and eat food and talk about what you've worked on recently, issues you're having, just get ideas and make some friends. So, I really appreciated the group, and I'm going to personally plug the San Diego Chapter has picked up again. And we're meeting next Friday down in Del Mar. And we're going to be meeting on the last Friday of every month through October. So, I'm super excited to be a part of the group. And Joe, yeah, I'm curious about your perspective. As a CTO with thoughtbot, just what are your thoughts about that kind of thing? KENDALL: Yeah. How right am I about how lonely you are, Joe? JOE: [laughs] You know, I've been lonelier since we went remote. I used to work in the office, and I was a CTO, but also, I had lunch with people, which was nice. So, I'm lonelier. But yeah, I think everybody needs a group like that, like, senior developer therapy just to talk about your woes together, drown your sorrows. KENDALL: Well, I think years ago, I heard that CTOs are the most fired C-level executive. JOE: You're making me nervous now. KENDALL: [laughs] You've been there a long time, Joe. I know you've been there a long time. If you haven't been fired yet, you probably got a little while longer in you. This will be really awkward if it's published and you've already been fired. VICTORIA: We can always edit that out afterwards. [laughter] KENDALL: Yeah, no, I think it is a particularly lonely position. And, again, I think a lot of it is the average engineer in a technical company doesn't look at the COO or the CFO or even the CEO and think I could do that. But they're all looking at the CTO and thinking, what does that person do that I can't do? It's ridiculous because most of them would make terrible CTOs because it does require some of the business sense. Or, you know, right out of the gate, they might make terrible CTOs. It actually is quite a skill to be the most technical person and speak the business language. I mean, am I right about that, Joe? Like, was that hard for you to learn? JOE: Yeah, I definitely think...so, my background is also technical. I have a background in consulting. So, I always did a lot of metaprogramming, if you will. But making that transition to thinking about organizations that way, thinking about how all the other pieces play into it, was a pretty big step for me, even before I became a CTO as a consultant. KENDALL: Well, because you can't just chase the newest, hottest technology. You have to make business trade-offs. And not everything can be resume-driven development, right? Even if that technology over there is newer or hotter, it doesn't mean you have a business model that supports it. And it doesn't mean that migrating to it can be done, right? JOE: Yeah. I mean, even beyond choosing technologies, just choosing where to invest in your software stack, like, what needs to be reworked, what doesn't, and trying to explain those trade-offs, I think, is a rare skill. Being able to explain why something would be harder than something else when you're working with the leadership to prioritize a backlog it's a puzzle. KENDALL: Well, and I think when I'm in an executive conversation, and the CTO says, "Here's the thing that I think is the best decision technically, and I think it's the wrong decision for the business because of X, Y, or Z," I'm always super impressed, right? Like, this is the right technical solution for what we want. However, we shouldn't pursue that for business reasons right now. Maybe we can in six months, but right now, we need to prioritize this other thing. I don't know, that's always when I feel like, oh, this person knows what they're doing. JOE: There's nothing more dangerous to software than a bored developer. [laughs] One nice thing about being a consultant is that I don't have to invent problems to solve with technology at my company because sooner or later, I'll run across a company that has those problems, and I'll get to use that technology. But I think a lot of people are mostly happy...they might be happy in their role. They might be happy with our team. But they're very interested in whatever is hot right now, like machine learning, AI. And so, suddenly, that surreptitiously makes its way into the tech stack. And then, years later, it's somebody's problem to maintain. KENDALL: [laughs] Well, I have a specific memory of a firm in New York City that was, you know, this is relevant to y'all as thoughtbot is that, you know, at least historically, it was, to me, the premier Ruby on Rails consulting shop. I think that's still largely y'alls focus. Am I right about that? JOE: We still do a ton of Rails, yeah. KENDALL: Okay. Well, so this organization was all Ruby on Rails. It was a big organization. They had a very large customer base. And they hired a new CTO who came in, told everybody in the company they were stupid, laid off 70% of the engineering organization, and told the CEO he was going to completely rewrite the product from scratch in .NET, and he could do it in three weeks. And I'm pretty sure the business went under about three months later [laughs] because that was just so outrageously nuts to me. JOE: It's too bad he laid everybody off beforehand. I've been in that situation where somebody tells me, "I'm going to rewrite this. It'll be ready in three weeks." And I could fight with them and try and convince them they're wrong. But I feel like somebody who's approaching that with that attitude they're missing all of the nuance and context that would make it possible to explain to them why it's not going to work. And so, it's easier to just say, "You know, take the three weeks. I'll talk to you in three weeks." But if you've already laid off your development team, that's hard [laughs] to recover from. KENDALL: That's exactly right. VICTORIA: There's got to be a name for that kind of CTO who just wants to come in and blow everything up [laughs]. Yeah, so you spend a lot of time talking to different CTOs and doing this social networking aspect. I'm wondering if there's, like, patterns that you see. You've mentioned already one about just, like, the most often getting fired. [laughs] But what are the patterns you see, like, in challenges, and then what makes someone successful in that CTO role? KENDALL: Well, oh gosh, I have so many thoughts about this. First of all, I run into a couple of different categories of CTOs. There's a lot of people who come to CTO Lunches who are small company CTOs. I mean, it makes sense that there's a lot more small company CTOs than there are big company CTOs. But the small company CTO who maybe it's their first gig in the role or they're a serial CTO. There's the fractional CTOs that come that are doing it across several different organizations at the same time, and then there's the big company CTO who shows up. And honestly, all of their problems are very different. The thing that they have in common is even at a very large organization, in that position, they can make a decision that causes the company to go under. So, there is a significant amount of volatility in the amount of power that they wield. So, what's interesting about that is not everybody understands that. And so, first of all, there's the kind of CTO that just doesn't get that, and that doesn't matter if they're fractional, or a small company CTO, or a big company CTO. If they don't understand that, they're going to cause significant problems, right? Like the person I just mentioned who said, "I can just re-platform this in three weeks in .NET." There's that. I mean, I think, as with any senior leadership position, the comfort with volatility, the ability to know what to communicate down versus across and versus up, and then the ability to speak the business language. For everybody, the CFO's job is to communicate the financial needs alongside of the business leads, right? If the CFO's sole goal is to cut costs or make sure we're running as lean as possible, they're a bad CFO. But they're not as good of a CFO as the CFO who can say, "Hey, we're underspending right here. And I can look at the numbers and know we should invest more there. How can we invest more there and invest it well?" And it's the same thing for a technology executive to be able to look at the business context and communicate it back. And there are so many CTOs that I've worked with who they're the most technical person in the room, and they know it. And as a result, they're just a jerk to everyone around them, like, everything you did here was wrong. You know, that's where they fail. And so, if they can communicate the business needs, navigate the volatility, and support a team that's going to make decisions that aren't always the same decision they're going to make, they're going to be successful. Honestly, there's very, very few CTOs that I've met like that. People who are excited to meet you at work, excited to see you succeed, excited to see that you went and built a thing is great. I mean, the reason I was VP of engineering is the CTO that I was working with at the time...it's a terrible story. There was an engineer who had seen something that we were doing on repeat all the time and, in his spare time, spent about 40 hours outside of work, not during work hours, automating this task that we were doing regularly. And it was related to standing up a whole bunch of things in our standard infrastructure. He brings it to the CTO and says, "Look what I built." And the CTO, instead of saying, "Hey, this is incredible. Thank you. This is going to save us a bunch of time. Let's iterate on it. Here's some things I'd like to tweak. Can we bring it in this direction? Can we..." you know, whatever, said, "Why is this in Python? It should be in Ansible," something like that. I can't remember. And the engineer literally burst into tears. [laughs] JOE: Oh my God. KENDALL: [laughs] Well, I mean, yeah, it was like; literally, that's why the CTO stopped managing people that day. There's a lot of examples that I have like that. Joe, I appreciate that your response is, "Oh my God." Because I think there's a lot of people who'd be like, wait, what was wrong with that? Shouldn't it have been in Ansible? JOE: [laughs] Yeah, I've seen CTOs come into primarily two groups. One is the CTO who just tells, you know, like, they make the decisions, and they tell everybody what to do. They obviously don't have all of the information because you can't be in every room all the time. And the other is the CTO, who just wants to be one of the team members and doesn't make any decisions and tries to get people to make decisions collectively on their own without any particular guidance or structure. And finding that middle spot of, like, not just saying, "Hey, everything's in Ansible," allowing for the creativity and initiative, but also coalescing the group into a single direction, I think, is what makes a good CTO. KENDALL: Well, yeah, because the CTO does have to say no, sometimes, right? Like, the best product, people say, "No." Good CTOs say, "No." There is some amount of, hey, I need you to come to me with trade-offs about this. Why are you going to make that decision? And I'm sorry, you still didn't convince me, right? Like, I mean, those are appropriate things to say. But yeah, I'm with you on that. You said they fall into two categories. But you really mean the third and that middle ground. Is it easy for you to walk that middle ground, Joe? JOE: I wouldn't say it's easy. [laughs] KENDALL: Yeah. Well, I'm always nervous to say something. I'm doing well because I know there's a report out there that can point at every time I failed at it, right? So... MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you're tight on time and investment, which is why we've created targeted 1-hour remote workshops to help you develop a concrete plan for your product's next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at: tbot.io/entrepreneurs. VICTORIA: Yeah, what I'm getting from what you're saying, too, is this communication ability and not just, like, to communicate clearly but with a high level of empathy. So, if you say like, "Well, why is it in Python and not Ansible?" is different than being like, "What makes Python the best solution here?" Like, it's a different way to frame the question that could put someone on the defensive that just really requires, like, a high level of emotional intelligence. And also, if they've just worked, like, an 80-hour week, [laughs] I probably would maybe choose a different time to bring those questions up and notice that they have been burning the candle at both ends and prioritize getting them some rest. So, speaking of, like, communication and getting prioritization for [inaudible 15:34], especially on, like, infrastructure teams, maybe we could talk a little bit about Kubernetes, like, when that comes up as an appropriate solution, and how you talk about it with the business. KENDALL: My background with Kubernetes is long because a company that I still work with, Fairwinds, used to be called ReactiveOps, has been in the Kubernetes space for a very long time. I think we were one of the very first companies working with Kubernetes. It was coming up that people were running into the limits of something like Heroku, right? And I think it's Kelsey Hightower who said every company wants a PaaS. They just want the Paas that they built themselves. And that's really accurate. And I think Kubernetes isn't quite a framework for building your own PaaS or isn't quite a foundation where I think of a foundation for a house. Instead, it's more like rebar and cement and somebody saying, "Good luck, buddy." You know, you still have to know how to put the rebar and cement together to even make the foundation, but it is the building blocks that help get you to a custom-built PaaS. And it's become something that a lot of people have landed on as, you know, the broadly accepted way to build cloud-native infrastructure. The reason I've been in the Kubernetes space and the space that I see Kubernetes still filling is we need to standardize on something. We can choose a cloud provider's PaaS. We can choose a third-party PaaS, or we can standardize on something like Kubernetes. And even though we're not going to migrate from AWS to Azure, the flexibility that Kubernetes gives us as a broadly adopted pattern is going to give us some ability to be future-proofed in our infrastructure in a way that previous stacks were not, you know, it was Puppet, and it was Ansible. And it was SaltStack. And it was all Terraform all the time. I'm not saying those things don't exist anymore. I'm saying Kubernetes kind of has won that battle. Joe, since you're here and I know y'all are doing some Kubernetes work now at thoughtbot, I'm curious if you agree with that characterization. JOE: Yeah, I think that's true. I think it's the center for people to coalesce around. Like, for an effort in the industry to move forward, there needs to be some common language, some common ground. And I think Kubernetes struck the right balance of being abstract. So, you can use it in different environments but still making some decisions, so you don't have to make them all. And so, like, all of the things you had to do with containers like figuring out what your data solution is going to be, what your networking solution is going to be, Kubernetes didn't even really make those decisions. [laughs] They just made a platform where those decisions can be made in a common way. And that allowed the community and the ecosystem to grow. KENDALL: I mean, I think of it a lot like WordPress; you know, WordPress is hated by many. When WordPress came out, it was hot, right? And it was PHP, which everybody was super excited about at the time. Kubernetes is going to reach a point where it's as long in the tooth and terrible as people think WordPress is, but it has become the standard. And the advantage of the standard is you can use the not standard. You can go build a website in Jekyll instead of WordPress, and there's going to be some things that are nicer about Jekyll. But because WordPress is so broadly adopted, there's a plugin for everything. And I think that's where Kubernetes sits is because it's become so widely adopted everybody's building for it. Everybody's adapting for it. If you run into a problem, you're going to find somebody else out there who has that problem. In fact, I think of one organization that I know that was on HashiCorp's Nomad. And they said, "Actually, we think Nomad has better technology through and through. But we think we're the only company at this size and scale using Nomad. And so, when we run into a problem, we can't Google for it. There's no such thing as a plugin that exists to solve this. Nobody has ever run into this before on Nomad. But there's 100 companies dealing with the same problem in Kubernetes, and there's ten solutions." And I think that's the power that it brings. VICTORIA: So, it's not just a trend that CTOs are moving towards, you think. KENDALL: I mean, I think it's already won the battle and the hockey stick of adoption. We're still right at the very bottom of that tick-up because it takes people a long time to adapt new technology like this, especially in their infrastructure. It's a big migration, to move. So, I don't think it's the widely adopted infrastructure technology even yet. I think a lot of the biggest organizations are still running on things that predate Kubernetes. But I think it has won the battle, and it is winning the battle and is going to be the thing going forward, so yeah. JOE: I think it also has a lot of room to grow still. Like, there are other technologies that I used previously, like Docker, and they were a big step up from some of the things I was doing at the time. But you quickly hit the ceiling, or it was, like, I don't know where to go with this next. I don't know what else is going to happen. Whereas with Kubernetes, there are so many directions it can go in. Like, the serverless Kubernetes offerings that are starting to pop up are extremely interesting, where, you know, you don't actually maintain a cluster or anything. You just deploy things to this ethereal cluster that always exists. And so, that sort of combination of platform as a service, function as a service, Kubernetes, as that evolves, I think there are a lot of exciting things that have yet to come in the Kubernetes space. KENDALL: Well, so say more about that, Joe, because I've been going to KubeCon for a very long time, maybe...I don't know if it's 2016 or so when I first went. And it felt for a number of years...maybe those first four-ish years it was always the people at KubeCon were the, like, big dreamers and thinkers and, like, we're here to change the future of cloud infrastructure. And this is going places, and we're excited to be here and be a part of it. And here's what I'm going to do that changes the next thing. And I feel like now if I go to KubeCon, it's a lot of people from, you know, IBM and some big bank that are, like, deep sigh, well, I have to adopt Kubernetes. I need to know what the vendors are. What do you guys do, and how does this work? Can you please teach it to me? Because I'm being told by my boss, I have to do it. I don't see that excitement around Kubernetes anymore. The excitement I see is all around further up the stack, you know, things like Wasm, WebAssembly, or eBPF, the networking things and tracing things that are possible. Maybe that's further down the stack. I guess it depends on how you think about it, but different part of the stack. So, I'm curious, touching on the serverless components of Kubernetes; sure, I get that. And I do think, increasingly, the PaaSs of the future are all going to be Kubernetes-based, whether that's exposed or not. But where are the places that you think it's still going to go? Because I feel like it's already gotten boring, maybe in a positive way. But I don't see the excitement around it like I saw a few years back. And I'm curious what else you think is going to happen. JOE: Yeah, I mean, I don't think I disagree. I think Kubernetes itself, the core concept, is, like, it's still changing. But you're right that the excitement about Kubernetes existing has gone down because it's been there for a while. But I feel like the ecosystem is still growing pretty rapidly. Like, the things you mentioned, like Wasm and Istio, and all the tools in that ecosystem that continue to grow, is where I think the interesting things will happen. Like, it's created this new lower-level layer of abstraction that makes it possible to build concepts and technology that could not have existed before. KENDALL: Yeah, well, and I'm, you know, talking to people who are working really hard at making short-run ephemeral workloads work better on things like GPUs for the sake of AI, right? Like, I mean, there is some really interesting things happening, and people are doing this in Kubernetes. So, I get that. I agree with that. It is interesting that Kubernetes has become sort of the stable thing, and now it's about who can build the interesting add-ons. It's almost like, okay, we've built Half-Life. What is Counter-Strike going to look like? You know. That's a terrible (I'm aging myself.) example. But still. VICTORIA: I think it's interesting, I mean, to look at the size of the market for platform engineering right now. In 2022, was 4.8 billion, and it's estimated to be in 10 years $41 billion. So, there is this emerging trend of different platform engineering products, different abstractions on top of Kubernetes. And I wonder what advice you would have for a technical founder who's looking to build and solve some of these interesting issues in Kubernetes and create a business around it. KENDALL: Well, okay, let me clarify that question. Are you thinking, I'm a startup, and I need to build my infrastructure, and I'm going to choose Kubernetes. What advice do I need? Or are you thinking, I am founder, and I want to go build on the Kubernetes ecosystem. What advice do you have? VICTORIA: Now I want to know the answer to both. But my question was the second one to start. KENDALL: One of the things that is hard about the Kubernetes ecosystem is there's not a ton of companies that have made a whole bunch of money in Kubernetes because, as I said, I still think we're actually really early in the adoption curve. The kinds of companies that have adopted Kubernetes are the kinds of companies that don't spend lots and lots of money on an infrastructure. [laughs] They're the kinds of companies that are fast-moving, early adopters, or, you know, those first followers, and so they're under $100 million companies for the most part. Where the JP Morgans and Chase are running Kubernetes somewhere in their stack, but they haven't adopted it across the stack to need the biggest, best tools about it. So, the first piece of advice that I'd give is, be a little wary. It's still very early to the market. Maybe now is the time to build the thing. When ReactiveOps pivoted to Kubernetes, I think it was six months of having conversations with companies who were just, like, so excited about it, and this is definitely what we want to do. But nobody was doing it yet. You know, it was, we have, like, six solid months of just excitement and nobody actually pulling the trigger. And, you know, we were a little too early to that market. And that was just the people adopting it. So, I think there is some nervousness that cloud-native solutions the only people who are really making money in Kubernetes are named Amazon, Google, and Microsoft because it's the cloud providers that are making a ton off of it. Now, there's Rancher. There is StackPointCloud. There's a few others that have had big exits in this space. But I don't think it's actually as big of a booming economy as a lot of people think, in part because EKS is an incredibly amazing product. Like, eight years ago, the thing people paid us the most to do at ReactiveOps was just stand up Kubernetes because it was so stinking hard to just get it up and working. And now you click some buttons. Anybody can go do that. So, it's changed a lot, right? And I think be wary when you're entering that ecosystem. And then, my advice to the founder that's not building on the ecosystem but just looking to adopt a technology that's going to be a future-proofed infrastructure is just adopt one of the cloud-native platforms. And there are a whole bunch of sort of default best-in-class add-ons out there that you need to throw in. Don't adopt too many because then you have to maintain them forever. That's the easiest way to get started. You can figure out all the rest of it later. But if you go use EKS, or GKE, AKS, you can get started pretty easily and build something that is going to be future-proofed. I don't know, Joe; I'm curious if you disagree with any of that. JOE: Well, I think it's interesting to think about who's making money in Kubernetes. Like, I think there might not be as many companies who are doing only Kubernetes and Kubernetes-focused products that are massively successful. But I think because it has had a good amount of adoption and because it's easier to work with something that's standardized, it has helped companies sell things that they wanted to sell anyway. Like, all the Datadog, all the Scalas, the logging companies, they all have Kubernetes add-ons. And now everybody is paying Datadog [laughs] to have a dashboard for their Kubernetes cluster. I think they're making more money than they would have been without targeting the market. And so, I think that's really...if you want to get into the market, it's not, like, I'm going to build a Kubernetes product. It's if I'm building operations and an infrastructure product, I should definitely have it work with Kubernetes, and people will want to click and install it. KENDALL: So, to be clear, you know, one of the companies that I work with is called Axiom, and they play in the same, you know, monitoring, observability space as Datadog does. And part of what makes Kubernetes interesting in that space is in a microservice environment; there's so much happening. Where are problems being caused? We don't live in a day where I can just run my code, and it tells me that there's an unexpected semicolon on line 23, right? Like, that still happens. You're still doing those things. But this microservice talking to that microservice is where things tend to break down. Did I communicate this correctly? What was sent? What was received? Where did it break down? What was the latency? And if you were doing things in the old way back when you were standing it up with, say, Ansible, or Puppet, or something like that, and you were orchestrating all of these cloud virtual machines, you had to really work hard to instrument the tracing and logging and everything involved in order to track what was going on. Whereas that's one of the magic things about Kubernetes is with a few of the add-ons or some of the things out of the box with Kubernetes, it's a couple of clicks to get so, so much of the data and have insight into where things are going and what's going wrong. And so, I 100% agree with that. Kubernetes is generating a tremendous amount of data. And if you're a data company, it's really nice to have all that come in, and it helps them make money, helps the user of Kubernetes in that situation understand where problems are happening and breaking down. Yeah, there's definitely some network effects of what Kubernetes is doing in that. I completely agree. JOE: I think there are also some interesting companies, like, where they make...Emissary, Ambassador, and they have that sort of dual -- KENDALL: Komodor, is that -- JOE: Yeah, maybe. They have open source, but then they have a product. KENDALL: You're thinking of Ambassador Labs. JOE: Yeah. Ambassador Labs, yeah. I guess I don't really know how much money they're making. But I think that's a really interesting concept as people who make open-source things then make a well-supported product built around it. KENDALL: Sure. What's interesting is, I think in the VC world, at least right now, and it may pick up again, but post-Silicon Valley Bank nearly caving in, I think that the VC tolerance for, yeah, just go get a billion open-source adopters, and we'll figure out how to monetize later I think that the tolerance for that is a lot lower than it was even six months ago. JOE: Yeah, I think you have to have a dual model right from the beginning now. KENDALL: Yeah. Agreed. VICTORIA: You got to figure out how to make money on Kubernetes before you can. [laughs] KENDALL: You know, minor detail. That's why I think services companies in this space still have a lot going for it. Because in order to even be able to sell software to a company using Kubernetes, you half the time have to go stand up Kubernetes for them because it is still that hard for so many people to really adopt it. VICTORIA: Yeah. And maybe, like, talking more about, like, when it is the right decision to start on Kubernetes because I think the question I get sometimes is just, is it overkill? Is it too much for what we're building? Especially, like, if you're building a brand-new product, you're not even sure if it's going to get adopted that widely. KENDALL: I mean, and I'm [laughs] curious your thought on this, Joe, but there's a good argument to be made that Heroku was enough for the vast majority of founders early on. But the thing is, Kubernetes isn't as hard as it used to be. Going and clicking a couple of buttons on GKE and deploying something into Kubernetes with GKE Autopilot running it's not as easy as Heroku, but it's not wildly far off. And it does substantially future-proof you. So, when is it too early? I'm not sure it's ever too early if you have an intention of scaling if you're planning on running some kind of legacy workload, like, things that are going to be stateful. Or maybe WordPress, for example, you don't probably need to deploy your WordPress blog onto Kubernetes. You can do that in your cPanel on Bluehost. I don't actually know if Bluehost even exists anymore, but I assume it's still a thing. I don't know, what would you say, Joe? JOE: I agree with that. I think it's a hard first pill to swallow. But I think the reality is that it's very easy to underestimate the infrastructure needs of even an early product. Like, it doesn't really matter what you're building. You're still going to have things like secrets management. You're still going to have to worry about networking. They just don't go away. There's no way you have a product without them. And so, rather than slowly solving all those problems from scratch on a platform that isn't designed for it, I think it's easier to just bite the bullet and use one of the managed solutions, especially, as you said, I think it's getting easier and easier. The activation energy from going from credit card to Kubernetes cluster is just getting lower. KENDALL: And so, the role of the CTO is just getting easier and easier because they can just adopt the one technology, and it's obviously Kubernetes. And it's obviously Rust, right? [laughter] Yeah, no, I'm with you. And I think if you find somebody who knows Kubernetes inside and out, it's really not going to take them long to get started. VICTORIA: Yeah, once again, change management is the biggest challenge for any new innovation coming into adoption. So, I'm curious to talk more about the influence that you need and how you influence others to come around to these types of ideas, like, in the executive suite and with the leadership of a company, especially on these types of topics, which can feel maybe a little abstract for people. KENDALL: How you influence them specifically to use Kubernetes, or just how you talk with them about technology adoption in general? Or what are you asking? VICTORIA: Yeah, like, how do I get people to not just turn their ears off when I say the word Kubernetes? [laughs] KENDALL: Yeah, I mean, I think...so I think that's where it's the technologist's job and the role of the CTO to translate these things into business speak. And that's why I'm using words like future-proofing your infrastructure is because there are companies that...I know one company that made a conscious decision that they were going to try to re-platform every single year, and that is not a good idea or sustainable for the vast majority [laughs] of companies. In fact, I can't think of a single situation where that makes sense. But if you can say to the CFO, "Hey, it's going to cost us a little bit more right now. It's going to save us substantially in the long term because this is the thing that's winning. And if we go standardize on Heroku right now, every company does eventually have to migrate off of Heroku. They either go out of business, or they get too big for it." That's the kind of thing that needs to be communicated in order to get people to adopt it. They don't care what the word is. They don't care if you're saying Kubernetes; you know, most CFOs understand it about as well as my mom does. My mom tries to bring it up in conversation because she's heard me use it. And she thinks it makes her sound smart, which maybe it does in the right climate. VICTORIA: My partner does the same thing. He says DevOps and Kubernetes all the time. I'm like; you don't know what you're talking about. [laughter] JOE: Those words do not come up in my house. KENDALL: One of my kids asked me to explain Kubernetes. And I do a whole talk, particularly at organizations where understanding Kubernetes is essential to the salespeople's role. And I give a whole talk about the background of how we got here from deploying on some servers in our back room. And, you know, what's different about the cloud, what containerization did, et cetera. And I have this long explanation. And I remember taking a deep breath and saying to my kids, "Do you really want to hear this?" And I had one son say, "Yes, absolutely." And my wife and three of the other kids all stood up and said, "No way," and left the room. So, when somebody asks me, "What do you do?" Actually, one of the key relationships I built with some of the early people at GCP when we were partnering closely with them was a person that I met, and I asked, "What do you do for a living?" And he said, "I can tell you, but it's not going to mean anything to you." And I was like, "That's what I say to people." And it turned out he was in charge of, you know, Kubernetes partnerships for Google. I can explain to you what it means and why it's important. But you're not going to be happy that I spent that time explaining it to you. VICTORIA: [laughs] That sounds awesome, though. It sounds like you built a server rack just to demo to your children what it was. KENDALL: No, no. I just talked back through the history of...that company that I mentioned that built Twitter about five years too early; we had a, you know, we had a server rack in the...literally physically in our closet that was serving up our product at the time. VICTORIA: Probably the best demo I ever saw was at Google headquarters in Herndon, and someone had built...They had 3D-printed a little mini server rack that they had put Raspberry Pis onto, and then they had Kubernetes deployed on it. And they did an automatic failover of a node to just demo how it works and had little lights that went with it. It was pretty fun. So maybe you should get one for yourself. [laughter] It's a fun project. KENDALL: They remember the things that it enables. They don't remember what it does. And so, when I say so, and so is a client that's using this technology, then they get real excited because they're like, "My dad makes that work." And I'm like, well, okay, that's kind of a stretch, but you get the idea. VICTORIA: Yeah, you got to lean into that kind of reputation in your house. KENDALL: That's right. VICTORIA: And you're like, yes, that's correct. KENDALL: That's right. [laughs] VICTORIA: I do make Kubernetes. I make all the clouds work, yeah. KENDALL: Actually, my most common explanation is Kubernetes is the plumbing of the internet. Unless you're a plumber, you don't care about the pipes. You just want your shit to flush when you use the toilet. You want the things to load when you click your buttons. You don't actually care what's going on behind the scenes, but this is what's orchestrating it increasingly across the internet. VICTORIA: So far, we've called Kubernetes WordPress or the toilet. [laughs] KENDALL: The plumbing. [laughter] VICTORIA: You are really good at selling it. [laughter] KENDALL: Hey, if you want to build a nice, clean city, you need good plumbing. You might not care what the pipes are made of, but you need good plumbing. [laughs] VICTORIA: Works for me. On that note -- [laughs] KENDALL: Yeah. Right? Right? VICTORIA: That's [inaudible 36:41] on a high note. Is there anything else that you'd like to promote? KENDALL: With regards to CTO Lunches, we have a free listserv. There are local lunches. If there isn't a local lunch where you are, it's very lightweight to start up a chapter. We often have folks who are willing to sponsor that first lunch to get you going. We do have a paid tier of CTO Lunches. If you want a small back room Slack channel of people to discuss, I think it's $99 a month. Yeah, if you're a CTO and/or a senior engineering leader and you want a community of people to process with, be it our free tier or our paid tier, we've got something for you. We're trying to invest in this to build community around it. And it's something we enjoy doing more than almost anything. Come take part. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Kendall Miller.

Josh Doody, Owner of Fearless Salary Negotiation, joins Corey on Screaming in the Cloud to discuss how important tonality and communication is, both in salary negotiations and everyday life. Josh describes how important it is to have a positive padding to your communications in order to make the person on the other end of the negotiation feel like a collaborator rather than a combatant. Corey and Josh also describe scenarios where tonality made a huge difference in the outcome, and Josh gives some examples of where and when to be mindful of how you're coming across in modern communication methods. Josh also reveals how negotiating with companies multiple times allows him to understand their recruiters more than a person who is encountering their negotiation process for the first time.About JoshJosh is a salary negotiation coach who works with senior software engineers and engineering managers to negotiate job offers with big tech companies. He also wrote Fearless Salary Negotiation: A Step-by-Step Guide to Getting Paid What You're Worth, and recently launched Salary Negotiation Mastery to help folks who aren't able to work with Josh 1-on-1.Links Referenced: Fearless Salary Negotiation website: https://fearlesssalarynegotiation.com Fearless Salary Negotiation: https://www.amazon.com/Fearless-Salary-Negotiation-step-step/dp/0692568689/ Twitter: https://twitter.com/joshdoody LinkedIn: https://www.linkedin.com/in/joshdoody/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Human-scale teams use Tailscale to build trusted networks. Tailscale Funnel is a great way to share a local service with your team for collaboration, testing, and experimentation.  Funnel securely exposes your dev environment at a stable URL, complete with auto-provisioned TLS certificates. Use it from the command line or the new VS Code extensions. In a few keystrokes, you can securely expose a local port to the internet, right from the IDE.I did this in a talk I gave at Tailscale Up, their first inaugural developer conference. I used it to present my slides and only revealed that that's what I was doing at the end of it. It's awesome, it works! Check it out!Their free plan now includes 3 users & 100 devices. Try it at snark.cloud/tailscalescream Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined by recurring guest and friend Josh Doody, who among oh, so many things, is the owner of fearlesssalarynegotiation.com, and basically does exactly what it says on the tin. Josh, great to talk to you again.Josh: Hey, Corey. Thanks for having me back. I appreciate it and I'm glad to be here.Corey: So, you are, for those who have not heard me evangelize what you do—which is fine. No one listens to all of the backlog of episodes and whatnot—you are a salary negotiation coach, and you emphasize working with high earners who are negotiating new job offers, which is basically awesome. How did you stumble into this?Josh: Yeah, a good question. Really, it started as what I would say is a series of interesting career choices that I made, where I started as an engineer. I was pretty quickly bored in engineering and I switched to—I wanted to be customer-facing and do stuff that had impact on the business, so I did that and ended up working for a software company that made HR software that happened to do among other things, compensation planning. And so, I kind of started learning how it worked behind the scenes.And then over time, I started wising up and negotiating my own job offers. And noticed that wow that kind of worked pretty well, and I decided to write a book about it, a hundred percent just because I like to write stuff. I've been writing for 20 years on the internet, and I decided, why not just write a book about this? You know, five or six people will buy it, my mom will love it, I'll get it out there and it'll feel really good.And then people started reading the book and asking me if they could hire me to do the methodology in the book for them. And I said, “Sure.”Corey: When people try to give you money, say yes.Josh: Yeah. Okay, you know, whatever, you know? My first person that ever hired me asked me what my rate was, and I didn't have a rate because I had never considered doing that before. But she was a freelance writer and I said, “Well, whatever your rate is, that's my rate.” [laugh]. So, that was my first rate that I charged someone.And yeah, from there just, it took off as more people started hiring me. A number of friends were chirping in my ear that hey, you know, this seems like a really valuable thing that you're doing and people are coming out of the woodwork to ask you to do it for them. Maybe you should do that thing instead of the other things you're doing and trying to sell copies of the book and stuff like that. Like, why don't you just be a salary negotiation coach? That was, I don't know, like, seven years ago now, and here I am.Corey: I don't know if I ever told you this, but back when we met in the fall of 2016, I was trying to figure out what windmill I was going to tilt at before I stumbled upon the idea of AWS billing as being one of them. I thought that writing a book and being a sort of a coach of sorts on how to do job interviews with an emphasis, of course, on salary negotiation, would be a great topic for me because I've done it an awful lot. This is a byproduct of getting fired all the time because of my mouth. And then I started talking to you and my reaction was, “Oh, Josh is way better at this than I am. No, I'm going to go find something else instead.”And now the world is what it is, and honestly, at this point, all the cloud providers really wish you hadn't been there at that point in time because then they wouldn't have to deal with the nonsense that I present to them now. But I always had a high opinion of what you do, just because it is in such a sweet spot where if I were to shut this place down and get a quote-unquote, “Real job” somewhere, I would hire you. And it's not that I intellectually don't know how to negotiate. Half my consulting now is negotiating large AWS contracts on behalf of AWS customers with AWS. A lot of these things tend to apply and go very hand-in-glove.But there's something to be said for having someone who sees this all the time in a consistent ongoing basis, who is able to be dispassionate. Because when you're coaching someone, it's not you in the same boat. For you, it's okay, you want to have a happy customer, obviously, but for your client, it's suddenly, wow, this is the next stage of my career. This matters. The stakes are infinitely higher for them than they are for you.And that means you have the luxury of taking a step back and recognizing a bad deal when you see one. There is such value to that I can't imagine not engaging you or someone like you the next time that I would go about changing jobs. Although these days, it's probably an acquisition or I finally succumb to a cease and desist. I don't really know that I'm employable anymore.Josh: [laugh]. Yeah, I mean, you said a lot of really interesting things there. I think a common theme—you know, to work with me, there's a short application that people fill out, and very frequently in the application, there are a couple of open-ended questions about you know, how can I help you? What's your number one concern? That kind of stuff.And frequently, they'll say, “Yeah, I've negotiated before and I actually did okay, but I want to work with a professional this time,” is the gist of it, for I think reasons that you mentioned. And one of them is, there's just a difference between negotiating for yourself and feeling all of that pressure and having somebody who can just objectively look at it and say, “No, I think you should ask for this instead.” Or, “No, I don't think that you should give that information to the recruiter.” And the person instead of feeling, you know, personal subjective pressure can just say, “Well, the objective person that I hired and paid money to help me with this says, ‘don't do that,' or ‘do this instead,' and it's easier for me to just trust what they're doing as a professional and let me be a professional at the other things that I'm a professional at.”And so yeah, I think that's a lot of—you know, for some people, it's, “I have no idea how to negotiate. I don't want to screw this up. Please help me, Josh.” And for some people, it's, “Yeah, I've done this before. I did, okay, but I want you here to help me do this.”And that includes people who come back and work with me two or three times. They know the methodology. They've been through it literally with me, and I'm very open about what we're doing and why I'm collaborative with my clients. We're talking about the decisions we make. I will bounce things off of them.I'll say, “Here's what I think we should do. What does your intuition tell you about that? How do you feel about it?” Because it's important to me because they're in the game and I need to know what they think. And they'll come back to me and we'll do it again. They already know the playbook. And I think that's because it's easier to just have somebody who's a professional there to objectively tell you, “You're not asking for enough.” Or, “Did you think about asking for this instead?” Or, “Do you really care about that thing?” Stuff like that.Corey: There is so much value to that, just because it's a what's normal in this? Because I'm sure you've seen before where—I'm probably—I should put this in more of a question, but I already know the answer because I've seen it just from people randomly sending me things out on the internet—of their times for companies say or ask for things that are just absolute clown shoes. It's, I would barely consider it professional at that. It always feels like there's value in being able to talk to someone who sees this all the time who can say, “Hold on. That is absolutely not normal. That is not a reasonable question. That is not an expectation that any sensible person is going to have.” Because the failure mode otherwise is you think it's you.Josh: Yeah, part of my value prop is, you know, I know how to negotiate with companies. I'm not afraid of them. I've negotiated with Fortune 5 companies, come out way ahead—just as you do frequently—and I know the playbook that they're running. But part of it also is, you know, I have a compendium of recruiter responses. I know what they say, I know what their words mean, and so I can say things like, “Oh, here's what they actually mean when they ask you for that.”Or I can say, “That's weird.” Which, you know, if I've done 20 negotiations with this company and all of a sudden a recruiter says something that's weird, that makes my ears perk up and makes me wonder why. And so, I can dig in on my side and try and figure out what's going on, see if we tripped some wire that I didn't see or, you know, something like that. So, that's part of the value too, is just all the reps that I've had, even like you said, I'm sure that you would do a wonderful job negotiating; I've talked to you about negotiating online and off, and I know that you know the game, you know how to do it, for your day job but also for compensation. But I probably have more reps negotiating with those companies than you do and therefore my compendium is a little bit deeper, so there might be things that I could recognize that you would not recognize that I could see, right, in the similar way that in your negotiation world that there are things that I certainly would not recognize that you would catch on to.And I think that can be a very valuable thing. There could be something a recruiter says where I recognize, “Aha. That's a technical term or that's a key phrase that we can grab onto. And that is an opportunity to get more.”Corey: Or, “What are you making now?” It's like, yes, that's the industry accepted one free pass that's screwing the candidate. Yeah—Josh: Right.Corey: —let's not do that.Josh: Right. And we're—here's how to sidestep it and here's what happens when they ask for it for the fourth time, and here's what happens when they say the magic words and, you know, all that stuff. So yeah, a lot of it is just getting reps. It started with let me just run my playbook and then as I run the playbook, I get more data every time I do it, and I get to learn what the edge cases look like, and how to spot, you know, weird funky stuff coming from recruiters and that sort of thing.Corey: One aspect of this that has been, I guess, capturing my imagination since you first talked to me about it, and I am certain I'm going to butcher this into something that sounds insulting and demeaning, which sort of cuts against the entire point. Specifically, the idea of a positive language, or, the term you used was ‘Positively Persuasive.' What is that? Because it sounds like it's just someone who's setting me up, like, waving raw steak in front of a tiger, like, “Please maul me on this.” But there is more to it than that.Josh: [laugh]. Yeah, so this is something that, to be honest with you, I have done almost intuitively throughout my career, but certainly as a salary negotiation coach. And what it is, is a tendency to use positive, meaning, you know, not negative words. So like, essentially, if you're familiar at all with improv, which I would say probably half of the people listening probably have some idea what I'm talking about, you take improv classes, and they teach you an exercise called Yes, And. And the reason you do Yes, And is, you know, Corey says something wacky and I could shut it down.I could say, “That's not true.” You know, “My hair isn't red.” And then we're done improving. But if Corey says, “Josh your hair is red,” even if my hair is not red and I say, “Yes, and… it's on fire right now,” then we have something going, right? And so, using those positive words—yes, and is a positive way of responding to that—opens up a further dialog and also makes it easier for you to engage with me in that improvisation. In a way, a negotiation is an improvisation; they're all going to be different.A business conversation is going to be an improvisation. It's rare that you're going to have a conversation where you could write the script completely before the conversation starts. Often there will be an opportunity to improv, to do something different. And so, positively persuasive is essentially my way of thinking about how to use those positive words to accomplish an objective while building rapport with the person that you're talking to, and leaving the door open for that kind of positive collaboration and improvisation where you can work together with your co-party, with the person that you're talking to in the negotiation. And so, that's super abstract, and a concrete example of this would be for example, in a counteroffer email.Frequently people will, kind of unsolicited, just send me their counteroffer emails. “I'm writing up this email. What do you think?” Somebody on my newsletter or my email list or something. And sometimes they're okay, and sometimes it's like, they're giving an ultimatum and they're saying, “You promised this when we first talked on the phone and you're not giving me that. You offered me this and I want what you offered to start with.”And they're using all these negative words: “You promised this and didn't give it to me.” “That's not what I expected.” Whereas in the counteroffers that I'm writing, it says, “Hey, thanks for the offer.” Starts right away with something that looks like a throwaway line, a platitude, but really what it is is saying, “Hey, we're on the same team here. We're collaborating. Thanks for the offer. I appreciate it and I hope you're having a good week so far.”And then as it goes on, it says, “Here are the reasons that I'm super valuable to your team. I can't wait to join this team and, you know, express that value.” And then, “You offered $100,000. I would be more comfortable if we could settle on $115,000.” And so, that's a counteroffer. In some cases, the counter will be more than 15%. That's kind of a middle-of-the-road one, but the way I say it is, “I would be more comfortable if,” and so there's no sort of in-your-face, there's no ultimatum, there's no fist pounding on the desk—Corey: There's no, “No.” There's no, “This is not acceptable.” There's no, “I won't accept this.” It's a very soft approach that generally doesn't put people on edge.Josh: Puts it—it not only doesn't put them on edge, but you're sort of putting your arm around them saying, “Hey, you know, I'd be more comfortable if we could do this.” And they're like, “Okay, you know, let me see what I can do for you.” So, you're not making—you're not turning them into, you know, an enemy combatant; you're turning them into a collaborator. And now it's you and then working together to try to make you comfortable so that you can join their team. So, that's a subtle thing that happens in a counteroffer email and numerous other places.But that's the idea is that when you can, you're choosing positive language so that your requests will be received better, so you build rapport with the person that you're negotiating with, and so that they perceive you to be a collaborator and not an opponent.Corey: It sounds hokey, but I've also watched it work. It's weird in that we hear about things like this, we think, “Oh, that wouldn't work on me at all,” except it the evidence very clearly shows that it does. There's a reason that some people are considered charismatic and I think this is a large part of it. And I also wonder, I mean, you focus on salary negotiation for high earners, and that, historically at least, as included, you know, a fair few number of software developers and whatnot. And these days, let's be very clear that communicating what you want, clearly, concisely, and in an understandable way that something or someone can action is such a lost foreign skill for some of these people that they call the entire field ‘prompt engineering' because just communicate clearly is apparently a microaggression when you ask an engineer to do it without giving it a fancy name. Improved communication really feels like it has been part of a dawning awareness lately that, wait, this is actually important, not just one of those box-checking items that you say so that people don't spit in your food.Josh: I think you're a hundred percent right about that. I mean, it's interesting is you think about, you know, forms of communication that we have kind of experienced over the past, you know, however many years. But you know, at first, there was no writing, over, you know, thousands of years ago, or whatever, it was just all kind of oral tradition. And then we had writing and it was, like, long-form writing. And then, you know, fast forward to today and it's like you're sending a text with two letters and that means something right, or I'm about to head to my friend's house, and I text him three letters: OMW, right?It's like, extremely terse, direct, and to the point. And there is a place for that, I think. I think that efficiency probably has some benefits. I mean, there's not a lot of reason for me to spend six minutes, you know, writing a text to tell somebody that I'm heading to their house. But on the other hand, I think that sort of concision, that terse writing can also lose a lot in translation, and as we're using more media that look like Slack, or Discord, or these other chat-based ways of communicating—including email, by the way; I mean, email can be a place where you can be as terse, or I guess, as pleonastic as you'd like—and you get more and more words in there.And so, I think it's important to be intentional with those words in contexts where tone and meaning and intent can matter. And a lot of that is in interpersonal communication. And again, it's about how messages are received and what you're conveying. I use a lot of—this is [laugh] not directly related—I use a lot of emoji and emoticons and stuff like that and I do that because I'm trying to convey tone in a medium that doesn't really facilitate it, right?If I'm talking to you, you and I can see each other's faces right now, so you know if I'm being sarcastic, or telling a joke, or being very serious. And so, in emails, I'll put a smiley face. And that's me saying, “Hey, I'm not laying this on real thick. I'm just letting you know.” Right? So anyway, there are so many media that are available to us now that make it hard to convey tone that I think a lot of it is you've got to be intentional with your tone.Corey: I have worked with more people over the course of my career that have what I've taken the call being the asshole-in-email problem, where I have—I think these people are just these absolute jerks. They are completely onerous to deal with and I despise dealing with these people, but then I'll sit down with them and they are the nicest people and they are incredibly competent and effective. They just have a challenge where whatever they write an email, it sounds like there's an implicit, “Listen up here dickhead…” that they're starting the email with.Josh: [laugh]. Yeah.Corey: And, “You know what your problem is…” may as well be how they open these things. And it feels like effectively communicating and tone is becoming something of a lost art. I've talked to multiple people now who will wind up using Chat-Gippity to construct the bones of a work email and then they'll just change a sentence or two in the center that actually is the substantive thing that they want to send so it winds up handling all the window-dressing there. Now, I'm wondering what the other side is going to look like when you have someone using Chat-Gippity to paste a work email into it. It's like, “Okay, strip out the flattery. What are they actually asking from me here?” So, you effectively have, like, an API layer of padding provided by computers, where you could just like, say, the direct thing, but it comes with all the flowerly accouterments that has become expected in business correspondence.Josh: Yeah. I mean, I love everything that you said there. It's true. I mean, I've worked with people in the past where they would send me an email, or I would email with them frequently and then we were talking in person, I realized that oh, I totally misread what they were saying. Like, I misread what they meant to say, I misread what their outcome, their preferred outcome was, and it's because the tone is just lost in email.And I don't think it was necessarily due to any sort of deficiency on their side. It was on—they have a way of communicating, I have a way of perceiving communications, and they were different, and so the message that I got was different. So, I think a lot of what I'm talking about with positively persuasive is how do I communicate in a way where it is not ambiguous, where it is very clear what I'm saying, what my intent is, what my tone is. And sometimes, like you said, [laugh] use ChatGPT to, like, strip out the flattery. I put the flattery in because I want them to know, like, “Look, I know that you're a person. You and I are on the same team here. We're working together.”So, a lot of my emails will open with, “Hey, hope you're having a good day.” And it's like, do I care if they're having a good day? Yeah, but I don't need to say that out loud. The reason I'm saying it out loud is I want them—the opposite of everything you just described where I want them to read that email and think, “Okay, Josh isn't coming at me. Even if he does have critiques of something that I'm doing, or he has a suggestion to improve something, he's coming at it from the place of, ‘Hey, I hope you're having a good day so far.'” Whatever I say at the beginning of the email.And so, that's filler, a hundred percent, but it's filler with a purpose that is meant to convey the tone of the email, that is, I'm not coming down on you too hard. I'm trying to convey a message or ask a question and sincerely curious, and can we come together on this to figure out what the solution is or to move forward or to find the next steps or whatever the thing is that we're trying to do?Corey: It feels like this is an area that has massive application beyond the obvious negotiation piece of it, which is fundamentally where we sit down and try and convince people to do a thing that we want them to do that is in our interest. But it's like, okay, well, that's not just negotiation. That is, on some level, a disturbing number of human interactions that we tend to have. Where do you see this being applied? Is it something that just—that you're looking at just through a lens of communicating effectively in a salary negotiation, or does it extend beyond that to your worldview?Josh: I think it can get pretty broad. I mean, as you were describing, I was thinking kind of, as you were talking, like, when else do I use this? And the answer is a lot. But one place that I use this kind of thing a lot is when I'm emailing people who I don't know, and trying to get them to either just give me something or to allow me more leeway than they otherwise necessarily have to allow. And so for—here, I'll give you an example, which is, I recently switched homeowners insurance providers because I live in Florida and homeowner's insurance in Florida is a nightmare.And so, I changed providers. I thought I had crossed all my t's and dotted all my I's, but there was something that fell between the cracks, and that is that the mortgage holder—the bank that holds my mortgage—hadn't sent the premium check to my new insurance provider. They didn't get that memo. And it was essentially my responsibility, but I kind of goofed. So, the bank writes me an email and they say, “Hey, we see you changed providers but we don't have an address for them. We can't send them a check. Can you give it to me?”And so, now I'm—there are two parties that I have to kind of keep on my side. One of them is obviously the bank, but also the insurance provider, who might be mad at me because I'm ten days late on this premium or whatever. So, my emails to them are places where I use this where it's like, I'm basically going to make it so that the person who could get mad at me and cause me some kind of detriment is going to have to do it through a really thick cloud of, “Josh is a nice guy who isn't trying to be a jerk to anybody here. He's not trying to pull one over on anybody. There was an honest mistake that was made, he's just trying to make everything right, and he's hoping that I can help them.”And they're going to have to look at the way that I communicate with them and they're going to have to push through it and say, “Nope. I'm going to be a jerk. I'm going to follow the letter of the law or I'm going to be as punitive as I can be.” That's really hard to do when somebody like me is emailing, say, “Hey, listen, I know that we were supposed to get a check out to you last week. I'm working on it right now. I've already got everything to the bank. It's going to be overnighted to you tonight. Is there anything else I could do to make this easy for you on your side?”And then they're going to be like, “No, just, you know, as soon as we get it, we'll let you know.” Whereas if I'm, like, you know, mad at them or I'm mad at somebody or I'm being a jerk in email, then they don't really have any reason to not be as punitive as they can be to me. And so, that's just—it's a little manipulative, I guess, but it's also the way that I see life, right? Like, I'm like that with everyone, including people who are on the other side of that equation. I'm going to give them grace when I can.And so, it's a way of me saying, “Hey, can you extend some grace to me? I think you're a human being who's on the other side of this and you have a job to do and I understand that, and if you could be a little bit kind to me, that would be great.” And it works almost every time.Corey: This episode is sponsored in part by Panoptica.  Panoptica simplifies container deployment, monitoring, and security, protecting the entire application stack from build to runtime. Scalable across clusters and multi-cloud environments, Panoptica secures containers, serverless APIs, and Kubernetes with a unified view, reducing operational complexity and promoting collaboration by integrating with commonly used developer, SRE, and SecOps tools. Panoptica ensures compliance with regulatory mandates and CIS benchmarks for best practice conformity. Privacy teams can monitor API traffic and identify sensitive data, while identifying open-source components vulnerable to attacks that require patching. Proactively addressing security issues with Panoptica allows businesses to focus on mitigating critical risks and protecting their interests. Learn more about Panoptica today at panoptica.app.Corey: There's value as well, even everyday customer service interactions, if I have a bad customer experience buying something off of Amazon—I know, imagine that.j could that ever happen? Of course not. But in a magical world in which in hypothetically did, I can call up and they answer the phone, I'm probably going to be pretty steamed going into that conversation because this is effort I didn't want to have to deal with. But stop and think about it for a second. Usually, when I call Amazon for a variety of things, it's not Andy Jassy who's answering the phone. Those are atypical moments for me.Instead, it is generally some poor customer service schmo, who is basically given zero amount of autonomy to speak of in the course of their job, and surprisingly, does not set Amazon's strategic priorities for them. And if I unload on this person, maybe I make myself feel better, I've made someone else's day actively worse, but even if you want to set aside the story of being a good person—which I don't suggest people do—but view it in a purely Machiavellian self-serving way, you're still going to have a better outcome if you inspire people to like you by making yourself likable. Because when you're a jerk—and I used to work helpdesk; I remember how this works—Josh: Me, too.Corey: Suddenly, I will fall back on every policy that I can have, “Oh, we're not allowed to sit through a reboot. Bye.” As opposed to, “Eh, [unintelligible 00:22:31] say ever not to, but I'm enjoying this and I want to help you out and make sure you get there, so hang out. Why not?” There are ways people can bend the rules in your favor, but if you give them an excuse to fall back on that, they're not going to go out of their way to help you at all. They're going to make you go through every bit of procedural red tape they can possibly come up with. And again, you've made their day worse and that should not be lost on you. The outcomes are better for everyone when you're a nice person.Josh: As you were talking, it's funny because I remembered, maybe the most frustrated I've ever been talking to customer service. This is several years—many years ago, but I had some student loan stuff going on. I don't even remember specifically what it was, but it had to do with, you know, who was servicing the loan and I'm trying to pay off a loan and I can't get the right person on the phone and they say, you know, “It's this other place that owns that holds the loan.” Or, “You need to call this person,” and I'm getting the runaround and I'm not able to do the thing I want to do.And after I think I've been hung up on, like, three times, and I was really steamed. Like you said, I'm legitimately, like, very frustrated. My voice had been cracking a little bit, which is how I know I'm, like, really getting heated is my [laugh] voice will start to crack a little bit. But I said to the person—and I became conscious in that moment of like, okay, I'm very frustrated. I could say something I regret I could really, like, hurt this person that I'm talking to.As you said, they're just somebody who's a customer service representative for this bank or loan servicer, whoever they were. So, I said something like, “Listen, you can't hear it in the tone of my voice right now, but I need you to know that I'm extremely frustrated and I'm going to [laugh] I'm going to get really upset, and so I'm asking you to help me before I do that before I escalate. I don't want to talk to your manager, but I'm going to ask you to do that if you don't help me right now. And you should know that I'm super frustrated. My voice is not betraying that right now, but understand that I am.”And they snapped in and they were like, “Okay, I get it, I get it,” you know? And right there even as a place where I could have just started shouting at them or whatever it takes, you know, “I want to talk to your manager,” and, “I'm going to escalate,” and all this stuff. And instead, I was like, well, I'm going to give them one last chance, which is, let me just tell them how frustrated I am without using colorful language or mean words. And it worked. It was a subtle thing that actually, I think it got their attention more than anything else. They said, “Oh, this person is really angry. I should actually listen to them.”Corey: Now, there is a dark side to this as well and that is human nature. I have done experiments on this over the years, most notably on Twitter, back when that was the central place people went to, and when I would say something nice about an AWS service, it got in most cases two likes and maybe a bot would retweet it. Whereas if I say, “This AWS service is a piece of garbage,” and I come up with some reason for it, it went around the internet three times and it was misconstrued, with me saying, “The entirety of AWS is terrible.” Not usually, no. There are some frustrating elements, but yeah, there's context. It doesn't fit into a single tweet.The snarky negativity blows up and responds to—and resonates with something in human nature that the people love spreading that around and engaging with it, whereas the happy positivity does not work that way. On Twitter. I've noticed what seems to be the opposite effect on LinkedIn. Snark doesn't do well over there, but almost saccharine-sweet sincerity does. And I don't know what this says about various social media channels or human nature or what. All I know is that I'm confused.Josh: I think you're right. You know, I mean, as you were talking, I was thinking about clickbait, right? Like, there's a reason that clickbait is called what it is, and it's because you read it and you get annoyed or frustrated or angry, and I'm going to hate-read this article right now and I'm going to send it to six friends. There is something in human nature. I mean, you know, we talked—for decades, I've heard about how the local news is our news, “If it bleeds, it leads,” in news, right?We're not talking about how great the planet is or how things—like, this bad thing happened in New Orleans yesterday and you should be really upset about it, or wherever that place happens to be on that particular day. I do think there is something innate in us that allows us to gravitate towards those kinds of things and I have no idea what it is. But it is interesting, as you said, that there are places where either that's frowned upon or there's just a different mode of communication, which tells me that there's something sort of in the cultural water there that causes people to perceive stuff differently in different kinds of social media environments, right? Twitter definitely is a place where things can go pretty negative. And there are other places that are significantly more negative, right, on the internet, if you want to go, they get really bad, and then there's places that are really positive.And it's interesting how it's like a maybe people self-select into those places, but also, I think, you know, I think there's a big difference if you think about, like, who's using Twitter and why and who's using LinkedIn and why. I think that people correctly perceive on LinkedIn that for the most part, you're probably not going to be somebody that's at the top of a bunch of lists to be hired if your whole thing on LinkedIn is just being negative all the time and doom and gloom and snark and that kind of thing. It'll be entertaining to some people, but you're probably not going to get many job offers based on that because people are going to ask, “Do I want to work with this person 24 hours a day?” And they'll read your posts and say, “No,” whereas at least a saccharine sweet person, everybody knows those people who are like that in real life, and they can be I don't know, a little bit much, but also can generally be very good people to work with and it's not difficult to sort of like manage that.Corey: There's a lot that can be done just by having people want to help you. It's weird. Like, I take a look at some of the people that I identify publicly as the nicest in tech—Mark [unintelligible 00:27:48] is a good example. Kelsey Hightower is sort of the canonical example of all of this. These are just genuinely nice people. Ashley Willis, another good example.There are so many different folks out there who are just beacons of positivity. And I look at that, and it's like, first, that is admirable. Second, holy hell that is absolutely not me. No one is ever going to say, “That's what I love about Corey. He's so uplifting and positive all the time.” You know, I do strive to be a better person and inspire others to be better people, but I'm also willing to spare no quarter for corporate tomfoolery either. Which apparently means a lot of people think you're a jerk as a result. I'll take it.Josh: Yeah, I think it's, you know, everybody—that's the nice thing about humans, right, is we're all different. And there are lots of different types of person—if everybody had the same personality, what a boring place that we would live. And that's true for, more or less, any human characteristic. If we were all the same and vanilla, I think it would be pretty boring. So, I think that having really positive people out there is great, and having some people who are snarky is great, and having people who have, you know, an ability to just point out absurdity is great. If everyone is pointing out absurdity all the time, then we're not left with too much.So, I do think it's good that those people are out there and they're very positive. And I think that, you know, even for myself, like, I try to be positive and helpful. Like, we were talking about customer service. I'm like, overly nice to customer service people. I tip more than I should most of the time. And a lot of that is just, you know, that's a human; they have needs and feelings and this is a way for me to be kind to them.And I know most people don't think that way that I do. And I like that. And I think that some people don't think that way and I think that's totally fine, too. I think the variety is the spice of life and I think that makes it interesting and useful. I also think that being intentional with those different modes, having them all available to you, and exercising them in different environments can be, like, a level-up, right? It can be a superpower.You can either be a person with a personality who exercises that same personality all the time, or you can choose to exercise, sort of, different personalities or different ways of communicating or different levels of positivity or negativity in different environments. And I think that makes it even more interesting where you're able to essentially be a chameleon and find the right mode of communication for the environment or the situation that you're in, which can enhance that situation for you or for other people that are around you.Corey: I have to ask, do you find that this is something you do all the time or do you put on your negotiating phrasing the same way that I do when my children accuse me of putting on ‘podcast voice.'Josh: All the time, definitely not. I am aware of it as a way of communicating that's available to me and I do consciously use it a lot of the time. But you know, if I'm just sitting around with my buddies on, you know, Wednesday night watching the game, probably not. And a lot of that is because, you know, part of this is, it's a default to positive because you don't know sort of who's on the other end of the line, whereas if you're communicating with somebody that you've communicated with for hundreds of hours, you don't need all that stuff, you don't need all the tonal indicators and the padding and all that stuff because you know that person. So, a lot of what I'm describing, even like in a salary negotiation, I'm basically working from the default of I don't know the counterparty, I don't know the recruiter, and therefore we're going to default to positive, and that's going to essentially, you know, make things smoother.It's going to remove friction because there are things that I don't know, whereas, you know, if I'm communicating with somebody I know really well for 20 years, we don't need all that stuff. We can—that's where the shorthand can come in handy. It can be really useful because we already know all of the background there. One place that I'm very conscious of this is, you know, every now and then somebody, with a personal friend or somebody that I know, well, I'll have, like, a difficult conversation where they'll say, “Hey, you know, this is something that happened to me recently. Can you help me out?” Or, “This is a difficult thing that I'm going through.”And that's a place where I am very conscious of this and it comes in different ways. One of them is using positive words, but one of them is also just, like, exercising extreme sympathy or empathy if it's appropriate. Which is, again, it's a conscious decision to say, this isn't a time to point out, you know, for example, errors, or like, this person just needs someone that they want to talk to and I'm going to listen to them carefully, I'm going to try to give them reassurance that the situation will be resolved eventually, and that kind of thing, but it's not a time for you know, critique or, you know, negative words or pointing out flaws and that kind of thing. And so, I think that's also kind of a conscious place that I will exercise it. But to answer your question, no, I don't do this all the time.I would say without having ever thought about this before, the less familiar I am with the person or the situation, the more I will default to this, and the more familiar I am with the person or the situation, the less I will default to it. And I will just use more plain, kind of, direct language because that familiarity is there, and it assumes a lot that isn't there when I don't know the person well.Corey: I really want to thank you for taking the time to speak with me about this. Where can people go to learn more?Josh: Maybe follow me on Twitter [laugh], @joshdoody on Twitter.Corey: It's a harder problem these days than it once was.Josh: Yeah. I really paused there. I am pretty active on LinkedIn these days. And fearlesssalarynegotiation.com isn't explicitly about positive language or being positively persuasive, but you'll see even just reading the articles that I write there that underlying most of what I write is this sort of implicit understanding that positivity is the way to make progress and to get closer to what your goals are. So, @joshdoody on Twitter; joshdoody on LinkedIn, of course, and then fearlesssalarynegotiation.com.Corey: And we will, of course, put links to all of this in the show notes. Thank you so much for taking the time to speak with me. I appreciate it.Josh: Thanks for having me on, Corey. This was a lot of fun. I always like talking to you.Corey: I do, too. Josh [laugh] Doody, owner of Fearless Salary Negotiation. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment that rants itself sick, but also only uses positive language.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

When you think of Kubernetes or Docker, I bet empathy is not the first word that comes to mind. Today, I am joined by, Kelsey Hightower whose passion it is to bring empathy to work everyday and we talk about how to reframe our approach to building tools for humans, learning from the physical world, config management, containerization and more. Kelsey earned his CompTIA A+ certification and began his career working at BellSouth installing DSL. He has worked at Puppet Labs, Monsoon Commerce (where he wrote his open source config management library Conf'd ), and currently he is a Distinguished Engineer, Google Cloud.  He is a leading expert and advocate in Kubernetes and is known in the tech community as the explainer and chief of Kubernetes having spoken at many many conferences and even co-founding the Kubernetes-focused KubeCon conference. He is also a published co-author of the book Kubernetes: Up & Running. He likes to say he is a SysAdmin who can code and a big part of his day is spent elevating people. Enjoy our conversation! Connect with Kelsey: Twitter Show notes and helpful resources: Meet Kelsey Kelsey's book: Kubernetes: Up & Running “If there is a problem do what is necessary to solve it no matter what” “You do your best work when you are at your best” Brian Grant - Chief architect of Kubernetes Kim Bannerman - People first empathetic leader “A 10x engineer can make 10 people better - level up the people around you” “Always seek to understand why you do what you do” “Continue to grow by observing the world around you and make adjustments so you can make an impact” Building something cool or solving interesting problems? Want to be on this show? Send me an email at jointhepodcast@unfilteredbuild.com Podcast produced by Unfiltered Build - dream.design.develop.

Kelsey Hightower was a Distinguished Engineer at Google, where he worked on Google Cloud Platform. In this second part of the conversation, we focus on Kelsey's retirement - the financial planning that enabled him to retire at 42, how he got started advising startups and his perspectives on compensation, turning down a substantial offer from Microsoft and meeting Satya Nadella in person. And, of course, plans for the future.

This week we're joined by Solomon Hykes, the creator of Docker. Now he's back with his next big thing called Dagger — CI/CD as code that runs anywhere. We're users of Dagger so check out our codebase if you want to see how it works. On today's show Solomon takes us back to the days of Docker, what it was like on that 10 year journey, his transition from Docker to Dagger, Dagger's community-led growth model, their focus on open source and community, how it works, and even a cameo from Kelsey Hightower to explain how Dagger works.

This week we're joined by Solomon Hykes, the creator of Docker. Now he's back with his next big thing called Dagger — CI/CD as code that runs anywhere. We're users of Dagger so check out our codebase if you want to see how it works. On today's show Solomon takes us back to the days of Docker, what it was like on that 10 year journey, his transition from Docker to Dagger, Dagger's community-led growth model, their focus on open source and community, how it works, and even a cameo from Kelsey Hightower to explain how Dagger works.

Kelsey Hightower was a Distinguished Engineer at Google, where he worked on Google Cloud Platform. In this first part of the conversation, we delve into pivotal moments in Kelsey's career journey ranging from buying his first car by working at mcdonald's after school, to starting his own computer store that turned into a music studio after 6pm, to hacking on python infrastructure with the core developers. Through these stories, we learned a ton about how Kelsey thinks about acquiring new skills - getting paid for it, breaking into the world of open source, navigating corporate politics, building trust within a team, and much more.

This week we discuss RHEL licensing changes, check the vibe of DevOps and some thoughts on programing language. Plus, has ChatGPT already become boring? Runner-up Titles I don't like listening to fellow thought leaders. I listen to myself enough. Dammit, alarm was set for PM A massive failure of one The end of free It's not all smiles and thumbs Goose-cow “I used to, but I don't anymore.” The Podcast Review podcast. Rundown RHEL Furthering the evolution of CentOS Stream (https://www.redhat.com/en/blog/furthering-evolution-centos-stream) Red Hat strikes a crushing blow against RHEL downstreams (https://www.theregister.com/2023/06/23/red_hat_centos_move/) IBM/Red Hat Sparks Anger at GPL ‘breach' as RHEL Source Locked Up (https://devops.com/rhel-gpl-richixbw/) Rocky Strikes Back At Red Hat (https://hackaday.com/2023/06/30/rocky-strikes-back-at-red-hat/) The Suicide Attempt by Red Hat [Opinion] (https://news.itsfoss.com/red-hat-fiasco/) Rant about Red Hat's Licensing Change for REHL (https://youtube.com/watch?v=4fAq6AphRn0&feature=share) Reddit Reddit CEO tells employees that subreddit blackout “will pass” (https://www.theverge.com/2023/6/13/23759559/reddit-internal-memo-api-pricing-changes-steve-huffman) Apollo's Christian Selig explains his fight with Reddit — and why users revolted (https://www.theverge.com/2023/6/13/23759180/reddit-protest-private-apollo-christian-selig-subreddit) Reddit doubles down (https://www.platformer.news/p/reddit-doubles-down?utm_medium=email) Hackers threaten to leak 80GB of confidential data stolen from Reddit (https://techcrunch.com/2023/06/19/hackers-threaten-to-leak-80gb-of-confidential-data-stolen-from-reddit) DevOps Second Wave DevOps (https://www.systeminit.com/blog-second-wave-devops/) Kelsey Hightower Predicts How the Kubernetes Community Will Evolve (https://thenewstack.io/kelsey-hightower-predicts-how-the-kubernetes-community-will-evolve/) Kelsey Hightower Retires (https://twitter.com/kelseyhightower/status/1673366087541600256?s=20) Even the best rides come to an end featuring Kelsey Hightower (https://changelog.com/friends/6) (Podcast) Stack Overflow Developer Survey 2023 (https://survey.stackoverflow.co/2023/) Relevant to your Interests AWS teases mysterious mil-spec ‘Snowblade' server (https://www.theregister.com/2023/06/07/aws_snowblade_military_edge_server/) To fill offices, Google issues ultimatum while Salesforce tries charity (https://www.washingtonpost.com/business/2023/06/08/google-salesforce-return-to-office/) Amazon is pursuing 'too many ideas' and needs to focus on best opportunities (https://www.cnbc.com/2023/06/07/amazon-is-pursuing-too-many-ideas-bernstein-says-in-open-letter.html) There are better places for Amazon to put their capital to work, says Bernstein's Mark Shmulik (https://www.youtube.com/watch?v=j9Z2HeYkl4c) The best password managers for 2023 | Engadget (https://www.engadget.com/best-password-manager-134639599.html?guccounter=1&guce_referrer=aHR0cHM6Ly9uZXdzLmdvb2dsZS5jb20v&guce_referrer_sig=AQAAAIYHiHrsIv_lVu8RNqY46BjFzlgU4pFDBXmk1gQxq2wlQOz02b5tuepColb1KJFoYYwQVWy2SjTUKWVY2oAEMzfkYXlXs97_PE0gpwNUA4RjnDwE_YEm7FB323M9oOBQJNHboj1t77QC9HriDL8cJP-VcplJ5UlJvvwHZRzMn9PC) After a Rocky Year, Zuckerberg Lays Out Meta's Road Map to Employees (https://www.nytimes.com/2023/06/08/technology/mark-zuckerberg-meta.html) Hybrid combines the worst of office and remote work (https://world.hey.com/dhh/hybrid-combines-the-worst-of-office-and-remote-work-d3174e50) Twilio to sell ValueFirst business to Tanla (NYSE:TWLO) (https://seekingalpha.com/news/3978773-twilio-to-sell-valuefirst-business-to-tanla) Jeff Bezos Has Gained $10 on Mystery Purchase of One Amazon Share (https://www.bloomberg.com/news/articles/2023-06-09/billionaire-jeff-bezos-just-bought-one-share-of-amazon-and-no-one-knows-why#xj4y7vzkg) Jeff Bezos Has Gained $10 on Mystery Purchase of One Amazon Share (https://www.bloomberg.com/news/articles/2023-06-09/billionaire-jeff-bezos-just-bought-one-share-of-amazon-and-no-one-knows-why#xj4y7vzkg) CNET's Free Shopping Extension Saves You Time and Money. Give It a Try Today (https://www.cnet.com/tech/services-and-software/use-cnet-shopping-to-seek-out-the-best-deals/) Modular: Our launch & what's next (https://www.modular.com/blog/our-launch-whats-next) Exclusive-Broadcom set to win EU nod for $61 billion VMware deal, sources say (https://finance.yahoo.com/news/exclusive-eu-antitrust-regulators-okay-091426470.html) Amazon is reportedly trying to offer Prime subscribers free cell phone service | Engadget (https://www.engadget.com/amazon-is-reportedly-trying-to-offer-prime-subscribers-free-cell-phone-service-140026387.html) Cloud cost management startup CloudZero lands $32M investment (https://techcrunch.com/2023/06/12/cloud-cost-management-startup-cloudzero-lands-32m-investment/) Twitter stiffs Google (https://www.platformer.news/p/twitter-stiffs-google) Open Sourcing AWS Cedar Is a Game Changer for IAM (https://thenewstack.io/open-sourcing-aws-cedar-is-a-game-changer-for-iam/) Oracle beats on top and bottom lines as cloud revenue jumps (https://www.cnbc.com/2023/06/12/oracle-orcl-q4-earnings-report-2023.html) America to halt $68.7bn Microsoft takeover of Activision Blizzard (https://www.thetimes.co.uk/article/america-to-halt-68-7bn-microsoft-takeover-of-activision-blizzard-d80jvxm6f) Meta's Open-Source 'MusicGen' AI Is Like ChatGPT for Tunes (https://gizmodo.com/meta-open-source-musicgen-ai-like-chatgpt-for-music-1850528986) Google's return-to-office crackdown gets backlash from some employees: (https://www.cnbc.com/2023/06/13/google-rto-crackdown-gets-backlash-check-my-work-not-my-badge.html) Forrester Wave Integrated Software Delivery Platforms, Q2 2023 (https://www.forrester.com/blogs/the-forrester-wave-integrated-software-delivery-platforms-q2-2023-say-goodbye-to-the-devops-tax/) The economic potential of generative AI: The next productivity frontier (https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axioslogin&stream=top) 1 big thing: Where AI's productivity revolution will strike first (https://www.axios.com/newsletters/axios-login-da50d8f4-fb10-4952-af38-01163b9acbd3.html?chunk=0&utm_term=emshare#story0) For the first time in almost 30 years, a company other than IBM received the most US patents (https://finance.yahoo.com/news/first-time-almost-30-years-192900742.html) AMD stock pops on potential Amazon superchip deal, CEO bullishness (https://finance.yahoo.com/news/amd-stock-pops-on-potential-amazon-superchip-deal-ceo-bullishness-112819279.html) Amazon cloud services back up after big outage hits thousands of users (https://www.reuters.com/technology/amazon-says-multiple-cloud-services-down-users-2023-06-13/) Proven Practices for Developing a Multicloud Strategy | Amazon Web Services (https://aws.amazon.com/blogs/enterprise-strategy/proven-practices-for-developing-a-multicloud-strategy/) 40 photos from inside Metropolitan Park—the first phase of Amazon's HQ2 (https://www.aboutamazon.com/news/amazon-offices/amazon-headquarters-hq2-arlington-virginia-photos?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axioslogin&stream=top) The Forrester Wave™: Integrated Software Delivery Platforms, Q2 2023 (https://page.gitlab.com/forrester-wave-integrated-software-delivery-platforms-2023.html?utm_source=cote&utm_campaign=devrel&utm_content=newsletter20230615&utm_medium=email) AWS US-EAST-1 wobbled after Lambda management issues spread (https://www.theregister.com/2023/06/14/aws_us_east_1_brownout/) The store is for people, but the storefront is for robots (https://www.theverge.com/23753963/google-seo-shopify-small-business-ai) A Look Back at Q1 '23 Public Cloud Software Earnings (https://cloudedjudgement.substack.com/p/a-look-back-at-q1-23-public-cloud?utm_source=post-email-title&publication_id=56878&post_id=128805971&isFreemail=true&utm_medium=email) Apple Is Taking On Apples in a Truly Weird Trademark Battle (https://www.wired.com/story/apple-vs-apples-trademark-battle/) Apple Watch alerts 29-year-old Cincinnati woman to blood clot in lungs while sleeping (https://9to5mac.com/2023/06/19/apple-watch-blood-clot-sleeping/) Return to Office Enters the Desperation Phase (https://www.nytimes.com/2023/06/20/business/return-to-office-remote-work.html) Critical 'nOAuth' Flaw in Microsoft Azure AD Enabled Complete Account Takeover (https://thehackernews.com/2023/06/critical-noauth-flaw-in-microsoft-azure.html) What happened to Oracle? Why do they keep acquiring companies? (https://www.tiktok.com/t/ZT8JH8X5Y/) How an ex-Googler is reimagining the oldest computing interface of all (https://www.fastcompany.com/90907013/warp-terminal-command-line) WFH 4 ever (https://www.axios.com/2023/06/23/work-from-home-remote-workplace-trend) Databricks picks up MosaicML, an OpenAI competitor, for $1.3B (https://techcrunch.com/2023/06/26/databricks-picks-up-mosaicml-an-openai-competitor-for-1-3b/) Introducing LLaMA: A foundational, 65-billion-parameter language model (https://ai.facebook.com/blog/large-language-model-llama-meta-ai/?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axioslogin&stream=top) AI's next conflict is between open and closed (https://www.axios.com/newsletters/axios-login-e2a8f546-c6e2-421c-a7dc-0996d64bf312.html?chunk=0&utm_term=emshare#story0) Amazon is investing another $7.8B in Ohio-based cloud computing operations, (https://apnews.com/article/amazon-aws-ohio-data-center-investment-e35c8b726269b6b78ce05854f9f31d27) A new law protecting pregnant workers is about to take effect (https://www.axios.com/2023/06/22/pregnant-workers-fairness-act-2023-explain) Amazon launches AWS AppFabric to help customers connect their SaaS apps (https://techcrunch.com/2023/06/27/amazon-launches-aws-appfabric-to-help-customers-connect-their-saas-apps/?guccounter=1&guce_referrer=aHR0cHM6Ly9uZXdzLmdvb2dsZS5jb20v&guce_referrer_sig=AQAAAGcA6HN4Zti_4dKCpuMURoiAkkQ_uR0GBWFOG215KnmRsvryBDclj9SjWv-95R0yA0wFRXevcP-HUdwk-E3ZyR3d23rc5VGVCNXFGK5L3mAPvoEOJxRs6WZFKQvDUBIyw5V3NpdWGkkQ-fXDh4Rijfdp2l_ekJTxepVJjoYJSyKz) State of Kubernetes Cost Optimization Report (https://inthecloud.withgoogle.com/state-of-kubernetes-cost-optimization-report/dl-cd.html) FTC Request, Answered: How Cloud Providers Do Business (https://www.lastweekinaws.com/blog/ftc-request-answered-how-cloud-providers-do-business/) OrbStack · Fast, light, simple Docker & Linux on macOS (https://orbstack.dev/?ref=console.dev) Surprise! You Work for Amazon. (https://www.theatlantic.com/technology/archive/2023/06/amazon-hub-delivery-last-mile/674559/) btop - the htop alternative (https://haydenjames.io/btop-the-htop-alternative/) We Raised A Bunch Of Money (https://fly.io/blog/we-raised-a-bunch-of-money/) Twitter has stopped paying its Google Cloud bills (https://www.businessinsider.com/elon-musk-twitter-stopped-paying-google-cloud-bills-money-platformer-2023-6) Report: 2022 Microsoft Azure Revenue Less Than Estimated, Half That Of AWS | CRN (https://www.crn.com/news/cloud/report-2022-microsoft-azure-revenue-less-than-estimated-half-that-of-aws) Google Domains shutting down, assets sold and being migrated to Squarespace (https://9to5google.com/2023/06/15/google-domains-squarespace/) Is Waze next? (https://www.theverge.com/2023/6/27/23776329/google-waze-layoffs-ads) The real story of how Facebook almost acquired Waze, but we ended up with Google (https://post.news/@/noam/2RTRvTNNxSCQb3yNjqa0DPfr1Yk) Google killed its Iris augmented-reality smart glasses (https://www.businessinsider.com/google-ar-iris-augmented-reality-smart-glasses-2023-6) Who killed Google Reader? (https://www.theverge.com/23778253/google-reader-death-2013-rss-social) Mark Zuckerberg is ready to fight Elon Musk in a cage match (https://www.theverge.com/2023/6/21/23769263/mark-zuckerberg-elon-musk-fight-cage-match-worldstar) IBM to Acquire Apptio Inc., (https://newsroom.ibm.com/2023-06-26-IBM-to-Acquire-Apptio-Inc-,-Providing-Actionable-Financial-and-Operational-Insights-Across-Enterprise-IT) IBM Re-ups On FinOps With Its Apptio Acquisition (https://www.forrester.com/blogs/ibm-re-ups-on-finops-with-its-apptio-acquisition/) Nonsense Texas Bans Kids From Social Media Without Mom and Dad's Ok (https://gizmodo.com/texas-law-kids-social-media-ban-without-parents-consent-1850540419) Summer intern's commute goes viral: She flies from South Carolina to New Jersey (https://www.cnn.com/2023/06/15/business/tiktok-summer-intern-commute/index.html) Twitter evicted from office amid lawsuits over unpaid rent and cleaning bills (https://arstechnica.com/tech-policy/2023/06/judge-ruled-twitter-must-be-evicted-from-colorado-office-over-unpaid-rent/) Fishing crew denied $3.5M in prize money after 600-pound marlin DQ'd in tournament (https://nypost.com/2023/06/19/massive-marlin-dqd-in-big-rock-blue-marlin-tournament-over-mutilation/) 'World's Largest' Buc-ee's store opens (https://www.wyff4.com/article/bucees-world-largest-tennessee/44343171) now on Bus-ee's Map (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjgoKnr-vX_AhVslGoFHeeBBREQFnoECBgQAQ&url=https%3A%2F%2Fwww.google.com%2Fmymaps%2Fviewer%3Fmid%3D1IBCXZDU73Q5pjsDWVkoQ5O0GLoUd-bg%26hl%3Den&usg=AOvVaw3joznC0GgnH9dU-z_XGEw5&opi=89978449) Magic Mushrooms. LSD. Ketamine. The Drugs That Power Silicon Valley. (https://www.wsj.com/articles/silicon-valley-microdosing-ketamine-lsd-magic-mushrooms-d381e214) 'Fueled by inflation': USPS stamp prices are increasing soon. Here's what to know. (https://www.usatoday.com/story/money/2023/06/28/stamp-price-increase-usps/70363626007/) At least a year younger on paper: South Korea makes changes to age-counting law (https://www.usatoday.com/story/news/world/2023/06/28/south-korea-changes-age-counting-law/70363453007/) Sony just spilled confidential PlayStation information because of a Sharpie (https://www.theverge.com/2023/6/28/23777298/sony-ftc-microsoft-confidential-documents-marker-pen-scanner-oops) Australia legalises psychedelics for mental health (https://www.bbc.co.uk/news/world-australia-66072427) Listener Feedback Let's Get To The News | Craig Box | Substack (https://craigbox.substack.com/) When You Don't Have a Seat At the (Managed Database) Table (https://unskript.com/blog/when-you-don-t-have-a-seat-at-the-(managed-database)-table> Show more) by Doug Sillars Conferences August 8th Kubernetes Community Day Australia (https://community.cncf.io/events/details/cncf-kcd-australia-presents-kubernetes-community-day-australia-2023/) in Sydney, Matt attending. August 21st to 24th SpringOne (https://springone.io/) & VMware Explore US (https://www.vmware.com/explore/us.html), in Las Vegas. Explore EU CFP is open. Sep 6th to 7th DevOpsDays Des Moines (https://devopsdays.org/events/2023-des-moines/welcome/), Coté speaking. Sep 18th to 19th SHIFT (https://shift.infobip.com/) in Zadar, Coté speaking. October 6, 2023, KCD Texas 2023 (https://community.cncf.io/events/details/cncf-kcd-texas-presents-kcd-texas-2023/), CFP Closes: August 30, 2023 Jan 29, 2024 to Feb 1, 2024 That Conference Texas CFP Open 6/1 - 8/21 (https://that.us/call-for-counselors/tx/2024/) If you want your conference mentioned, let's talk media sponsorships. SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Get a SDT Sticker! Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us on Twitch (https://www.twitch.tv/sdtpodcast), Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/), Mastodon (https://hachyderm.io/@softwaredefinedtalk), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk) and YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured). Use the code SDT to get $20 off Coté's book, Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Become a sponsor of Software Defined Talk (https://www.softwaredefinedtalk.com/ads)! Recommendations Brandon: Cloudcast: MidYear 2023 Update (https://www.thecloudcast.net/2023/07/midyear-2023-update.html) Governments Building Software This Is What Happens When Governments Build Software - Odd Lots (https://omny.fm/shows/odd-lots/this-is-what-happens-when-governments-build-softwa) The Book I Wish Every Policymaker Would Read (https://www.nytimes.com/2023/06/06/opinion/ezra-klein-podcast-jennifer-pahlka.html) Tony Hsieh and the Emptiness of the Tech-Mogul Myth (https://www.newyorker.com/news/our-columnists/tony-hsieh-and-the-emptiness-of-the-tech-mogul-myth) (via Coté's newsletter) Coté: Hand Mirror app (https://handmirror.app), also in Setapp (https://setapp.com) if you have that. If Books could Kill (https://www.patreon.com/IfBooksPod) Photo Credits Header (https://unsplash.com/photos/5yuRImxKOcU) Artwork (https://www.freepnglogos.com/images/linux-22615.html)

Kelsey Hightower (@kelseyhightower) announced his retirement from Google this week. What comes next is unknown, but let's take a few moments to appreciate the lessons he passed along to everyone.SHOW: 732CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW SPONSORS:GCore - Global Hosting, CDN, Edge and Cloud ServicesUse promocode “CLOUDCAST” to receive a €100 credit on Gcore servicesCloudZero – Cloud Cost Visibility and Savings​​CloudZero provides immediate and ongoing savings with 100% visibility into your total cloud spendFind "Breaking Analysis Podcast with Dave Vellante" on Apple, Google and SpotifyKeep up to data with Enterprise Tech with theCUBESHOW NOTES:Kubernetes the Hard Way KubeCon 2023 AMA - From Community to CustomersTHE WORLD IS FULL OF SMART PEOPLE - BUT NOT ALL SMART IDEAS GET COMMUNICATEDLots of people in the DevRel world want(ed) to be like Kelsey HightowerHe was a little bit like Keiser Sozer; he left a small footprint behind.HOW DID KELSEY HIGHTOWER MAKE AN IMPACT ON YOUR TECH CAREER?He spoke from a position of authority, that he created and demonstratedHe believed that community was bigger (and more important) than companyHe seemed to believe in the rule of “2 vs 1” - listen more than talkHe didn't take himself too seriouslyHe connected with crowds of people, and individual peopleHe highlighted the good more often than he criticized the badHe was always demonstrating the art of the possibleFEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet

On Monday, Kelsey Hightower announced his retirement from Google. On Tuesday, he sat down with us to discuss why, how & what's next. Along the way, Kelsey teaches us how not to suck at work, analyzes his magical demos, fights off the haters (again) & opines on System Initiative, Dagger & 37Signals moving off the cloud.

On Monday, Kelsey Hightower announced his retirement from Google. On Tuesday, he sat down with us to discuss why, how & what's next. Along the way, Kelsey teaches us how not to suck at work, analyzes his magical demos, fights off the haters (again) & opines on System Initiative, Dagger & 37Signals moving off the cloud.

Kelsey Hightower and host Mike Chenetz discuss monolith vs micro-services and everything in-between! What are the right tools for the job? Who should care about operations? Who should care about development? Should it be a combined role? Find out the answers to all of these things and more.

Kelsey Hightower is a pragmatic person, in love with technology but never forgetting that technology should always be in the service of humankind. His rational view on the business-technology interplay and scrutinizing approach to finding value in technology restore sanity in this crazy world often driven solely by technology hype cycles. His ability to dissect business problems and break them down to technology fundamentals never ceases to amaze me. We talked about different perspectives of value, how to approach the ever-changing technical landscape, why it is essential to master technical fundamentals, and much more.Subscribe to 0800-DEVOPS newsletter here.This interview is featured in 0800-DEVOPS #47 - Talking about value with Kelsey Hightower.[Check out podcast chapters if available on your podcast platform or use links below](00:01)Introduction(00:35)The relationship between technology and business in creating value for the customers(04:48)Is technology moving to fast?(08:05)Are we becoming hype driven?(11:38)How does he assess new technology in terms of value?(15:52)Achieving the balance between business and technology(23:52)A career in tech is about the willingness to learn a different tool when the time comes

A scathing takedown of Serverless... By Amazon? We react to this strange revelation and more.

In this episode of Kubernetes Bytes, Ryan and Bhavin sit down with Platform engineering expert Luca Galante, head of product at Humanitec to discuss all things Platform engineering, what is it, and how it is different from DevOps. They also discuss when it makes sense to have a platform engineering team and how you can get started on your journey by building internal development platforms. Show Notes: - What is platform engineering? - What is an internal developer platform? - What is Dynamic Configuration Management? - Platform Engineering community - PlatformCon 2023 - Luca's LinkedIn and Twitter Cloud Native News: InfluxData Series E round - https://techcrunch.com/2023/02/13/influxdata-lands-51m-to-grow-its-time-series-database-offerings Cloud Native Security Con - https://youtube.com/playlist?list=PLj6h78yzYM2NQ-Zi_k5qVmZyxSmLBzM6V Adrian's Platform engineering blog - https://adrianco.medium.com/platform-engineering-teams-done-right-b3b3d4a8ad23 Amazon EKS Anywhere on SNOW - https://aws.amazon.com/blogs/containers/new-amazon-eks-anywhere-on-snow Kelsey Hightower affirms databases on k8s - https://twitter.com/kelseyhightower/status/1624081136073994240 NetApp discontinues astra data store https://blocksandfiles.com/2023/01/25/netapp-astra-data-store/ Edge computing trends 2023 - https://technologymagazine.com/articles/the-cutting-edge-edge-computing-trends-to-watch-in-2023

Benjamin Elder is a Senior Software Engineer at Google, a Kubernetes SIG Testing Chair & Tech Lead, and a Kubernetes Steering Committee member. In this episode we got to chat with Benjamin about the new kubernetes registry migration from k8s.gcr.io to registry.k8s.io. We also had an opportunity to discuss the community, the various SIG's (Special Interest Groups) Benjamin is involved with the amount of work needed to drive the project forward.   Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod Chatter of the week Google Developer Experts program. ChatGPT. OpenAI Case Study. Kubernetes Jobs API. Job Tracking, to Support Massively Parallel Batch Workloads, Is GA in kubernetes 1.26. Stateful apps on Kubernetes. Kelsey Hightower's take on Databases on Kubernetes twitter space. Kubernetes Resources Model News of the week Linkerd published a 2022 recap The CNCF Cloud Native Maturity Model The CNCF Cloud Native Maturity Model website Using Amazon EKS with Google Workspace identities CNCF Ambassador 2.0 program Cloud Native Security Con NA 2023 (website - recordings) The CNCF important updates for KubeCon + CloudNativeCon 2023 and co-located events Kubernetes 1.26 news: https://kubernetes.io/blog/ Eviction policy for unhealthy pods guarded by PodDisruptionBudgets:https://kubernetes.io/blog/2023/01/06/unhealthy-pod-eviction-policy-for-pdbs/ Retroactive Default StorageClass: https://kubernetes.io/blog/2023/01/05/retroactive-default-storage-class/ Alpha support for cross-namespace storage data sources: https://kubernetes.io/blog/2023/01/02/cross-namespace-data-sources-alpha/ Advancements in Kubernetes Traffic Engineering: https://kubernetes.io/blog/2022/12/30/advancements-in-kubernetes-traffic-engineering/ Job Tracking, to Support Massively Parallel Batch Workloads, Is Generally Available: https://kubernetes.io/blog/2022/12/29/scalable-job-tracking-ga/ CPUManager goes GA: https://kubernetes.io/blog/2022/12/27/cpumanager-ga/ Pod Scheduling Readiness: https://kubernetes.io/blog/2022/12/26/pod-scheduling-readiness-alpha/ Support for Passing Pod fsGroup to CSI Drivers At Mount Time: https://kubernetes.io/blog/2022/12/23/kubernetes-12-06-fsgroup-on-mount/ GA Support for Kubelet Credential Providers: https://kubernetes.io/blog/2022/12/22/kubelet-credential-providers/ Introducing Validating Admission Policies: https://kubernetes.io/blog/2022/12/20/validating-admission-policies-alpha/ Device Manager graduates to GA: https://kubernetes.io/blog/2022/12/19/devicemanager-ga/ Non-Graceful Node Shutdown Moves to Beta: https://kubernetes.io/blog/2022/12/16/kubernetes-1-26-non-graceful-node-shutdown-beta/ Alpha API For Dynamic Resource Allocation: https://kubernetes.io/blog/2022/12/15/dynamic-resource-allocation/ Windows HostProcess Containers Are Generally Available: https://kubernetes.io/blog/2022/12/13/windows-host-process-containers-ga/ We're now signing our binary release artifacts!: https://kubernetes.io/blog/2022/12/12/kubernetes-release-artifact-signing/   Links from the interview Benjamin Elder LinkedIn Github Twitter Kubernetes Steering Committee Kubernetes SIG Testing Kubernetes IN Docker (KIND) Benjamin on the podcast episode 96 Paris Pittman LinkedIN Twitter Kubernetes registry move from k8s.gcr.io to registry.k8s.io Archeio is the tool used to redirect to GCR or S3 depending on the client. The design of how requests are handled. Doc detailing the background of this migration. Kubernetes SIG Contributor Experience Kubernetes Slack channel

We talk about how Next is bringing image components, server components, and in-house analytics via split bee—and bundling them all together with Turbopack, powered by Rust, our Developer Survey most loved language of 2022.Guillermo Rauch is the CEO and cofounder of Vercel and cocreator of Next.js, an open-source React framework that helps developers build fast, lightweight web applications. The most recent version is Next.js 13. You can find Guillermo on LinkedIn.We previously talked with Guillermo about the security risks of laziness, how Next.js mixes static site and SPA functions, and the front-end trends that get him excited. Kelsey Hightower is the Principal Developer Advocate at Google Cloud. Find him on Twitter or GitHub, or read about his very personal history with Kubernetes.Kelsey has also distinguished himself on our podcast before. Kyle Mitofsky is a Senior Software Engineer at Stack Overflow. Find him on Twitter or GitHub.

Happy Holidays from all of us at Google! This week, hosts Carter Morgan, Stephanie Wong, and Max Saltonstall are sharing their favorite moments from the year! From great partnerships with national companies, new releases in some of your favorite Google software tools, and a trillion digits of pi, we're breaking down some 2022 highlights and introducing special guest Podcast Producer Kevin McCormack to help with a fun podcast trivia game! Carter Morgan Carter Morgan is Developer Advocate for Google Cloud, where he creates and hosts content on Google's Youtube channel, co-hosts several Google Cloud podcasts, and designs courses like the Udacity course “Scalable Microservices with Kubernetes” he co-created with Kelsey Hightower. Carter Morgan is an international standup comedian, who's approach of creating unique moments with the audience in front of him has seen him perform all over the world, including in Paris, London, the Melbourne International Comedy Festival with Joe White. And in 2019, and the 2019 Edinburgh Fringe Festival. Previously, he was a programmer for the USAF and Microsoft. Stephanie Wong Stephanie Wong is a Developer Advocate focusing on online content across all Google Cloud products. She's a host of the GCP Podcast and the Where the Internet Lives podcast, along with many GCP Youtube video series. She is the winner of a 2021 Webby Award for her content about data centers. Previously she was a Customer Engineer at Google and at Oracle. Outside of her tech life she is a former pageant queen and hip hop dancer and has an unhealthy obsession with dogs. Max Saltonstall Max Saltonstall is a Developer Relations Engineer at Google Cloud. He is a father, teacher, storyteller, speaker, educator, nefarious villain, game designer, juggler, and is only part zombie. Cool things of the week Boost medical discoveries with AlphaFold on Vertex AI blog 6 common mistakes to avoid in RESTful web API Design blog Marketing Analytics With Google Cloud blog Our Favorite Episodes of 2022 Stephanie's Favorites GCP Podcast Episode 290: Resiliency at Shopify with Camilo Lopez and Tai Dickerson podcast GCP Podcast Episode 315: Cloud Functions (2nd gen) with Jaisen Mathai and Sara Ford podcast GCP Podcast Episode 307: FinOps with Joe Daly podcast Carter's Favorites GCP Podcast Episode 308: New Pi World Record with Emma Haruka Iwao and Sara Ford podcast GCP Podcast Episode 327: ML/AI Data Science for Data Analytics with Jed Dougherty and Dan Darnell podcast GCP Podcast Episode 289: Cloud Security Megatrends with Phil Venables podcast Max's Favorites GCP Podcast Episode 316: Google Cloud for Higher Education with Laurie White and Aaron Yeats podcast GCP Podcast Episode 317: Launching Products at Google Cloud with Anita Kibunguchy-Grant and Gabe Weiss podcast GCP Podcast Episode 325: Digital Sovereignty with Archana Ramamoorthy and Julien Blanchez podcast Stephanie's Honorable Mentions GCP Podcast Episode 323: Next 2022 with Forrest Brazeal and Stephanie Wong podcast GCP Podcast Episode 298: Celebrating Women's History Month with Vidya Nagarajan Raman podcast Carter's Honorable Mentions GCP Podcast Episode 312: Managed Service for Prometheus with Lee Yanco and Ashish Kumar podcast GCP Podcast Episode 290: Resiliency at Shopify with Camilo Lopez and Tai Dickerson podcast Max's Honorable Mentions GCP Podcast Episode 326: Assured Workloads with Key Access Justifications with Bryce Buffaloe and Seth Denney | Google Cloud Platform Podcast podcast Hosts Stephanie Wong, Carter Morgan and Max Saltonstall

About KelseyKelsey Hightower is the Principal Developer Advocate at Google, the co-chair of KubeCon, the world's premier Kubernetes conference, and an open source enthusiast. He's also the co-author of Kubernetes Up & Running: Dive into the Future of Infrastructure.Links: Twitter: @kelseyhightower Company site: Google.com Book: Kubernetes Up & Running: Dive into the Future of Infrastructure TranscriptAnnouncer: Hello and welcome to Screaming in the Cloud, with your host Cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of Cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is brought to us by our friends at Pinecone. They believe that all anyone really wants is to be understood, and that includes your users. AI models combined with the Pinecone vector database let your applications understand and act on what your users want… without making them spell it out. Make your search application find results by meaning instead of just keywords, your personalization system make picks based on relevance instead of just tags, and your security applications match threats by resemblance instead of just regular expressions. Pinecone provides the cloud infrastructure that makes this easy, fast, and scalable. Thanks to my friends at Pinecone for sponsoring this episode. Visit Pinecone.io to understand more.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. I'm joined this week by Kelsey Hightower, who claims to be a principal developer advocate at Google, but based upon various keynotes I've seen him in, he basically gets on stage and plays video games like Tetris in front of large audiences. So I assume he is somehow involved with e-sports. Kelsey, welcome to the show.Kelsey: You've outed me. Most people didn't know that I am a full-time e-sports Tetris champion at home. And the technology thing is just a side gig.Corey: Exactly. It's one of those things you do just to keep the lights on, like you're waiting to get discovered, but in the meantime, you're waiting table. Same type of thing. Some people wait tables you more or less a sling Kubernetes, for lack of a better term.Kelsey: Yes.Corey: So let's dive right into this. You've been a strong proponent for a long time of Kubernetes and all of its intricacies and all the power that it unlocks and I've been pretty much the exact opposite of that, as far as saying it tends to be over complicated, that it's hype-driven and a whole bunch of other, shall we say criticisms that are sometimes bounded in reality and sometimes just because I think it'll be funny when I put them on Twitter. Where do you stand on the state of Kubernetes in 2020?Kelsey: So, I want to make sure it's clear what I do. Because when I started talking about Kubernetes, I was not working at Google. I was actually working at CoreOS where we had a competitor Kubernetes called Fleet. And Kubernetes coming out kind of put this like fork in our roadmap, like where do we go from here? What people saw me doing with Kubernetes was basically learning in public. Like I was really excited about the technology because it's attempting to solve a very complex thing. I think most people will agree building a distributed system is what cloud providers typically do, right? With VMs and hypervisors. Those are very big, complex distributed systems. And before Kubernetes came out, the closest I'd gotten to a distributed system before working at CoreOS was just reading the various white papers on the subject and hearing stories about how Google has systems like Borg tools, like Mesa was being used by some of the largest hyperscalers in the world, but I was never going to have the chance to ever touch one of those unless I would go work at one of those companies.So when Kubernetes came out and the fact that it was open source and I could read the code to understand how it was implemented, to understand how schedulers actually work and then bonus points for being able to contribute to it. Those early years, what you saw me doing was just being so excited about systems that I attended to build on my own, becoming this new thing just like Linux came up. So I kind of agree with you that a lot of people look at it as a more of a hype thing. They're looking at it regardless of their own needs, regardless of understanding how it works and what problems is trying to solve that. My stance on it, it's a really, really cool tool for the level that it operates in, and in order for it to be successful, people can't know that it's there.Corey: And I think that might be where part of my disconnect from Kubernetes comes into play. I have a background in ops, more or less, the grumpy Unix sysadmin because it's not like there's a second kind of Unix sysadmin you're ever going to encounter. Where everything in development works in theory, but in practice things pan out a little differently. I always joke that ops is the difference between theory and practice. In theory, devs can do everything and there's no ops needed. In practice, well it's been a burgeoning career for a while. The challenge with this is Kubernetes at times exposes certain levels of abstraction that, sorry certain levels of detail that generally people would not want to have to think about or deal with, while papering over other things with other layers of abstraction on top of it. That obscure, valuable troubleshooting information from a running something in an operational context. It absolutely is a fascinating piece of technology, but it feels today like it is overly complicated for the use a lot of people are attempting to put it to. Is that a fair criticism from where you sit?Kelsey: So I think the reason why it's a fair criticism is because there are people attempting to run their own Kubernetes cluster, right? So when we think about the cloud, unless you're in OpenStack land, but for the people who look at the cloud and you say, "Wow, this is much easier." There's an API for creating virtual machines and I don't see the distributed state store that's keeping all of that together. I don't see the farm of hypervisors. So we don't necessarily think about the inherent complexity into a system like that, because we just get to use it. So on one end, if you're just a user of a Kubernetes cluster, maybe using something fully managed or you have an ops team that's taking care of everything, your interface of the system becomes this Kubernetes configuration language where you say, "Give me a load balancer, give me three copies of this container running." And if we do it well, then you'd think it's a fairly easy system to deal with because you say, "kubectl, apply," and things seem to start running.Just like in the cloud where you say, "AWS create this VM, or G cloud compute instance, create." You just submit API calls and things happen. I think the fact that Kubernetes is very transparent to most people is, now you can see the complexity, right? Imagine everyone driving with the hood off the car. You'd be looking at a lot of moving things, but we have hoods on cars to hide the complexity and all we expose is the steering wheel and the pedals. That car is super complex but we don't see it. So therefore we don't attribute as complexity to the driving experience.Corey: This to some extent feels it's on the same axis as serverless, with just a different level of abstraction piled onto it. And while I am a large proponent of serverless, I think it's fantastic for a lot of Greenfield projects. The constraints inherent to the model mean that it is almost completely non-tenable for a tremendous number of existing workloads. Some developers like to call it legacy, but when I hear the term legacy I hear, "it makes actual money." So just treating it as, "Oh, it's a science experiment we can throw into a new environment, spend a bunch of time rewriting it for minimal gains," is just not going to happen as companies undergo digital transformations, if you'll pardon the term.Kelsey: Yeah, so I think you're right. So let's take Amazon's Lambda for example, it's a very opinionated high-level platform that assumes you're going to build apps a certain way. And if that's you, look, go for it. Now, one or two levels below that there is this distributed system. Kubernetes decided to play in that space because everyone that's building other platforms needs a place to start. The analogy I like to think of is like in the mobile space, iOS and Android deal with the complexities of managing multiple applications on a mobile device, security aspects, app stores, that kind of thing. And then you as a developer, you build your thing on top of those platforms and APIs and frameworks. Now, it's debatable, someone would say, "Why do we even need an open-source implementation of such a complex system? Why not just everyone moved to the cloud?" And then everyone that's not in a cloud on-premise gets left behind.But typically that's not how open source typically works, right? The reason why we have Linux, the precursor to the cloud is because someone looked at the big proprietary Unix systems and decided to re-implement them in a way that anyone could run those systems. So when you look at Kubernetes, you have to look at it from that lens. It's the ability to democratize these platform layers in a way that other people can innovate on top. That doesn't necessarily mean that everyone needs to start with Kubernetes, just like not everyone needs to start with the Linux server, but it's there for you to build the next thing on top of, if that's the route you want to go.Corey: It's been almost a year now since I made an original tweet about this, that in five years, no one will care about Kubernetes. So now I guess I have four years running on that clock and that attracted a bit of, shall we say controversy. There were people who thought that I meant that it was going to be a flash in the pan and it would dry up and blow away. But my impression of it is that in, well four years now, it will have become more or less system D for the data center, in that there's a bunch of complexity under the hood. It does a bunch of things. No-one sensible wants to spend all their time mucking around with it in most companies. But it's not something that people have to think about in an ongoing basis the way it feels like we do today.Kelsey: Yeah, I mean to me, I kind of see this as the natural evolution, right? It's new, it gets a lot of attention and kind of the assumption you make in that statement is there's something better that should be able to arise, giving that checkpoint. If this is what people think is hot, within five years surely we should see something else that can be deserving of that attention, right? Docker comes out and almost four or five years later you have Kubernetes. So it's obvious that there should be a progression here that steals some of the attention away from Kubernetes, but I think where it's so new, right? It's only five years in, Linux is like over 20 years old now at this point, and it's still top of mind for a lot of people, right? Microsoft is still porting a lot of Windows only things into Linux, so we still discuss the differences between Windows and Linux.The idea that the cloud, for the most part, is driven by Linux virtual machines, that I think the majority of workloads run on virtual machines still to this day, so it's still front and center, especially if you're a system administrator managing BDMs, right? You're dealing with tools that target Linux, you know the Cisco interface and you're thinking about how to secure it and lock it down. Kubernetes is just at the very first part of that life cycle where it's new. We're all interested in even what it is and how it works, and now we're starting to move into that next phase, which is the distro phase. Like in Linux, you had Red Hat, Slackware, Ubuntu, special purpose distros.Some will consider Android a special purpose distribution of Linux for mobile devices. And now that we're in this distro phase, that's going to go on for another 5 to 10 years where people start to align themselves around, maybe it's OpenShift, maybe it's GKE, maybe it's Fargate for EKS. These are now distributions built on top of Kubernetes that start to add a little bit more opinionation about how Kubernetes should be pushed together. And then we'll enter another phase where you'll build a platform on top of Kubernetes, but it won't be worth mentioning that Kubernetes is underneath because people will be more interested on the thing above.Corey: I think we're already seeing that now, in terms of people no longer really care that much what operating system they're running, let alone with distribution of that operating system. The things that you have to care about slip below the surface of awareness and we've seen this for a long time now. Originally to install a web server, it wound up taking a few days and an intimate knowledge of GCC compiler flags, then RPM or D package and then yum on top of that, then ensure installed, once we had configuration management that was halfway decent.Then Docker run, whatever it is. And today feels like it's with serverless technologies being what they are, it's effectively a push a file to S3 or it's equivalent somewhere else and you're done. The things that people have to be aware of and the barrier to entry continually lowers. The downside to that of course, is that things that people specialize in today and effectively make very lucrative careers out of are going to be not front and center in 5 to 10 years the way that they are today. And that's always been the way of technology. It's a treadmill to some extent.Kelsey: And on the flip side of that, look at all of the new jobs that are centered around these cloud-native technologies, right? So you know, we're just going to make up some numbers here, imagine if there were only 10,000 jobs around just Linux system administration. Now when you look at this whole Kubernetes landscape where people are saying we can actually do a better job with metrics and monitoring. Observability is now a thing culturally that people assume you should have, because you're dealing with these distributed systems. The ability to start thinking about multi-regional deployments when I think that would've been infeasible with the previous tools or you'd have to build all those tools yourself. So I think now we're starting to see a lot more opportunities, where instead of 10,000 people, maybe you need 20,000 people because now you have the tools necessary to tackle bigger projects where you didn't see that before.Corey: That's what's going to be really neat to see. But the challenge is always to people who are steeped in existing technologies. What does this mean for them? I mean I spent a lot of time early in my career fighting against cloud because I thought that it was taking away a cornerstone of my identity. I was a large scale Unix administrator, specifically focusing on email. Well, it turns out that there aren't nearly as many companies that need to have that particular skill set in house as it did 10 years ago. And what we're seeing now is this sort of forced evolution of people's skillsets or they hunker down on a particular area of technology or particular application to try and make a bet that they can ride that out until retirement. It's challenging, but at some point it seems that some folks like to stop learning, and I don't fully pretend to understand that. I'm sure I will someday where, "No, at this point technology come far enough. We're just going to stop here, and anything after this is garbage." I hope not, but I can see a world in which that happens.Kelsey: Yeah, and I also think one thing that we don't talk a lot about in the Kubernetes community, is that Kubernetes makes hyper-specialization worth doing because now you start to have a clear separation from concerns. Now the OS can be hyperfocused on security system calls and not necessarily packaging every programming language under the sun into a single distribution. So we can kind of move part of that layer out of the core OS and start to just think about the OS being a security boundary where we try to lock things down. And for some people that play at that layer, they have a lot of work ahead of them in locking down these system calls, improving the idea of containerization, whether that's something like Firecracker or some of the work that you see VMware doing, that's going to be a whole class of hyper-specialization. And the reason why they're going to be able to focus now is because we're starting to move into a world, whether that's serverless or the Kubernetes API.We're saying we should deploy applications that don't target machines. I mean just that step alone is going to allow for so much specialization at the various layers because even on the networking front, which arguably has been a specialization up until this point, can truly specialize because now the IP assignments, how networking fits together, has also abstracted a way one more step where you're not asking for interfaces or binding to a specific port or playing with port mappings. You can now let the platform do that. So I think for some of the people who may be not as interested as moving up the stack, they need to be aware that the number of people we need being hyper-specialized at Linux administration will definitely shrink. And a lot of that work will move up the stack, whether that's Kubernetes or managing a serverless deployment and all the configuration that goes with that. But if you are a Linux, like that is your bread and butter, I think there's going to be an opportunity to go super deep, but you may have to expand into things like security and not just things like configuration management.Corey: Let's call it the unfulfilled promise of Kubernetes. On paper, I love what it hints at being possible. Namely, if I build something that runs well on top of Kubernetes than we truly have a write once, run anywhere type of environment. Stop me if you've heard that one before, 50,000 times in our industry... or history. But in practice, as has happened before, it seems like it tends to fall down for one reason or another. Now, Amazon is famous because for many reasons, but the one that I like to pick on them for is, you can't say the word multi-cloud at their events. Right. That'll change people's perspective, good job. The people tend to see multi-cloud are a couple of different lenses.I've been rather anti multi-cloud from the perspective of the idea that you're setting out day one to build an application with the idea that it can be run on top of any cloud provider, or even on-premises if that's what you want to do, is generally not the way to proceed. You wind up having to make certain trade-offs along the way, you have to rebuild anything that isn't consistent between those providers, and it slows you down. Kubernetes on the other hand hints at if it works and fulfills this promise, you can suddenly abstract an awful lot beyond that and just write generic applications that can run anywhere. Where do you stand on the whole multi-cloud topic?Kelsey: So I think we have to make sure we talk about the different layers that are kind of ready for this thing. So for example, like multi-cloud networking, we just call that networking, right? What's the IP address over there? I can just hit it. So we don't make a big deal about multi-cloud networking. Now there's an area where people say, how do I configure the various cloud providers? And I think the healthy way to think about this is, in your own data centers, right, so we know a lot of people have investments on-premises. Now, if you were to take the mindset that you only need one provider, then you would try to buy everything from HP, right? You would buy HP store's devices, you buy HP racks, power. Maybe HP doesn't sell air conditioners. So you're going to have to buy an air conditioner from a vendor who specializes in making air conditioners, hopefully for a data center and not your house.So now you've entered this world where one vendor does it make every single piece that you need. Now in the data center, we don't say, "Oh, I am multi-vendor in my data center." Typically, you just buy the switches that you need, you buy the power racks that you need, you buy the ethernet cables that you need, and they have common interfaces that allow them to connect together and they typically have different configuration languages and methods for configuring those components. The cloud on the other hand also represents the same kind of opportunity. There are some people who really love DynamoDB and S3, but then they may prefer something like BigQuery to analyze the data that they're uploading into S3. Now, if this was a data center, you would just buy all three of those things and put them in the same rack and call it good.But the cloud presents this other challenge. How do you authenticate to those systems? And then there's usually this additional networking costs, egress or ingress charges that make it prohibitive to say, "I want to use two different products from two different vendors." And I think that's-Corey: ...winds up causing serious problems.Kelsey: Yes, so that data gravity, the associated cost becomes a little bit more in your face. Whereas, in a data center you kind of feel that the cost has already been paid. I already have a network switch with enough bandwidth, I have an extra port on my switch to plug this thing in and they're all standard interfaces. Why not? So I think the multi-cloud gets lost in the chew problem, which is the barrier to entry of leveraging things across two different providers because of networking and configuration practices.Corey: That's often the challenge, I think, that people get bogged down in. On an earlier episode of this show we had Mitchell Hashimoto on, and his entire theory around using Terraform to wind up configuring various bits of infrastructure, was not the idea of workload portability because that feels like the windmill we all keep tilting at and failing to hit. But instead the idea of workflow portability, where different things can wind up being interacted with in the same way. So if this one division is on one cloud provider, the others are on something else, then you at least can have some points of consistency in how you interact with those things. And in the event that you do need to move, you don't have to effectively redo all of your CICD process, all of your tooling, et cetera. And I thought that there was something compelling about that argument.Kelsey: And that's actually what Kubernetes does for a lot of people. For Kubernetes, if you think about it, when we start to talk about workflow consistency, if you want to deploy an application, queue CTL, apply, some config, you want the application to have a load balancer in front of it. Regardless of the cloud provider, because Kubernetes has an extension point we call the cloud provider. And that's where Amazon, Azure, Google Cloud, we do all the heavy lifting of mapping the high-level ingress object that specifies, "I want a load balancer, maybe a few options," to the actual implementation detail. So maybe you don't have to use four or five different tools and that's where that kind of workload portability comes from. Like if you think about Linux, right? It has a set of system calls, for the most part, even if you're using a different distro at this point, Red Hat or Amazon Linux or Google's container optimized Linux.If I build a Go binary on my laptop, I can SCP it to any of those Linux machines and it's going to probably run. So you could call that multi-cloud, but that doesn't make a lot of sense because it's just because of the way Linux works. Kubernetes does something very similar because it sits right on top of Linux, so you get the portability just from the previous example and then you get the other portability and workload, like you just stated, where I'm calling kubectl apply, and I'm using the same workflow to get resources spun up on the various cloud providers. Even if that configuration isn't one-to-one identical.Corey: This episode is sponsored in part by our friends at Uptycs, because they believe that many of you are looking to bolster your security posture with CNAPP and XDR solutions. They offer both cloud and endpoint security in a single UI and data model. Listeners can get Uptycs for up to 1,000 assets through the end of 2023 (that is next year) for $1. But this offer is only available for a limited time on UptycsSecretMenu.com. That's U-P-T-Y-C-S Secret Menu dot com.Corey: One thing I'm curious about is you wind up walking through the world and seeing companies adopting Kubernetes in different ways. How are you finding the adoption of Kubernetes is looking like inside of big E enterprise style companies? I don't have as much insight into those environments as I probably should. That's sort of a focus area for the next year for me. But in startups, it seems that it's either someone goes in and rolls it out and suddenly it's fantastic, or they avoid it entirely and do something serverless. In large enterprises, I see a lot of Kubernetes and a lot of Kubernetes stories coming out of it, but what isn't usually told is, what's the tipping point where they say, "Yeah, let's try this." Or, "Here's the problem we're trying to solve for. Let's chase it."Kelsey: What I see is enterprises buy everything. If you're big enough and you have a big enough IT budget, most enterprises have a POC of everything that's for sale, period. There's some team in some pocket, maybe they came through via acquisition. Maybe they live in a different state. Maybe it's just a new project that came out. And what you tend to see, at least from my experiences, if I walk into a typical enterprise, they may tell me something like, "Hey, we have a POC, a Pivotal Cloud Foundry, OpenShift, and we want some of that new thing that we just saw from you guys. How do we get a POC going?" So there's always this appetite to evaluate what's for sale, right? So, that's one case. There's another case where, when you start to think about an enterprise there's a big range of skillsets. Sometimes I'll go to some companies like, "Oh, my insurance is through that company, and there's ex-Googlers that work there." They used to work on things like Borg, or something else, and they kind of know how these systems work.And they have a slightly better edge at evaluating whether Kubernetes is any good for the problem at hand. And you'll see them bring it in. Now that same company, I could drive over to the other campus, maybe it's five miles away and that team doesn't even know what Kubernetes is. And for them, they're going to be chugging along with what they're currently doing. So then the challenge becomes if Kubernetes is a great fit, how wide of a fit it isn't? How many teams at that company should be using it? So what I'm currently seeing as there are some enterprises that have found a way to make Kubernetes the place where they do a lot of new work, because that makes sense. A lot of enterprises to my surprise though, are actually stepping back and saying, "You know what? We've been stitching together our own platform for the last five years. We had the Netflix stack, we got some Spring Boot, we got Console, we got Vault, we got Docker. And now this whole thing is getting a little more fragile because we're doing all of this glue code."Kubernetes, We've been trying to build our own Kubernetes and now that we know what it is and we know what it isn't, we know that we can probably get rid of this kind of bespoke stack ourselves and just because of the ecosystem, right? If I go to HashiCorp's website, I would probably find the word Kubernetes as much as I find the word Nomad on their site because they've made things like Console and Vault become first-class offerings inside of the world of Kubernetes. So I think it's that momentum that you see across even People Oracle, Juniper, Palo Alto Networks, they're all have seem to have a Kubernetes story. And this is why you start to see the enterprise able to adopt it because it's so much in their face and it's where the ecosystem is going.Corey: It feels like a lot of the excitement and the promise and even the same problems that Kubernetes is aimed at today, could have just as easily been talked about half a decade ago in the context of OpenStack. And for better or worse, OpenStack is nowhere near where it once was. It would felt like it had such promise and such potential and when it didn't pan out, that left a lot of people feeling relatively sad, burnt out, depressed, et cetera. And I'm seeing a lot of parallels today, at least between what was said about OpenStack and what was said about Kubernetes. How do you see those two diverging?Kelsey: I will tell you the big difference that I saw, personally. Just for my personal journey outside of Google, just having that option. And I remember I was working at a company and we were like, "We're going to roll our own OpenStack. We're going to buy a free BSD box and make it a file server. We're going all open sources," like do whatever you want to do. And that was just having so many issues in terms of first-class integrations, education, people with the skills to even do that. And I was like, "You know what, let's just cut the check for VMware." We want virtualization. VMware, for the cost and when it does, it's good enough. Or we can just actually use a cloud provider. That space in many ways was a purely solved problem. Now, let's fast forward to Kubernetes, and also when you get OpenStack finished, you're just back where you started.You got a bunch of VMs and now you've got to go figure out how to build the real platform that people want to use because no one just wants a VM. If you think Kubernetes is low level, just having OpenStack, even OpenStack was perfect. You're still at square one for the most part. Maybe you can just say, "Now I'm paying a little less money for my stack in terms of software licensing costs," but from an extraction and automation and API standpoint, I don't think OpenStack moved the needle in that regard. Now in the Kubernetes world, it's solving a huge gap.Lots of people have virtual machine sprawl than they had Docker sprawl, and when you bring in this thing by Kubernetes, it says, "You know what? Let's reign all of that in. Let's build some first-class abstractions, assuming that the layer below us is a solved problem." You got to remember when Kubernetes came out, it wasn't trying to replace the hypervisor, it assumed it was there. It also assumed that the hypervisor had APIs for creating virtual machines and attaching disc and creating load balancers, so Kubernetes came out as a complementary technology, not one looking to replace. And I think that's why it was able to stick because it solved a problem at another layer where there was not a lot of competition.Corey: I think a more cynical take, at least one of the ones that I've heard articulated and I tend to agree with, was that OpenStack originally seemed super awesome because there were a lot of interesting people behind it, fascinating organizations, but then you wound up looking through the backers of the foundation behind it and the rest. And there were something like 500 companies behind it, an awful lot of them were these giant organizations that ... they were big e-corporate IT enterprise software vendors, and you take a look at that, I'm not going to name anyone because at that point, oh will we get letters.But at that point, you start seeing so many of the patterns being worked into it that it almost feels like it has to collapse under its own weight. I don't, for better or worse, get the sense that Kubernetes is succumbing to the same thing, despite the CNCF having an awful lot of those same backers behind it and as far as I can tell, significantly more money, they seem to have all the money to throw at these sorts of things. So I'm wondering how Kubernetes has managed to effectively sidestep I guess the open-source miasma that OpenStack didn't quite manage to avoid.Kelsey: Kubernetes gained its own identity before the foundation existed. Its purpose, if you think back from the Borg paper almost eight years prior, maybe even 10 years prior. It defined this problem really, really well. I think Mesos came out and also had a slightly different take on this problem. And you could just see at that time there was a real need, you had choices between Docker Swarm, Nomad. It seems like everybody was trying to fill in this gap because, across most verticals or industries, this was a true problem worth solving. What Kubernetes did was played in the exact same sandbox, but it kind of got put out with experience. It's not like, "Oh, let's just copy this thing that already exists, but let's just make it open."And in that case, you don't really have your own identity. It's you versus Amazon, in the case of OpenStack, it's you versus VMware. And that's just really a hard place to be in because you don't have an identity that stands alone. Kubernetes itself had an identity that stood alone. It comes from this experience of running a system like this. It comes from research and white papers. It comes after previous attempts at solving this problem. So we agree that this problem needs to be solved. We know what layer it needs to be solved at. We just didn't get it right yet, so Kubernetes didn't necessarily try to get it right.It tried to start with only the primitives necessary to focus on the problem at hand. Now to your point, the extension interface of Kubernetes is what keeps it small. Years ago I remember plenty of meetings where we all got in rooms and said, "This thing is done." It doesn't need to be a PaaS. It doesn't need to compete with serverless platforms. The core of Kubernetes, like Linux, is largely done. Here's the core objects, and we're going to make a very great extension interface. We're going to make one for the container run time level so that way people can swap that out if they really want to, and we're going to do one that makes other APIs as first-class as ones we have, and we don't need to try to boil the ocean in every Kubernetes release. Everyone else has the ability to deploy extensions just like Linux, and I think that's why we're avoiding some of this tension in the vendor world because you don't have to change the core to get something that feels like a native part of Kubernetes.Corey: What do you think is currently being the most misinterpreted or misunderstood aspect of Kubernetes in the ecosystem?Kelsey: I think the biggest thing that's misunderstood is what Kubernetes actually is. And the thing that made it click for me, especially when I was writing the tutorial Kubernetes The Hard Way. I had to sit down and ask myself, "Where do you start trying to learn what Kubernetes is?" So I start with the database, right? The configuration store isn't Postgres, it isn't MySQL, it's Etcd. Why? Because we're not trying to be this generic data stores platform. We just need to store configuration data. Great. Now, do we let all the components talk to Etcd? No. We have this API server and between the API server and the chosen data store, that's essentially what Kubernetes is. You can stop there. At that point, you have a valid Kubernetes cluster and it can understand a few things. Like I can say, using the Kubernetes command-line tool, create this configuration map that stores configuration data and I can read it back.Great. Now I can't do a lot of things that are interesting with that. Maybe I just use it as a configuration store, but then if I want to build a container platform, I can install the Kubernetes kubelet agent on a bunch of machines and have it talk to the API server looking for other objects you add in the scheduler, all the other components. So what that means is that Kubernetes most important component is its API because that's how the whole system is built. It's actually a very simple system when you think about just those two components in isolation. If you want a container management tool that you need a scheduler, controller, manager, cloud provider integrations, and now you have a container tool. But let's say you want a service mesh platform. Well in a service mesh you have a data plane that can be Nginx or Envoy and that's going to handle routing traffic. And you need a control plane. That's going to be something that takes in configuration and it uses that to configure all the things in a data plane.Well, guess what? Kubernetes is 90% there in terms of a control plane, with just those two components, the API server, and the data store. So now when you want to build control planes, if you start with the Kubernetes API, we call it the API machinery, you're going to be 95% there. And then what do you get? You get a distributed system that can handle kind of failures on the back end, thanks to Etcd. You're going to get our backs or you can have permission on top of your schemas, and there's a built-in framework, we call it custom resource definitions that allows you to articulate a schema and then your own control loops provide meaning to that schema. And once you do those two things, you can build any platform you want. And I think that's one thing that it takes a while for people to understand that part of Kubernetes, that the thing we talk about today, for the most part, is just the first system that we built on top of this.Corey: I think that's a very far-reaching story with implications that I'm not entirely sure I am able to wrap my head around. I hope to see it, I really do. I mean you mentioned about writing Learn Kubernetes the Hard Way and your tutorial, which I'll link to in the show notes. I mean my, of course, sarcastic response to that recently was to register the domain Kubernetes the Easy Way and just re-pointed to Amazon's ECS, which is in no way shape or form Kubernetes and basically has the effect of irritating absolutely everyone as is my typical pattern of behavior on Twitter. But I have been meaning to dive into Kubernetes on a deeper level and the stuff that you've written, not just the online tutorial, both the books have always been my first port of call when it comes to that. The hard part, of course, is there's just never enough hours in the day.Kelsey: And one thing that I think about too is like the web. We have the internet, there's webpages, there's web browsers. Web Browsers talk to web servers over HTTP. There's verbs, there's bodies, there's headers. And if you look at it, that's like a very big complex system. If I were to extract out the protocol pieces, this concept of HTTP verbs, get, put, post and delete, this idea that I can put stuff in a body and I can give it headers to give it other meaning and semantics. If I just take those pieces, I can bill restful API's.Hell, I can even bill graph QL and those are just different systems built on the same API machinery that we call the internet or the web today. But you have to really dig into the details and pull that part out and you can build all kind of other platforms and I think that's what Kubernetes is. It's going to probably take people a little while longer to see that piece, but it's hidden in there and that's that piece that's going to be, like you said, it's going to probably be the foundation for building more control planes. And when people build control planes, I think if you think about it, maybe Fargate for EKS represents another control plane for making a serverless platform that takes to Kubernetes API, even though the implementation isn't what you find on GitHub.Corey: That's the truth. Whenever you see something as broadly adopted as Kubernetes, there's always the question of, "Okay, there's an awful lot of blog posts." Getting started to it, learn it in 10 minutes, I mean at some point, I'm sure there are some people still convince Kubernetes is, in fact, a breakfast cereal based upon what some of the stuff the CNCF has gotten up to. I wouldn't necessarily bet against it socks today, breakfast cereal tomorrow. But it's hard to find a decent level of quality, finding the certain quality bar of a trusted source to get started with is important. Some people believe in the hero's journey, story of a narrative building.I always prefer to go with the morons journey because I'm the moron. I touch technologies, I have no idea what they do and figure it out and go careening into edge and corner cases constantly. And by the end of it I have something that vaguely sort of works and my understanding's improved. But I've gone down so many terrible paths just by picking a bad point to get started. So everyone I've talked to who's actually good at things has pointed to your work in this space as being something that is authoritative and largely correct and given some of these people, that's high praise.Kelsey: Awesome. I'm going to put that on my next performance review as evidence of my success and impact.Corey: Absolutely. Grouchy people say, "It's all right," you know, for the right people that counts. If people want to learn more about what you're up to and see what you have to say, where can they find you?Kelsey: I aggregate most of outward interactions on Twitter, so I'm @KelseyHightower and my DMs are open, so I'm happy to field any questions and I attempt to answer as many as I can.Corey: Excellent. Thank you so much for taking the time to speak with me today. I appreciate it.Kelsey: Awesome. I was happy to be here.Corey: Kelsey Hightower, Principal Developer Advocate at Google. I'm Corey Quinn. This is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple podcasts. If you've hated this podcast, please leave a five-star review on Apple podcasts and then leave a funny comment. Thanks.Announcer: This has been this week's episode of Screaming in the Cloud. You can also find more Core at screaminginthecloud.com or wherever fine snark is sold.Announcer: This has been a HumblePod production. Stay humble.

This year at VMware Explore the Virtually Speaking Podcast caught up with Google Distinguished Engineer Kelsey Hightower. Kelsey discusses the secure software supply chain, service oriented networking, and the role of the virtual machine in the context of containers and serverless. Read more

About ChenChen Goldberg is GM and Vice President of Engineering at Google Cloud, where she leads the Cloud Runtimes (CR) product area, helping customers deliver greater value, effortlessly. The CR  portfolio includes both Serverless and Kubernetes based platforms on Google Cloud, private cloud and other public clouds. Chen is a strong advocate for customer empathy, building products and solutions that matter. Chen has been core to Google Cloud's open core vision since she joined the company six years ago. During that time, she has led her team to focus on helping development teams increase their agility and modernize workloads. Prior to joining Google, Chen wore different hats in the tech industry including leadership positions in IT organizations, SI teams and SW product development, contributing to Chen's broad enterprise perspective. She enjoys mentoring IT talent both in and outside of Google. Chen lives in Mountain View, California, with her husband and three kids. Outside of work she enjoys hiking and baking.Links Referenced: Twitter: https://twitter.com/GoldbergChen LinkedIn: https://www.linkedin.com/in/goldbergchen/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Forget everything you know about SSH and try Tailscale. Imagine if you didn't need to manage PKI or rotate SSH keys every time someone leaves. That'd be pretty sweet, wouldn't it? With Tailscale SSH, you can do exactly that. Tailscale gives each server and user device a node key to connect to its VPN, and it uses the same node key to authorize and authenticate SSH.Basically you're SSHing the same way you manage access to your app. What's the benefit here? Built-in key rotation, permissions as code, connectivity between any two devices, reduce latency, and there's a lot more, but there's a time limit here. You can also ask users to reauthenticate for that extra bit of security. Sounds expensive?Nope, I wish it were. Tailscale is completely free for personal use on up to 20 devices. To learn more, visit snark.cloud/tailscale. Again, that's snark.cloud/tailscaleCorey: Welcome to Screaming in the Cloud, I'm Corey Quinn. When I get bored and the power goes out, I find myself staring at the ceiling, figuring out how best to pick fights with people on the internet about Kubernetes. Because, well, I'm basically sad and have a growing collection of personality issues. My guest today is probably one of the best people to have those arguments with. Chen Goldberg is the General Manager of Cloud Runtimes and VP of Engineering at Google Cloud. Chen, Thank you for joining me today.Chen: Thank you so much, Corey, for having me.Corey: So, Google has been doing a lot of very interesting things in the cloud, and the more astute listener will realize that interesting is not always necessarily a compliment. But from where I sit, I am deeply vested in the idea of a future where we do not have a cloud monoculture. As I've often said, I want, “What cloud should I build something on in five to ten years?” To be a hard question to answer, and not just because everything is terrible. I think that Google Cloud is absolutely a bright light in the cloud ecosystem and has been for a while, particularly with this emphasis around developer experience. All of that said, Google Cloud is sort of a big, unknowable place, at least from the outside. What is your area of responsibility? Where do you start? Where do you stop? In other words, what can I blame you for?Chen: Oh, you can blame me for a lot of things if you want to. I [laugh] might not agree with that, but that's—Corey: We strive for accuracy in these things, though.Chen: But that's fine. Well, first of all, I've joined Google about seven years ago to lead the Kubernetes and GKE team, and ever since, continued at the same area. So evolved, of course, Kubernetes, and Google Kubernetes Engine, and leading our hybrid and multi-cloud strategy as well with technologies like Anthos. And now I'm responsible for the entire container runtime, which includes Kubernetes and the serverless solutions.Corey: A while back, I, in fairly typical sarcastic form, wound up doing a whole inadvertent start of a meme where I joked about there being 17 ways to run containers on AWS. And then as that caught on, I wound up listing out 17 services you could use to do that. A few months went past and then I published a sequel of 17 more services you can use to run Kubernetes. And while that was admittedly tongue-in-cheek, it does lead to an interesting question that's ecosystem-wide. If I look at Google Cloud, I have Cloud Run, I have GKE, I have GCE if I want to do some work myself.It feels like more and more services are supporting Docker in a variety of different ways. How should customers and/or people like me—though, I am sort of a customer as well since I do pay you folks every month—how should we think about containers and services in which to run them?Chen: First of all, I think there's a lot of credit that needs to go to Docker that made containers approachable. And so, Google has been running containers forever. Everything within Google is running on containers, even our VMs, even our cloud is running on containers, but what Docker did was creating a packaging mechanism to improve developer velocity. So, that's on its own, it's great. And one of the things, by the way, that I love about Google Cloud approach to containers and Docker that yes, you can take your Docker container and run it anywhere.And it's actually really important to ensure what we call interoperability, or low barrier to entry to a new technology. So, I can take my Docker container, I can move it from one platform to another, and so on. So, that's just to start with on a containers. Between the different solutions, so first of all, I'm all about managed services. You are right, there are many ways to run a Kubernetes. I'm taking a lot of pride—Corey: The best way is always to have someone else run it for you. Problem solved. Great, the best kind of problems are always someone else's.Chen: Yes. And I'm taking a lot of pride of what our team is doing with Kubernetes. I mean, we've been working on that for so long. And it's something that you know, we've coined that term, I think back in 2016, so there is a success disaster, but there's also what we call sustainable success. So, thinking about how to set ourselves up for success and scale. Very proud of that service.Saying that, not everybody and not all your workloads you need the flexibility that Kubernetes gives you in all the ecosystem. So, if you start with containers your first time, you should start with Cloud Run. It's the easiest way to run your containers. That's one. If you are already in love with Kubernetes, we won't take it away from you. Start with GKE. Okay [laugh]? Go all-in. Okay, we are all in loving Kubernetes as well. But what my team and I are working on is to make sure that those will work really well together. And we actually see a lot of customers do that.Corey: I'd like to go back a little bit in history to the rise of Docker. I agree with you it was transformative, but containers had been around in various forms—depending upon how you want to define it—dating back to the '70s with logical partitions on mainframes. Well, is that a container? Is it not? Well, sort of. We'll assume yes for the sake of argument.The revelation that I found from Docker was the developer experience, start to finish. Suddenly, it was a couple commands and you were just working, where previously it had taken tremendous amounts of time and energy to get containers working in that same context. And I don't even know today whether or not the right way to contextualize containers is as sort of a lite version of a VM, as a packaging format, as a number of other things that you could reasonably call it. How do you think about containers?Chen: So, I'm going to do, first of all, a small [unintelligible 00:06:31]. I actually started my career as a system mainframe engineer—Corey: Hmm.Chen: And I will share that when you know, I've learned Kubernetes, I'm like, “Huh, we already have done all of that, in orchestration, in workload management on mainframe,” just to the side. The way I think about containers is as a—two things: one, it is a packaging of an application, but the other thing which is also critical is the decoupling between your application and the OS. So, having that kind of abstraction and allowing you to portable and move it between environments. So, those are the two things that are when I think about containers. And what technologies like Kubernetes and serverless gives on top of that is that manageability and making sure that we take care of everything else that is needed for you to run your application.Corey: I've been, how do I put this, getting some grief over the past few years, in the best ways possible, around a almost off-the-cuff prediction that I made, which was that in five years, which is now a lot closer to two, basically, nobody is going to care about Kubernetes. And I could have phrased that slightly more directly because people think I was trying to say, “Oh, Kubernetes is just hype. It's going to go away. Nobody's going to worry about it anymore.” And I think that is a wildly inaccurate prediction.My argument is that people are not going to have to think about it in the same way that they are today. Today, if I go out and want to go back to my days of running production services in anger—and by ‘anger,' I of course mean in production—then it would be difficult for me to find a role that did not at least touch upon Kubernetes. But people who can work with that technology effectively are in high demand and they tend to be expensive, not to mention then thinking about all of the intricacies and complexities that Kubernetes brings to the foreground, that is what doesn't feel sustainable to me. The idea that it's going to have to collapse down into something else is, by necessity, going to have to emerge. How are you seeing that play out? And also, feel free to disagree with the prediction. I am thrilled to wind up being told that I'm wrong it's how I learn the most.Chen: I don't know if I agree with the time horizon of when that will happen, but I will actually think it's a failure on us if that won't be the truth, that the majority of people will not need to know about Kubernetes and its internals. And you know, we keep saying that, like, hey, we need to make it more, like, boring, and easy, and I've just said like, “Hey, you should use managed.” And we have lots of customers that says that they're just using GKE and it scales on their behalf and they don't need to do anything for that and it's just like magic. But from a technology perspective, there is still a way to go until we can make that disappear.And there will be two things that will push us into that direction. One is—you mentioned that is as well—the talent shortage is real. All the customers that I speak with, even if they can find those great people that are experts, they're actually more interesting things for them to work on, okay? You don't need to take, like, all the people in your organization and put them on building the infrastructure. You don't care about that. You want to build innovation and promote your business.So, that's one. The second thing is that I do expect that the technology will continue to evolve and are managed solutions will be better and better. So hopefully, with these two things happening together, people will not care that what's under the hood is Kubernetes. Or maybe not even, right? I don't know exactly how things will evolve.Corey: From where I sit, what are the early criticisms I had about Docker, which I guess translates pretty well to Kubernetes, are that they solve a few extraordinarily painful problems. In the case of Docker, it was, “Well, it works on my machine,” as a grumpy sysadmin, the way I used to be, the only real response we had to that was, “Well. Time to backup your email, Skippy, because your laptop is going into production, then.” Now, you can effectively have a high-fidelity copy of production, basically anywhere, and we've solved the problem of making your Mac laptop look like a Linux server. Great, okay, awesome.With Kubernetes, it also feels, on some level, like it solves for very large-scale Google-type of problems where you want to run things across at least a certain point of scale. It feels like even today, it suffers from having an easy Hello World-style application to deploy on top of it. Using it for WordPress, or some other form of blogging software, for example, is stupendous overkill as far as the Hello World story tends to go. Increasingly as a result, it feels like it's great for the large-scale enterprise-y applications, but the getting started story of how do I have a service I could reasonably run in production? How do I contextualize that, in the world of Kubernetes? How do you respond to that type of perspective?Chen: We'll start with maybe a short story. I started my career in the Israeli army. I was head of the department and one of the lead technology units and I was responsible for building a PAS. In essence, it was 20-plus years ago, so we didn't really call it a PAS but that's what it was. And then at some point, it was amazing, developers were very productive, we got innovation again, again. And then there was some new innovation just at the beginning of web [laugh] at some point.And it was actually—so two things I've noticed back then. One, it was really hard to evolve the platform to allow new technologies and innovation, and second thing, from a developer perspective, it was like a black box. So, the developers team that people were—the other development teams couldn't really troubleshoot environment; they were not empowered to make decisions or [unintelligible 00:12:29] in the platform. And you know, when it was just started with Kubernetes—by the way, beginning, it only supported 100 nodes, and then 1000 nodes. Okay, it was actually not for scale; it actually solved those two problems, which I'm—this is where I spend most of my time.So, the first one, we don't want magic, okay? To be clear on, like, what's happening, I want to make sure that things are consistent and I can get the right observability. So, that's one. The second thing is that we invested so much in the extensibility an environment that it's, I wouldn't say it's easy, but it's doable to evolve Kubernetes. You can change the models, you can extend it you can—there is an ecosystem.And you know, when we were building it, I remember I used to tell my team, there won't be a Kubernetes 2.0. Which is for a developer, it's [laugh] frightening. But if you think about it and you prepare for that, you're like, “Huh. Okay, what does that mean with how I build my APIs? What does that mean of how we build a system?” So, that was one. The second thing I keep telling my team, “Please don't get too attached to your code because if it will still be there in 5, 10 years, we did something wrong.”And you can see areas within Kubernetes, again, all the extensions. I'm very proud of all the interfaces that we've built, but let's take networking. This keeps to evolve all the time on the API and the surface area that allows us to introduce new technologies. I love it. So, those are the two things that have nothing to do with scale, are unique to Kubernetes, and I think are very empowering, and are critical for the success.Corey: One thing that you said that resonates most deeply with me is the idea that you don't want there to be magic, where I just hand it to this thing and it runs it as if by magic. Because, again, we've all run things in anger in production, and what happens when the magic breaks? When you're sitting around scratching your head with no idea how it starts or how it stops, that is scary. I mean, I recently wound up re-implementing Google Cloud Distinguished Engineer Kelsey Hightower's “Kubernetes the Hard Way” because he gave a terrific tutorial that I ran through in about 45 minutes on top of Google Cloud. It's like, “All right, how do I make this harder?”And the answer is to do it on AWS, re-implement it there. And my experiment there can be found at kubernetesthemuchharderway.com because I have a vanity domain problem. And it taught me he an awful lot, but one of the challenges I had as I went through that process was, at one point, the nodes were not registering with the controller.And I ran out of time that day and turned everything off—because surprise bills are kind of what I spend my time worrying about—turn it on the next morning to continue and then it just worked. And that was sort of the spidey sense tingling moment of, “Okay, something wasn't working and now it is, and I don't understand why. But I just rebooted it and it started working.” Which is terrifying in the context of a production service. It was understandable—kind of—and I think that's the sort of thing that you understand a lot better, the more you work with it in production, but a counterargument to that is—and I've talked about it on this show before—for this podcast, I wind up having sponsors from time to time, who want to give me fairly complicated links to go check them out, so I have the snark.cloud URL redirector.That's running as a production service on top of Google Cloud Run. It took me half an hour to get that thing up and running; I haven't had to think about it since, aside from a three-second latency that was driving me nuts and turned out to be a sleep hidden in the code, which I can't really fault Google Cloud Run for so much as my crappy nonsense. But it just works. It's clearly running atop Kubernetes, but I don't have to think about it. That feels like the future. It feels like it's a glimpse of a world to come, we're just starting to dip our toes into. That, at least to me, feels like a lot more of the abstractions being collapsed into something easily understandable.Chen: [unintelligible 00:16:30], I'm happy you say that. When talking with customers and we're showing, like, you know, yes, they're all in Kubernetes and talking about Cloud Run and serverless, I feel there is that confidence level that they need to overcome. And that's why it's really important for us in Google Cloud is to make sure that you can mix and match. Because sometimes, you know, a big retail customer of ours, some of their teams, it's really important for them to use a Kubernetes-based platform because they have their workloads also running on-prem and they want to serve the same playbooks, for example, right? How do I address issues, how do I troubleshoot, and so on?So, that's one set of things. But some cloud only as simple as possible. So, can I use both of them and still have a similar developer experience, and so on? So, I do think that we'll see more of that in the coming years. And as the technology evolves, then we'll have more and more, of course, serverless solutions.By the way, it doesn't end there. Like, we see also, you know, databases and machine learning, and like, there are so many more managed services that are making things easy. And that's what excites me. I mean, that's what's awesome about what we're doing in cloud. We are building platforms that enable innovation.Corey: I think that there's an awful lot of power behind unlocking innovation from a customer perspective. The idea that I can use a cloud provider to wind up doing an experiment to build something in the course of an evening, and if it works, great, I can continue to scale up without having to replace, you know, the crappy Raspberry Pi-level hardware in my spare room with serious enterprise servers in a data center somewhere. The on-ramp and the capability and the lack of long-term commitments is absolutely magical. What I'm also seeing that is contributing to that is the de facto standard that's emerged of most things these days support Docker, for better or worse. There are many open-source tools that I see where, “Oh, how do I get this up and running?”“Well, you can go over the river and through the woods and way past grandmother's house to build this from source or run this Docker file.” I feel like that is the direction the rest of the world is going. And as much fun as it is to sit on the sidelines and snark, I'm finding a lot more capability stories emerging across the board. Does that resonate with what you're seeing, given that you are inherently working at very large scale, given the [laugh] nature of where you work?Chen: I do see that. And I actually want to double down on the open standards, which I think this is also something that is happening. At the beginning, we talked about I want it to be very hard when I choose the cloud provider. But innovation doesn't only come from cloud providers; there's a lot of companies and a lot of innovation happening that are building new technologies on top of those cloud providers, and I don't think this is going to stop. Innovation is going to come from many places, and it's going to be very exciting.And by the way, things are moving super fast in our space. So, the investment in open standard is critical for our industry. So, Docker is one example. Google is in [unintelligible 00:19:46] speaking, it's investing a lot in building those open standards. So, we have Docker, we have things like of course Kubernetes, but we are also investing in open standards of security, so we are working with other partners around [unintelligible 00:19:58], defining how you can secure the software supply chain, which is also critical for innovation. So, all of those things that reduce the barrier to entry is something that I'm personally passionate about.Corey: Scaling containers and scaling Kubernetes is hard, but a whole ‘nother level of difficulty is scaling humans. You've been at Google for, as you said, seven years and you did not start as a VP there. Getting promoted from Senior Director to VP at Google is a, shall we say, heavy lift. You also mentioned that you previously started with, I believe, it was a seven-person team at one point. How have you been able to do that? Because I can see a world in which, “Oh, we just write some code and we can scale the computers pretty easily,” I've never found a way to do that for people.Chen: So yes, I started actually—well not 7, but the team was 30 people [laugh]. And you can imagine how surprised I was when I joining Google Cloud with Kubernetes and GKE and it was a pretty small team, to the beginning of those days. But the team was already actually on the edge of burning out. You know, pings on Slack, the GitHub issues, there was so many things happening 24/7.And the thing was just doing everything. Everybody were doing everything. And one of the things I've done on my second month on the team—I did an off-site, right, all managers; that's what we do; we do off-sites—and I brought the team in to talk about—the leadership team—to talk about our team values. And in the beginning, they were a little bit pissed, I would say, “Okay, Chen. What's going on? You're wasting two days of our lives to talk about those things. Why we are not doing other things?”And I was like, “You know guys, this is really important. Let's talk about what's important for us.” It was an amazing it worked. By the way, that work is still the foundation of the culture in the team. We talked about the three values that we care about and how that will look like.And the reason it's important is that when you scale teams, the key thing is actually to scale decision-making. So, how do you scale decision-making? I think there are two things there. One is what you're trying to achieve. So, people should know and understand the vision and know where we want to get to.But the second thing is, how do we work? What's important for us? How do we prioritize? How do we make trade-offs? And when you have both the what we're trying to do and the how, you build that team culture. And when you have that, I find that you're set up more for success for scaling the team.Because then the storyteller is not just the leader or the manager. The entire team is a storyteller of how things are working in this team, how do we work, what you're trying to achieve, and so on. So, that's something that had been a critical. So, that's just, you know, from methodology of how I think it's the right thing to scale teams. Specifically, with a Kubernetes, there were more issues that we needed to work on.For example, building or [recoding 00:23:05] different functions. It cannot be just engineering doing everything. So, hiring the first product managers and information engineers and marketing people, oh my God. Yes, you have to have marketing people because there are so many events. And so, that was one thing, just you know, from people and skills.And the second thing is that it was an open-source project and a product, but what I was personally doing, I was—with the team—is bringing some product engineering practices into the open-source. So, can we say, for example, that we are going to focus on user experience this next release? And we're not going to do all the rest. And I remember, my team was like worried about, like, “Hey, what about that, and what about this, and we have—” you know, they were juggling everything together. And I remember telling them, “Imagine that everything is on the floor. All the balls are on the floor. I know they're on the floor, you know they're on the floor. It's okay. Let's just make sure that every time we pick something up, it never falls again.” And that idea is a principle that then evolved to ‘No Heroics,' and it evolved to ‘Sustainable Success.' But building things towards sustainable success is a principle which has been very helpful for us.Corey: This episode is sponsored in part by our friend at Uptycs. Attackers don't think in silos, so why would you have siloed solutions protecting cloud, containers, and laptops distinctly? Meet Uptycs - the first unified solution that prioritizes risk across your modern attack surface—all from a single platform, UI, and data model. Stop by booth 3352 at AWS re:Invent in Las Vegas to see for yourself and visit uptycs.com. That's U-P-T-Y-C-S.com. My thanks to them for sponsoring my ridiculous nonsense.Corey: When I take a look back, it's very odd to me to see the current reality that is Google, where you're talking about empathy, and the No Heroics, and the rest of that is not the reputation that Google enjoyed back when a lot of this stuff got started. It was always oh, engineers should be extraordinarily bright and gifted, and therefore it felt at the time like our customers should be as well. There was almost an arrogance built into, well, if you wrote your code more like Google will, then maybe your code wouldn't be so terrible in the cloud. And somewhat cynically I thought for a while that oh Kubernetes is Google's attempt to wind up making the rest of the world write software in a way that's more Google-y. I don't think that observation has aged very well. I think it's solved a tremendous number of problems for folks.But the complexity has absolutely been high throughout most of Kubernetes life. I would argue, on some level, that it feels like it's become successful almost in spite of that, rather than because of it. But I'm curious to get your take. Why do you believe that Kubernetes has been as successful as it clearly has?Chen: [unintelligible 00:25:34] two things. One about empathy. So yes, Google engineers are brilliant and are amazing and all great. And our customers are amazing, and brilliant, as well. And going back to the point before is, everyone has their job and where they need to be successful and we, as you say, we need to make things simpler and enable innovation. And our customers are driving innovation on top of our platform.So, that's the way I think about it. And yes, it's not as simple as it can be—probably—yet, but in studying the early days of Kubernetes, we have been investing a lot in what we call empathy, and the customer empathy workshop, for example. So, I partnered with Kelsey Hightower—and you mentioned yourself trying to start a cluster. The first time we did a workshop with my entire team, so then it was like 50 people [laugh], their task was to spin off a cluster without using any scripts that we had internally.And unfortunately, not many folks succeeded in this task. And out of that came the—what you you call it—a OKR, which was our goal for that quarter, is that you are able to spin off a cluster in three commands and troubleshoot if something goes wrong. Okay, that came out of that workshop. So, I do think that there is a lot of foundation on that empathetic engineering and the open-source of the community helped our Google teams to be more empathetic and understand what are the different use cases that they are trying to solve.And that actually bring me to why I think Kubernetes is so successful. People might be surprised, but the amount of investment we're making on orchestration or placement of containers within Kubernetes is actually pretty small. And it's been very small for the last seven years. Where do we invest time? One is, as I mentioned before, is on the what we call the API machinery.So, Kubernetes has introduced a way that is really suitable for a cloud-native technologies, the idea of reconciliation loop, meaning that the way Kubernetes is—Kubernetes is, like, a powerful automation machine, which can automate, of course, workload placement, but can automate other things. Think about it as a way of the Kubernetes API machinery is observing what is the current state, comparing it to the desired state, and working towards it. Think about, like, a thermostat, which is a different automation versus the ‘if this, then that,' where you need to anticipate different events. So, this idea about the API machinery and the way that you can extend it made it possible for different teams to use that mechanism to automate other things in that space.So, that has been one very powerful mechanism of Kubernetes. And that enabled all of innovation, even if you think about things like Istio, as an example, that's how it started, by leveraging that kind of mechanism to separate storage and so on. So, there are a lot of operators, the way people are managing their databases, or stateful workloads on top of Kubernetes, they're extending this mechanism. So, that's one thing that I think is key and built that ecosystem. The second thing, I am very proud of the community of Kubernetes.Corey: Oh, it's a phenomenal community success story.Chen: It's not easy to build a community, definitely not in open-source. I feel that the idea of values, you know, that I was talking about within my team was actually a big deal for us as we were building the community: how we treat each other, how do we help people start? You know, and we were talking before, like, am I going to talk about DEI and inclusivity, and so on. One of the things that I love about Kubernetes is that it's a new technology. There is actually—[unintelligible 00:29:39] no, even today, there is no one with ten years experience in Kubernetes. And if anyone says they have that, then they are lying.Corey: Time machine. Yes.Chen: That creates an opportunity for a lot of people to become experts in this technology. And by having it in open-source and making everything available, you can actually do it from your living room sofa. That excites me, you know, the idea that you can become an expert in this new technology and you can get involved, and you'll get people that will mentor you and help you through your first PR. And there are some roles within the community that you can start, you know, dipping your toes in the water. It's exciting. So, that makes me really happy, and I know that this community has changed the trajectory of many people's careers, which I love.Corey: I think that's probably one of the most impressive things that it's done. One last question I have for you is that we've talked a fair bit about the history and how we see it progressing through the view toward the somewhat recent past. What do you see coming in the future? What does the future of Kubernetes look like to you?Chen: Continue to be more and more boring. There is the promise of hybrid and multi-cloud, for example, is only possible by technologies like Kubernetes. So, I do think that, as a technology, it will continue to be important by ensuring portability and interoperability of workloads. I see a lot of edge use cases. If you think about it, it's like just lagging a bit around, like, innovation that we've seen in the cloud, can we bring that innovation to the edge, this will require more development within Kubernetes community as well.And that's really actually excites me. I think there's a lot of things that we're going to see there. And by the way, you've seen it also in KubeCon. I mean, there were some announcements in that space. In Google Cloud, we just announced before, like, with customers like Wendy's and Rite Aid as well. So, taking advantage of this technology to allow innovation everywhere.But beyond that, my hope is that we'll continue and hide the complexity. And our challenge will be to not make it a black box. Because that will be, in my opinion, a failure pattern, doesn't help those kinds of platforms. So, that will be the challenge. Can we scope the project, ensure that we have the right observability, and from a use case perspective, I do think edge is super interesting.Corey: I would agree. There are a lot of workloads out there that are simply never going to be hosted in the cloud provider region, for a variety of reasons of varying validity, but it is the truth. I think that the focus on addressing customers where they are has been an emerging best practice for cloud providers and I'm thrilled to see Google leading the charge on that.Chen: Yeah. And you just reminded me, the other thing that we see also more and more is definitely AI and ML workloads running on Kubernetes, which is part of that, right? So, Google Cloud is investing a lot in making an AI/ML easy. And I don't know if many people know, but, like, even Vertex AI, our own platform, is running on GKE. So, that's part of seeing how do we make sure that platform is suitable for these kinds of workloads and really help customers do the heavy lifting.So, that's another set of workloads that are very relevant at the edge. And one of our customers—MLB, for example—two things are interesting there. The first one, I think a lot of people sometimes say, “Okay, I'm going to move to the cloud and I want to know everything right now, how that will evolve.” And one of the things that's been really exciting with working with MLB for the last four years is the journey and the iterations. So, they started somewhat, like, at one phase and then they saw what's possible, and then moved to the next one, and so on. So, that's one. The other thing is that, really, they have so much ML running at the stadium with Google Cloud technology, which is very exciting.Corey: I'm looking forward to seeing how this continues to evolve and progress, particularly in light of the recent correction we're seeing in the market where a lot of hype-driven ideas are being stress test, maybe not in the way we might have hoped that they would, but it'll be really interesting to see what shakes out as far as things that deliver business value and are clear wins for customers versus a lot of the speculative stories that we've been hearing for a while now. Maybe I'm totally wrong on this. And this is going to be a temporary bump in the road, and we'll see no abatement in the ongoing excitement around so many of these emerging technologies, but I'm curious to see how it plays out. But that's the beautiful part about getting to be a pundit—or whatever it is people call me these days that's at least polite enough to say on a podcast—is that when I'm right, people think I'm a visionary, and when I'm wrong, people don't generally hold that against you. It seems like futurist is the easiest job in the world because if you predict and get it wrong, no one remembers. Predict and get it right, you look like a genius.Chen: So, first of all, I'm optimistic. So usually, my predictions are positive. I will say that, you know, what we are seeing, also what I'm hearing from our customers, technology is not for the sake of technology. Actually, nobody cares [laugh]. Even today.Okay, so nothing needs to change for, like, nobody would c—even today, nobody cares about Kubernetes. They need to care, unfortunately, but what I'm hearing from our customers is, “How do we create new experiences? How we make things easy?” Talent shortage is not just with tech people. It's also with people working in the warehouse or working in the store.Can we use technology to help inventory management? There's so many amazing things. So, when there is a real business opportunity, things are so much simpler. People have the right incentives to make it work. Because one thing we didn't talk about—right, we talked about all these new technologies and we talked about scaling team and so on—a lot of time, the challenge is not the technology.A lot of time, the challenge is the process. A lot of time, the challenge is the skills, is the culture, there's so many things. But when you have something—going back to what I said before—how you unite teams, when there's something a clear goal, a clear vision that everybody's excited about, they will make it work. So, I think this is where having a purpose for the innovation is critical for any successful project.Corey: I think and I hope that you're right. I really want to thank you for spending as much time with me as you have. If people want to learn more, where's the best place for them to find you?Chen: So, first of all, on Twitter. I'm there or on LinkedIn. I will say that I'm happy to connect with folks. Generally speaking, at some point in my career, I recognized that I have a voice that can help people, and I've experienced that can also help people build their careers. I'm happy to share that and [unintelligible 00:36:54] folks both in the company and outside of it.Corey: I think that's one of the obligations on a lot of us, once we wanted to get into a certain position or careers to send the ladder back down, for lack of a better term. It's I've never appreciated the perspective, “Well, screw everyone else. I got mine.” The whole point the next generation should have it easier than we did.Chen: Yeah, definitely.Corey: Chen Goldberg, General Manager of Cloud Runtimes and VP of Engineering at Google. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry rant of a comment talking about how LPARs on mainframes are absolutely not containers, making sure it's at least far too big to fit in a reasonably-sized Docker container.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.