Podcasts about Kubernetes

Ever felt the thrill of jumping into the unknown, taking a leap of faith from a successful career into the exciting world of startups? Our guest Brian, a "fallen physicist" and professor turned IT Security expert, knows this feeling all too well. Join us as Brian shares his intriguing journey from academia to the forefront of cybersecurity, where he found his calling in the high-pressure, high-stakes universe of IT security. Navigating through the sea of alerts, Brian and his team didn't just survive, they thrived, winning the battle to design user-friendly interfaces. A journey fraught with challenges but also filled with rewarding victories. Brian talks about his evolution into the startup space, the grueling process of creating the perfect business plan, and the satisfaction of creating usable solutions for an industry fraught with complexity. And while we're on personal journeys, I also reflect on the whirlwind of emotions and experiences as I stepped into fatherhood, all against the backdrop of the life-altering September 11th events. We also delve deep into the pressing issues of runtime security and vulnerability management, especially for Linux systems and Kubernetes. With Brian's expertise, we dissect security into "left of boom" and "right of boom" stages, underlining the importance of efficient detection and response strategies in a world where average detection time for breaches is three months. We also put the spotlight on Tipping Point technology that has revolutionized security processes in large companies, transforming painstaking tasks into enjoyable experiences. To wrap up this riveting conversation, Brian shares the quirky origin story of his company, Spider Bat. So, come join us on this riveting journey through the complex world of cybersecurity!https://www.linkedin.com/in/brian-smith-07a4191/https://www.spyderbat.com/Support the showAffiliate Links:NordVPN: https://go.nordvpn.net/aff_c?offer_id=15&aff_id=87753&url_id=902 Follow the Podcast on Social Media!Instagram: https://www.instagram.com/secunfpodcast/Twitter: https://twitter.com/SecUnfPodcastPatreon: https://www.patreon.com/SecurityUnfilteredPodcastYouTube: https://www.youtube.com/@securityunfilteredpodcastTikTok: Not today China! Not today

Dan Vega is a Spring Developer Advocate at VMware Tanzu. Dan is also a prolific YouTube content creator, course creator, and has spoken in several conferences. He also hosts the Spring Office Hours show and podcast weekly. In this episode, I talk to Dan about his journey to being a Spring Developer Advocate and what his job actually entails. We also chat about all things Spring - the scope of the framework, how to go about learning it, the release cadence and how to keep up. We also discuss some key choices facing Spring developers today - AOT, Reactive vs Virtual threads, Spring Cloud, Kubernetes and more! Links: Dan's website: https://www.danvega.dev/ YouTube channel: https://www.youtube.com/@DanVega Spring Office Hours (hosted by Dan with DaShaun Carter): https://tanzu.vmware.com/developer/tv/spring-office-hours/ Tanzu Developer Center: https://tanzu.vmware.com/developer/ --- Support this podcast: https://podcasters.spotify.com/pod/show/javabrains/support

Bret is joined by Dan Garfield of CodeFresh to talk about growth of GitOps as a standard, growth of Argo, and more.

In today's Kubernetes Unpacked, Michael and Kristina catch up with Prithvi Raj and Sayan Mondal to talk about all things Chaos Engineering in the Kubernetes space! We chat about the open source and CNCF incubating project, Litmus, and various other topics  including why Chaos Engineering is important, how it can help all organizations, how every engineer can use it, and more. The post Kubernetes Unpacked 035: Chaos Engineering In Kubernetes And The Litmus Project appeared first on Packet Pushers.

What's Normal: DNS TTL Values https://isc.sans.edu/forums/diary/What's%20Normal%3F%20DNS%20TTL%20Values/30234/ CISA Highlights Snatch Ransomware https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-263a npm packages caught exfiltrating Kubernetes config, SSH keys https://blog.sonatype.com/npm-packages-caught-exfiltrating-kubernetes-config-ssh-keys Nagios XI Vulnerabilities https://outpost24.com/blog/nagios-xi-vulnerabilities/

#229: When Kubernetes was first released in September 2014, the only way we could get applications installed to the cluster was by using kubectl apply and big, ugly YAML files. Since that time, many tools have been introduced to help manage application installation into Kubernetes clusters. However, no matter what tool you are using in 2023, under the hood, we're still just submitting those big, ugly YAML files to the Kubernetes. Once you realize this, things become much clearer. In this episode, we take a stroll down memory lane of how it all started and what you should consider doing today when creating (or maybe not creating) the YAML files for your application.   Today's sponsor: Save 25% on your first Barbaro Mojo order using the code "DevOps25” https://barbaromojo.com/discount/DevOps25   YouTube channel: https://youtube.com/devopsparadox/   Books and Courses: Catalog, Patterns, And Blueprints https://www.devopstoolkitseries.com/posts/catalog/   Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/   Slack: https://www.devopsparadox.com/slack/    Connect with us at: https://www.devopsparadox.com/contact/

Today's Full Stack Journey dives into Talos Linux, a "fit-for-purpose OS" designed for running Kubernetes. Host Scott Lowe speaks with Andrew Rynhard about Talos Linux and Sidero Labs, the company behind the Talos open source project. They discuss how Talos differs from other distributions, the concept of machine Linux, how Talos is designed for Kubernetes, and more. The post Full Stack Journey 082: Inside Talos Linux – The Distro Built For Kubernetes appeared first on Packet Pushers.

Today's Full Stack Journey dives into Talos Linux, a "fit-for-purpose OS" designed for running Kubernetes. Host Scott Lowe speaks with Andrew Rynhard about Talos Linux and Sidero Labs, the company behind the Talos open source project. They discuss how Talos differs from other distributions, the concept of machine Linux, how Talos is designed for Kubernetes, and more. The post Full Stack Journey 082: Inside Talos Linux – The Distro Built For Kubernetes appeared first on Packet Pushers.

As OSS projects continue to look for ways to balance community, sustainability and profitability, let's explore some alternative considerations for companies and communities. SHOW: 754CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW SPONSORS:Datadog Synthetic Monitoring: Frontend and Backend Modern MonitoringEnsure frontend issues don't impair user experience by detecting user-facing issues with API and browser tests with a free 14 day Datadog trial. Listeners of The Cloudcast will also receive a free Datadog T-shirt. AWS Insiders is an edgy, entertaining podcast about the services and future of cloud computing at AWS. Listen to AWS Insiders in your favorite podcast player. Cloudfix HomepageCloudZero – Cloud Cost Visibility and Savings​​CloudZero provides immediate and ongoing savings with 100% visibility into your total cloud spendSHOW NOTES:Troubles with Open Source Gig Economy (Chris Aniszczyk, CNCF)Open Source Needs Maintainers, How Do They Get Paid? (TNS)A New Way to Think about Open Source Sustainability (InfoWorld)OPEN SOURCE HAS BECOME CRITICAL INFRASTRUCTURE FOR BUSINESSESDocker, Kubernetes, Terraform, Ansible, Kafka, MongoDB, ElasticSearch, Java are all mission-critical to businesses. Cloud providers have disrupted the previous OSS models - operationalize vs. contributionsHow to pay contributors?How to avoid unpredictable changes to licensing?How to provide better transparency to customers and communities?DO OSS PROJECT NEED MORE STRUCTURE TO SUCCEED OR SUSTAIN?Establish “types” of projects: Business, Community, Any - Years to ActionEstablish some timelines around various types of projectsPatents have a timeline to explore - can there be OSS licenses that have timelinesGovernment tax credits for paying OSS contributorsShould governance foundations create forks at established times?Should groups like CNCF be more active in recruiting forks after a period of time?FEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet

In this episode of Kubernetes Bytes, Ryan and Bhavin sit down with Madhuri Yechuri and talk about all things Nodeless Kubernetes and how users can leverage the concept of Just in Time compute provisioning to prevent wasted spend on their cloud bills. Madhuri talks about LUNA and NOVA - a couple of Elotl products that help users run a nodeless Kubernetes multicluster platform for their containerized applications. Join the Kubernetes Bytes slack using: https://bit.ly/k8sbytes Ready to shop better hydration, use my special link https://zen.ai/apaSnaIFOuee5jScqZ28a03tKKvQiqkyz8mtm9wipoE to save 20% off anything you order. 00:30 Introduction 05:18 Cloud Native News 12:48 Interview with Madhuri 56:20 Takeaways Cloud Native News: https://tech.eu/2023/09/04/rig-dev-first-open-source-baas-platform-on-kubernetes https://d2iq.com/blog/dkp-2-6-features-new-ai-navigator https://securityboulevard.com/2023/09/pluto-finds-deprecated-kubernetes-api-versions-3-questions-from-users/ https://www.businesswire.com/news/home/20230906419666/en/RapidFort-Launches-Runtime-Protection-to-Automatically-Monitor-and-Secure-Kubernetes-Workloads https://www.businesswire.com/news/home/20230906393254/en/InfluxData-Announces-InfluxDB-Clustered-to-Deliver-Time-Series-Analytics-for-On-Premises-and-Private-Cloud-Deployments https://blocksandfiles.com/2023/09/04/storage-news-ticker-4-sep-2023/ https://blocksandfiles.com/2023/09/07/storage-ticker-7-september-2023/ Show links: https://www.elotl.co/ https://www.elotl.co/multi-cluster-podcast https://docs.kubefirst.io/aws/faq https://kubefirst.io/slack

Capt'n Amy is a Systems Engineer Supervisor for NASA at the Kennedy Space Center. Her mission is to make sure that the facilities are always mission ready. Her team also provides support for launch operations. In this episode, Amy takes us through her journey from studying electrical engineering in college and designing sprinkler systems to becoming a supervisor at NASA.  00:00 Introduction 01:23 What is Amy Doing Today? 09:55 First Memory of a Computer13:55 Interests in High School18:00 Starting University21:10 Designing Sprinkler Systems32:26 Applying to NASA38:30 First Experiences at NASA42:30 Telemetry in the Control Room48:00 Newfound Excitement at NASA54:50 Anyone can Work at NASA59:00 Thoughts on A.I1:02:40 Going Back to College1:08:30 Contact InfoConnect with Amy: Twitter: https://twitter.com/CaptnAmyLinkedin: https://www.linkedin.com/in/amy-lendian/Mentioned in today's episode:NASA: https://www.nasa.gov/Want more from Ardan Labs? You can learn Go, Kubernetes, Docker & more through our video training, live events, or through our blog!Online Courses : https://ardanlabs.com/education/ Live Events : https://www.ardanlabs.com/live-training-events/ Blog : https://www.ardanlabs.com/blog Github : https://github.com/ardanlabs

Go's known for it's fantastic standard library, but there are some places where the libraries can be challenging to use. The html/template package is one of those places. So what alternatives do we have? On today's episode we're talking about Templ, an HTML templating language for Go that has great developer tooling. Co-hosts Kris Brandow and Jon Calhoun are joined by Adrian Hesketh, the creator of Templ, and Joe Davidson, one of the maintainers on the project.

MLOps Coffee Sessions #179 with Lamia Youseff, From Virtualization to AI Integration. // Abstract Lamia discusses how both Fortune 500 companies and SMBs lack the knowledge and capabilities to identify which use cases in their systems can benefit from AI integration. She emphasizes the importance of helping these companies integrate AI effectively and acquire the necessary capabilities to stay competitive in the market. // Bio By way of an introduction, Dr. Lamia Youseff has been working in AI / ML for ~25 years, first in academia (MIT, Stanford, UCSB), then large tech (Google, Microsoft, Apple, and Facebook), and most recently with startups in Generative AI. She is currently the executive director of JazzComputing, a Visiting Research Scientist at Stanford University in Computer Science and AI, and a research affiliate with MIT Computer Science and Artificial Intelligence Lab (CSAIL). Dr. Youseff earned her Ph.D. in computer science by studying computationally intensive workloads (such as AI / ML and HPC / Scientific Codes) and has built/led several AI teams as an executive and leader at large tech companies over the years (Google, Facebook, Microsoft, and Apple). She also earned her Master's in business management, strategy, and leadership from Stanford Graduate School of Business (GSB), where she is a guest lecturer today. Dr. Youseff regularly writes and speaks about AI and Machine Learning evolution at CIO/CTO/CEO summits. // MLOps Jobs board https://mlops.pallet.xyz/jobs // MLOps Swag/Merch https://mlops-community.myshopify.com/ // Related Links ⁠ --------------- ✌️Connect With Us ✌️ ------------- Join our slack community: https://go.mlops.community/slack Follow us on Twitter: @mlopscommunity Sign up for the next meetup: https://go.mlops.community/register Catch all episodes, blogs, newsletters, and more: https://mlops.community/ Connect with Demetrios on LinkedIn: https://www.linkedin.com/in/dpbrinkm/ Connect with Lamia on LinkedIn: https://www.linkedin.com/in/lyouseff/ Timestamps: [00:00] Lamia's preferred coffee [01:12] Takeaways [03:00] Please like, share, and subscribe to our MLOps channels! [03:20] Lamia's background [09:52] Getting into Google Cloud [13:10] The Google Cloud project [16:38] The world before Kubernetes [19:25] Evolution of virtualization [23:20] Cloud evolution [28:13] Kubernetes enables the ecosystem [32:38] Multiple systems for machine learning [34:40] Standardization to a greater good [39:50] Complexity and pain points of ML in production [46:26] JazzComputing [50:33] Bridging gaps in AI implementation and investment [51:19] Wrap up

Virtual Application Networks, or VANs, are today's Heavy Networking topic. Our guest is Ted Ross, motive force behind the Skupper.io project. Skupper builds VANs in Kubernetes clusters that are conceptually like a VLAN or VPN, except that all the magic happens at layer 7. Skupper is based on the Advanced Message Queueing Protocol (AMQP), making it effectively a message bus used to interconnect application messages inside of mTLS tunnels running on top of whatever L3 network is available. If you're confused, don't be. We talk it all out, and explain why it's relevant to today's networking pros. The post Heavy Networking 699: Connecting Multicloud Kubernetes Clusters With Virtual Application Networks appeared first on Packet Pushers.

MLOps Coffee Sessions #178 with LLMs in Production Conference part 2 LLM on K8s Panel, Manjot Pahwa, Rahul Parundekar, and Patrick Barker hosted by Outerbounds, Inc.'s Shrinand Javadekar. // Abstract Large Language Models require a new set of tools... or do they? K8s is a beast and we like it that way. How can we best leverage all the battle-hardened tech that K8s has to offer to make sure that our LLMs go brrrrrrr. Let's talk about it in this chat. // Bio Shrinand Javadekar Shri Javadekar is currently an engineer at Outerbounds, focussed on building a fully managed, large-scale platform for running data-intensive ML/AI workloads. Earlier, he spent time trying to start an MLOps company for which he was a co-founder and head of engineering. He led the design, development, and operations of Kubernetes-based infrastructure at Intuit, running thousands of applications, built by hundreds of teams and transacting billions of $$. He has been a founding engineer of the Argo open-source project and also spent precious time at multiple startups that were acquired by large organizations like EMC/Dell and VMWare. Manjot Pahwa Manjot is an investor at Lightspeed India and focuses on SaaS and enterprise tech. She has had an operating career of over a decade within the space of fintech, SaaS, and developer tools spanning various geos such as the US, Singapore, and India. Before joining Lightspeed, Manjot headed Stripe in India, successfully obtaining the payment aggregator license, growing the team from ~10 to 100+, and driving acquisitions in the region during that time. Rahul Parundekar Rahul has 13+ years of experience building AI solutions and leading teams. He is passionate about building Artificial Intelligence (A.I.) solutions for improving the Human Experience. He is currently the founder of A.I. Hero - a platform to help you fix and enrich your data with ML. At AI Hero, he has also been a big proponent of declarative MLOps - using Kubernetes to operationalize the training and serving lifecycle of ML models and has published several tutorials on his Medium blog. Before AI Hero, he was the Director of Data Science (ML Engineering) at Figure-Eight (acquired by Appen), a data annotation company, where he built out a data pipeline and ML model serving architecture serving 36 models (NLP, Computer Vision, Audio, etc.) and traffic of up to 1M predictions per day. Patrick Barker Patrick started his career in Big Data back when that was cool, then moved into Kubernetes near its inception. He has put major features into the Kubernetes API and built several platforms on top of it. In recent years he has moved into AI, with a focus on distributed machine learning. He is now working with a startup to reshape the world of AI agents. // MLOps Jobs board https://mlops.pallet.xyz/jobs // MLOps Swag/Merch https://mlops-community.myshopify.com/ // Related Links ⁠Website: https://www.angellist.com/venture/relay Foundation by Isaac Asimov: https://www.amazon.com/Foundation-Isaac-Asimov/dp/0553293354 AngelList Relay blog: https://www.angellist.com/blog/introducing-angellist-relay --------------- ✌️Connect With Us ✌️ ------------- Join our slack community: https://go.mlops.community/slack Follow us on Twitter: @mlopscommunity Sign up for the next meetup: https://go.mlops.community/register Catch all episodes, blogs, newsletters, and more: https://mlops.community/ Connect with Demetrios on LinkedIn: https://www.linkedin.com/in/dpbrinkm/ Connect with Shri on LinkedIn: https://www.linkedin.com/in/shrijavadekar/ Connect with Manjot on LinkedIn: https://www.linkedin.com/in/manjotpahwa/ Connect with Rahul on LinkedIn: https://www.linkedin.com/in/rparundekar/ Connect with Patrick on LinkedIn: https://www.linkedin.com/in/patrickbarkerco/

In this episode, Bret and Nirmal talk with Brian Douglas of OpenSauced.

Virtual Application Networks, or VANs, are today's Heavy Networking topic. Our guest is Ted Ross, motive force behind the Skupper.io project. Skupper builds VANs in Kubernetes clusters that are conceptually like a VLAN or VPN, except that all the magic happens at layer 7. Skupper is based on the Advanced Message Queueing Protocol (AMQP), making it effectively a message bus used to interconnect application messages inside of mTLS tunnels running on top of whatever L3 network is available. If you're confused, don't be. We talk it all out, and explain why it's relevant to today's networking pros. The post Heavy Networking 699: Connecting Multicloud Kubernetes Clusters With Virtual Application Networks appeared first on Packet Pushers.

Virtual Application Networks, or VANs, are today's Heavy Networking topic. Our guest is Ted Ross, motive force behind the Skupper.io project. Skupper builds VANs in Kubernetes clusters that are conceptually like a VLAN or VPN, except that all the magic happens at layer 7. Skupper is based on the Advanced Message Queueing Protocol (AMQP), making it effectively a message bus used to interconnect application messages inside of mTLS tunnels running on top of whatever L3 network is available. If you're confused, don't be. We talk it all out, and explain why it's relevant to today's networking pros. The post Heavy Networking 699: Connecting Multicloud Kubernetes Clusters With Virtual Application Networks appeared first on Packet Pushers.

Bret Fisher, DevOps Dude & Cloud-Native Trainer, joins Corey on Screaming in the Cloud to discuss what it's like being a practitioner and a content creator in the world of cloud. Bret shares why he feels it's so critical to get his hands dirty so his content remains relevant, and also how he has to choose where to focus his efforts to grow his community. Corey and Bret discuss the importance of finding the joy in your work, and also the advantages and downfalls of the latest AI advancements. About BretFor 25 years Bret has built and operated distributed systems, and helped over 350,000 people learn dev and ops topics. He's a freelance DevOps and Cloud Native consultant, trainer, speaker, and open source volunteer working from Virginia Beach, USA. Bret's also a Docker Captain and the author of the popular Docker Mastery and Kubernetes Mastery series on Udemy. He hosts a weekly DevOps YouTube Live Show, a container podcast, and runs the popular devops.fan Discord chat server.Links Referenced: Twitter: https://twitter.com/BretFisher YouTube Channel: https://www.youtube.com/@BretFisher Website: https://www.bretfisher.com 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: In the cloud, ideas turn into innovation at virtually limitless speed and scale. To secure innovation in the cloud, you need Runtime Insights to prioritize critical risks and stay ahead of unknown threats. What's Runtime Insights, you ask? Visit sysdig.com/screaming to learn more. That's S-Y-S-D-I-G.com/screaming.My thanks as well to Sysdig for sponsoring this ridiculous podcast.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn, a little bit off the beaten path today, in that I'm talking to someone who, I suppose like me, if that's not considered to be an insult, has found themselves eminently unemployable in a quote-unquote, “Real job.” My guest today is Bret Fisher, DevOps dude and cloud-native trainer. Bret, great to talk to you. What do you do?Bret: [laugh]. I'm glad to be here, Corey. I help people for a living like a lot of us end up doing in tech. But nowadays, it's courses, it's live trainings, webinars, all that stuff. And then of course, the fun side of it is the YouTube podcast, hanging out with friends, chatting on the internet. And then a little bit of running a Discord community, which is one of the best places to have a little text chat community, if you don't know Discord.Corey: I've been trying to get the Discord and it isn't quite resonating with me, just because by default, it alerts on everything that happens in any server you're in. It, at least historically, was very challenging to get that tuned in, so I just stopped having anything alert me on my phone, which means now I miss things constantly. And that's been fun and challenging. I still have the slack.lastweekinaws.com community with a couple of thousand people in it.Bret: Nice. Yeah, I mean, some people love Slack. I still have a Slack community for my courses. Discord, I feel like is way more community friendly. By the way, a good server admin knows how to change those settings, which there are a thousand settings in Discord, so server admins, I don't blame you for not seeing that setting.But there is one where you can say new members, don't bug them on every message; only bug them on a mentions or, you know, channel mentions and stuff like that. And then of course, you turn off all those channel mentions and abilities for people to abuse it. But yeah, I had the same problem at first. I did not know what I was doing and it took me years to kind of figure out. The community, we now have 15,000 people. We call it Cloud Native DevOps, but it's basically people from all walks of DevOps, you know, recovering IT pros.And the wonderful thing about it is you always start out—like, you'd do the same thing, I'm sure—where you start a podcast or YouTube channel or a chat community or Telegram, or a subreddit, or whatever your thing is, and you try to build a community and you don't know if it's going to work and you invite your friends and then they show up for a day and then go away. And I've been very lucky and surprised that the Discord server has, to this point, taken on sort of a, its own nature. We've got, I don't know, close to a dozen moderators now and people are just volunteering their time to help others. It's wonderful. I actually—I consider it, like, one of the safe places, unlike maybe Stack Overflow where you might get hated for the wrong question. And we try to guide you to a better question so [laugh] that we can answer you or help you. So, every day I go in there, and there's a dozen conversations I missed that I wasn't able to keep up with. So, it's kind of fun if you're into that thing.Corey: I remember the olden days when I was one of the volunteer staff members on the freenode IRC network before its untimely and awful demise, and I really have come to appreciate the idea of, past a certain point, you can either own the forum that you're working within or you can participate in it, but being a moderator, on some level, sets apart how people treat you in some strange ways. And none of these things are easy once you get into the nuances of codes of conduct, of people participating in good faith, but also are not doing so constructively. And people are hard. And one of these years I should really focus on addressing aspects of that with what I'm focusing on.Bret: [laugh]. Yeah, the machines—I mean, as frustrating as the machines are, they at least are a little more reliable. I don't have anonymous machines showing up yet in Discord, although we do get almost daily spammers and stuff like that. So, you know, I guess I'm blessed to have attracted some of the spam and stuff like that. But a friend of mine who runs a solid community for podcasters—you know, for podcasts hosters—he warned me, he's like, you know, if you really want to make it the community that you have the vision for, it requires daily work.Like, it's a part-time job, and you have to put the time in, or it will just not be that and be okay with that. Like, be okay with it being a small, you know, small group of people that stick around and it doesn't really grow. And that's what's happened on the Slack side of things is I didn't care and feed it, so it has gotten pretty quiet over there as we've grown the Discord server. Because I kind of had to choose, you know? Because we—like you, I started with Slack long, long ago. It was the only thing out there. Discord was just for gamers.And in the last four or five years, I think Discord—I think during the pandemic, they officially said, “We are now more than gamers,” which I was kind of waiting for to really want to invest my company's—I mean, my company of three—you know, my company [laugh] time into a platform that I thought was maybe just for gamers; couldn't quite figure it out. And once they kind of officially said, “Yeah, we're for all communities,” we're more in, you know, and they have that—the thing I really appreciate like we had an IRC, but was mostly human-driven is that Discord, unlike Slack, has actual community controls that make it a safer place, a more inclusive place. And you can actually contact Discord when you have a spammer or someone doing bad things, or you have a server raid where there's a whole bunch of accounts and bot accounts trying to take you down, you can actually reach out to Discord, where Slack doesn't have any of that, they don't have a way for you to reach out. You can't block people or ban them or any of that stuff with Slack. And we—the luckily—the lucky thing of Dis—I kind of look at Discord as, like, the best new equivalent of IRC, even though for a lot of people IRC is still the thing, right? We have new clients now, you can actually have off—you could have sort of synced IRC, right, where you can have a web client that remembers you so you didn't lose the chat after you left, which was always the problem back in the day.Corey: Oh, yeah. I just parked it on, originally, a hardware box, now EC2. And this ran Irssi as my client—because I'm old school—inside of tmux and called it a life. But yeah, I still use that from time to time, but the conversation has moved on. One challenge I've had is that a lot of the people I talk to about billing nuances skew sometimes, obviously in the engineering direction, but also in the business user perspective and it always felt, on some level like it was easier to get business users onto Slack from a community perspective—Bret: Mmm. Absolutely. Yeah.Corey: —than it was for Discord. I mean, this thing started as well. This was years ago, before Discord had a lot of those controls. Might be time to take another bite at that apple.Bret: Yeah. Yeah, I definitely—and that, I think that's why I still keep the Slack open is there are some people, they will only go there, right? Like, they just don't want another thing. That totally makes sense. In fact, that's kind of what's happening to the internet now, right?We see the demise of Twitter or X, we see all these other new clients showing up, and what I've just seen in the dev community is we had this wonderful dev community on Twitter. For a moment. For a few years. It wasn't perfect by far, there was a lot people that still didn't want to use Twitter, but I felt like there was—if you wanted to be in the cloud-native community, that was very strong and you didn't always have to jump into Slack. And then you know, this billionaire came along and kind of ruined it, so people have fractured over to Mastodon and we've got some people have run Threads and some people on Bluesky, and now—and then some people like me that have stuck with Twitter.And I feel like I've lost a chunk of my friends because I don't want to spend my life on six different platforms. So, I am—I have found myself actually kind of sort of regressing to our Discord because it's the people I know, we're all talking about the same things, we all have a common interest, and rather than spending my time trying to find those people on the socials as much as I used to. So, I don't know, we'll see.Corey: Something that I have found, I'm curious to get your take on this, you've been doing this for roughly twice as long as I have, but what I've been having to teach myself is that I am not necessarily representative of the totality of the audience. And, aside from the obvious demographic areas, I learned best by reading or by building something myself—I don't generally listen to podcasts, which is a weird confession in this forum for me to wind up admitting to—and I don't basically watch videos at all. And it took me a while to realize that not everyone is like me; those are wildly popular forms of absorbing information. What I have noticed that the audience engages differently in different areas, whereas for this podcast, for the first six months, I didn't think that I'd remember to turn the microphone on. And that was okay; it was an experiment, and I enjoyed doing it. But then I went to a conference and wound up getting a whole bunch of feedback.Whereas for the newsletter, I had immediate responses to basically every issue when I sent it out. And I think the reason is, is because people are not sitting in front of a computer when they're listening to something and they're not going to be able to say, “Well, let me give you a piece of my mind,” in quite the same way. And by the time they remember later, it feels weird, like, calling into a radio show. But when you actually meet someone, “Yeah, I love your stuff.” And they'll talk about the episodes I've had out. But you can be forgiven for in some cases in the social media side of it for thinking that I'd forgotten to publish this thing.Bret: Yeah. I think that's actually a pretty common trait. There was a time where I was sort of into the science of learning and whatnot, and one of the things that came out of that was that the way we communicate or the way we learn and then the way—the input and the outputs are different per human. It's actually almost, like, comparable maybe to love languages, if you've read that book, where the way we give love and the way we receive love from others is—we prefer it in different ways and it's often not the same thing. And I think the same is true of learning and teaching, where my teaching style has always been visual.I think have almost always been in all my videos. My first course seven years ago, I was in it phy—like, I had my headshot in there and I just thought that that was a part of the best way you could make that content. And doesn't mean that I'm instantly better; it just means I wanted to communicate with my hands, maybe I got a little bit of Italian or French in me or something [laugh] where I'm moving my hands around a lot. So, I think that the medium is very specific to the person. And I meet people all the time that I find out, they didn't learn from me—they didn't learn about me, rather, from my course; they learned about me from a conference talk because they prefer to watch those or someone else learned about me from the podcast I run because they stumbled onto that.And it always surprises me because I always figure that since my biggest audience in my Udemy courses—over 300,000 people there—that that's how most of the people find me. And it turns out nowadays that when I meet people, a lot of times it's not. It's some other, you know, other venue. And now we have people showing up in the Discord server from the Discord Discovery. It's kind of a little feature in Discord that allows you to find servers that are on the topics you're interested in and were listed in there and people will find me that way and jump in not knowing that I have created courses, I have a weekly YouTube Live show, I have all the other things.And yeah, it's just it's kind of great, but also as a content creator, it's kind of exhausting because you—if you're interested in all these things, you can't possibly focus on all of them at the [laugh] same time. So, what is it the great Will Smith says? “Do two things and two things suffer.” [laugh]. And that's exactly what my life is like. It's like, I can't focus on one thing, so they all aren't as amazing as they could be, maybe, if I had only dedicated to one thing.Corey: No, I'm with you on that it's a saying yes to something means inherently saying no to something else. But for those of us whose interests are wide and varied, I find that there are always more things to do than I will ever be able to address. You have to pick and choose, on some level. I dabble with a lot of the stuff that I work on. I have given thought in the past towards putting out video courses or whatnot, but you've done that for ages and it just seems like it is so much front-loaded work, in many cases with things I'm not terrific at.And then, at least in my side of the world, oh, then AWS does another console refresh, as they tend to sporadically, and great, now I have to go back and redo all of the video shoots showing how to do it because now it's changed just enough to confuse people. And it feels like a treadmill you climb on top of and never get off.Bret: It can definitely feel like that. And I think it's also harder to edit existing courses like I'm doing now than it is to just make up something brand new and fresh. And there's something about… we love to teach, I think what we're learning in the moment. I think a lot of us, you get something exciting and you want to talk about it. And so, I think that's how a lot of people's conference talk ideas come up if you think about it.Like you're not usually talking about the thing that you were interested in a decade ago. You're talking about the thing you just learned, and you thought it was great, and you want everyone to know about it, which means you're going to make a YouTube video or a blog post or something about it, you'll share somewhere on social media about it. I think it's harder to make this—any of these content creation things, especially courses, a career if you come back to that course like I'm doing seven years after publication and you're continuing every year to update those videos. And you're thinking I—not that my interests have moved on, but my passion is in the new things. And I'm not making videos right now on new things.I'm fixing—like you're saying, like, I'm fixing the Docker Hub video because it has completely changed in seven years and it doesn't even look the same and all that. So, there's definitely—that's the work side of this business where you really have to put the time in and it may not always be fun. So, one of the things I'm learning from my business coach is like how to find ways to make some of this stuff fun again, and how to inject some joy into it without it feeling like it's just the churn of video after video after video, which, you know, you can fall into that trap with any of that stuff. So, yeah. That's what I'm doing this year is learning a little bit more about myself and what I like doing versus what I have to do and try to make some of it a little funner.Corey: This question might come across as passive-aggressive or back-handedly insulting and I swear to you it is not intended to, but how do you avoid what has been a persistent fear of mine and that is becoming a talking head? Whereas you've been doing this as a trainer for long enough that you haven't had a quote-unquote, “Real job,” in roughly, what, 15 years at this point?Bret: Yeah. Yeah.Corey: And so, you've never run Kubernetes in anger, which is, of course, was what we call production environment. That's right, I call it ‘Anger.' My staging environment is called ‘Theory' because it works in theory, but not in production. And there you have it. So, without being hands-on and running these things at scale, it feels like on some level, if I were to, for example, give up the consulting side of my business and just talk about the pure math that I see and what AWS is putting out there, I feel like I'd pretty quickly lose sight of what actual customer pain looks like.Bret: Yeah. That's a real fear, for sure. And that's why I'm kind of—I think I kind of do what you do and maybe wasn't… didn't try to mislead you, but I do consult on a fairly consistent basis and I took a break this year. I've only—you know, then what I'll do is I'll do some advisory work, I usually won't put hands on a cluster, I'm usually advising people on how to put the hands on that cluster kind of thing, or how to build accepting their PRs, doing stuff like that. That's what I've done in the last maybe three or four years.Because you're right. There's two things that are, right? Like, it's hard to stay relevant if you don't actually get your hands dirty, your content ends up I think this naturally becoming very… I don't know, one dimensional, maybe, or two dimensional, where it doesn't, you don't really talk about the best practices because you don't actually have the scars to prove it. And so, I'm always nervous about going long lengths, like, three or four years of time, with zero production work. So, I think I try to fill that with a little bit of advisory, maybe trying to find friends and actually trying to talk with them about their experiences, just so I can make sure I'm understanding what they're dealing with.I also think that that kind of work is what creates my stories. So like, my latest course, it's on GitHub Actions and Argo CD for using automation and GitOps for deployments, basically trying to simplify the deployment lifecycle so that you can just get back to worrying about your app and not about how it's deployed and how it's tested and all that. And that all came out of consulting I did for a couple of firms in 2019 and 2020, and I think right into 2021, that's kind of where I started winding them down. And that created the stories that caused me, you know, sort of the scars of going into production. We were migrating a COTS app into a SaaS app, so we were learning lots of things about their design and having to change infrastructure. And I had so many learnings from that.And one of them was I really liked GitHub Actions. And it worked well for them. And it was very flexible. And it wasn't as friendly and as GUI beautiful as some of the other CI solutions out there, but it was flexible enough and direct—close enough to the developer that it felt powerful in the developers' hands, whereas previous systems that we've all had, like Jenkins always felt like this black box that maybe one or two people knew.And those stories came out of the real advisory or consultancy that I did for those few years. And then I was like, “Okay, I've got stuff. I've learned it. I've done it in the field. I've got the scars. Let me go teach people about it.” And I'm probably going to have to do that again in a few years when I feel like I'm losing touch like you're saying there. That's a—yeah, so I agree. Same problem [laugh].Corey: Crap, I was hoping you had some magic silver bullet—Bret: No. [laugh].Corey: —other than, “No, it still gnaws at you forever and there's no real way to get away for”—great. But, uhh, it keeps things… interesting.Bret: I would love to say that I have that skill, that ability to, like, just talk with you about your customers and, like, transfer all that knowledge so that I can then talk about it, but I don't know. I don't know. It's tough.Corey: Yeah. The dangerous part there is suddenly you stop having lived experience and start just trusting whoever sounds the most confident, which of course, brings us to generative AI.Bret: Ohhh.Corey: Which apparently needs to be brought into every conversation as per, you know, analysts and Amazon leadership, apparently. What's your take on it?Bret: Yeah. Yeah. Well, I was earl—I mean, well maybe not early, early. Like, these people that are talking about being early were seven years ago, so definitely wasn't that early.Corey: Yeah. Back when the Hello World was a PhD from Stanford.Bret: Yeah [laugh], yeah. So, I was maybe—my first step in was on the tech side of things with Copilot when it was in beta a little over two years ago. We're talking about GitHub Copilot. That was I think my first one. I was not an OpenAI user for any of their solutions, and was not into the visual—you know, the image AI stuff as we all are now dabbling with.But when it comes to code and YAML and TOML and, you know, the stuff that I deal with every day, I didn't start into it until about two years ago. I think I actually live-streamed my first experiences with it with a friend of mine. And I was just using it for DevOps tasks at the time. It was an early beta, so I was like, kind of invited. And it was filling out YAML for me. It was creating Kubernetes YAML for me.And like we're all learning, you know, it hallucinates, as we say, which is lying. It made stuff up for 50% of the time. And it was—it is way better now. So, I think I actually wrote in my newsletter a couple weeks ago a recent story—or a recent experience because I wanted to take a project in a language that I had not previously written from scratch in but maybe I was just slightly familiar with. So, I picked Go because everything in cloud-native is written in Go and so I've been reading it for years and years and years and maybe making small PRs to various things, but never taken on myself to write it from scratch and just create something, start to finish, for myself.And so, I wanted a real project, not something that was contrived, and it came up that I wanted to create—in my specific scenario, I wanted to take a CSV of all of my students and then take a template certificate, you know, like these certificates of completion or certifications, you know, that you get, and it's a nice little—looks like the digital equivalent of a paper certificate that you would get from maybe a university. And I wanted to create that. So, I wanted to do it in bulk. I wanted to give it a stock image and then give it a list of names and then it would figure out the right place to put all those names and then generate a whole bunch of images that I could send out. And then I can maybe turn this into a web service someday.But I wanted to do this, and I knew, if I just wrote it myself, I'd be horrible at it, I would suck at Go, I'd probably have to watch some videos to remember some of the syntax. I don't know the standard libraries, so I'd have to figure out which libraries I needed and all that stuff. All the dependencies.Corey: You make the same typical newcomer mistakes of not understanding the local idioms and whatnot. Oh, yeah.Bret: Yeah. And so, I'd have to spend some time on Stack Overflow Googling around. I kind of guessed it was going to take me 20 to 40 hours to make. Like, and it was—we're talking really just hundreds of lines of code at the end of the day, but because Go standard library actually is really great, so it was going to be far less code than if I had to do it in NodeJS or something. Anyway, long story short there, it ended up taking three to three-and-a-half hours end to end, including everything I needed, you know, importing a CSV, sucking in a PNG, outputting PNG with all the names on them in the right places in the right font, the right colors, all that stuff.And I did it all through GitHub Copilot Chat, which is their newest Labs beta thing. And it brings the ChatGPT-4 experience into VS Code. I think it's right now only for VS Code, but other editors coming soon. And it was kind of wonderful. It remembered my project as a whole. It wasn't just in the file I was in. There was no copying-pasting back and forth between the web interface of ChatGPT like a lot of people tend to do today where they go into ChatGPT, they ask a question, then they copy out code and they paste it in their editor.Well, there was none of that because since that's built into the editor, it kind of flows naturally into your existing project. You can kind of just click a button and it'll automatically paste in where your cursor is. It does all this convenient stuff. And then it would relook at the code. I would ask it, you know, “What are ten ways to improve this code now that it works?” And you know, “How can I reduce the number of lines in this code?” Or, “How can I make it easier to read?”And I was doing all this stuff while I was creating the project. I haven't had anyone, like, look at it to tell me if it looks good [laugh], which I hear you had that experience. But it works, it solved my problem, and I did it in a half a day with no prep time. And it's all in ChatGPT's history. So, when I open up VS Code now, I open that project up and get it, it recognizes that oh, this is the project that you've asked all these previous questions on, and it reloads all those questions, allowing me to basically start the conversation off again with my AI friend at the same place I left off.And I think that experience basically proved to me that what everybody else is telling us, right, that yes, this is definitely the future. I don't see myself ever writing code again without an AI partner. I don't know why I ever would write it without the AI partner at least to help me, quicken my learning, and solve some of the prompts. I mean, it was spitting out code that wasn't perfect. It would actually—[unintelligible 00:23:53] sometimes fail.And then I would tell it, “Here's the error you just caused. What do I do with that?” And it would help me walk through the solution, it would fix it, it would recommend changes. So, it's definitely not something that will avoid you knowing how to program or make someone who's not a programmer suddenly write a perfect program, but man, it really—I mean, it took basically what I would consider to be a novice in that language—not a novice at programming, but a novice at that language—and spit out a productive program in less than a day. So, that's huge, I think.[midroll 00:24:27]Corey: What I think is a necessary prerequisite is a domain expertise in order to figure out what is accurate versus what is completely wrong, but sounds competent. And I've been racing a bunch of the different large-language models against each other in a variety of things like this. One of the challenges I'll give them is to query the AWS pricing API—which motto is, “Not every war crime happens in faraway places”—and then spit out things like the Managed Nat Gateway hourly cost table, sorted from most to least expensive by region. And some things are great at it and other things really struggle with it. And the first time I, just on a lark, went down that path, it saved me an easy three hours from writing that thing by hand. It was effectively an API interface, whereas now the most common programming language I think we're going to see on the rise is English.Bret: Yeah, good point. I've heard some theories, right? Like maybe the output language doesn't matter. You just tell it, “Oh, don't do that in Java, do it in PHP.” Whatever, or, “Convert this Java to PHP,” something like that.I haven't experimented with a lot of that stuff yet, but I think that having spent this time watching a lot of other videos, right, you know, watching [Fireship 00:25:37], and a lot of other people talking about LLMs on the internet, seeing the happy-face stuff happen. And it's just, I don't know where we're going to be in five or ten years. I am definitely not a good prediction, like a futurist. And I'm trying to imagine what the daily experience is going to be, but my assumption is, every tool we're using is going to have some sort of chat AI assistant in it. I mean, this is kind of the future that, like, none of the movies predicted.[laugh]. We were talking about this the other day with a friend of mine. We were talking about it over dinner, some developer friends. And we were just talking about, like, this would be too boring for a movie, like, we all want the—you know, we think of the movies where there's the three laws of robotics and all these things. And these are in no way sentient.I'm not intimidated or scared by them. I think the EU is definitely going to do the right thing here and we're going to have to follow suit eventually, where we rank where you can use AI and, like, there's these levels, and maybe just helping you with a program is a low-level, there's very few restrictions, in other words, by the government, but if you're talking about in cars or in medical or you know, in anything like that, that's the highest level and the highest restrictions and all that. I could definitely see that's the safety. Obviously, we'll probably do it too slow and too late and there'll be some bad uses in the meantime, but I think we're there. I mean, like, if you're not using it today—if you're listening to this, and you're not using AI yet in your day-to-day as someone related to the IT career, it's going to be everywhere and I don't think it's going to be, like, one tool. The tools on the CLI to me are kind of weird right now. Like, they certainly can help you write command lines, but it just doesn't flow right for me. I don't know if you've tried that.Corey: Yeah. I ha—I've dabbled lightly, but again, I've been a Unix admin for the better part of 20 years and I'm used to a world in which you type exactly what you mean or you suffer the consequences. So, having a robot trying to outguess me of what it thinks I'm trying to do, if it works correctly, it looks like a really smart tab complete. If it guesses wrong, it's incredibly frustrating. The risk/reward is not there in the same way.Bret: Right.Corey: So, for me at least, it's more frustration than anything. I've seen significant use cases across the business world where this would have been invaluable back when I was younger, where it's, “Great, here's a one-line email I'm about to send to someone, and people are going to call me brusque or difficult for it. Great. Turn this into a business email.” And then on the other side, like, “This is a five-paragraph email. What does he actually want?” It'll turn it back into one line. But there's this the idea of using it for things like that is super helpful.Bret: Yeah. Robots talking to robots? Is that what you're saying? Yeah.Corey: Well, partially, yes. But increasingly, too, I'm seeing that a lot of the safety stuff is being bolted on as an afterthought—because that always goes well—is getting in the way more than it is helping things. Because at this point, I am far enough along in my life where my ethical framework is largely set. I am not going to have radical changes in my worldview, no matter how much a robot [unintelligible 00:28:29] me.So, snark and sarcasm are my first languages and that is something that increasingly they're leery about, like, oh, sarcasm can hurt people's feelings. “Well, no kidding, professor, you don't say.” As John Scalzi says, “The failure mode of clever is ‘asshole.'” But I figured out how to walk that line, so don't you worry your pretty little robot head about that. Leave that to me. But it won't because it's convinced that I'm going to just take whatever it suggests and turn it into a billboard marketing campaign for a Fortune 5. There are several more approval steps in there.Bret: There. Yeah, yeah. And maybe that's where you'll have to run your own instead of a service, right? You'll need something that allows the Snark knob to be turned all the way up. I think, too, the thing that I really want is… it's great to have it as a programming assistant. It's great and notion to help me, you know, think out, you know, sort of whiteboard some things, right, or sketch stuff out in terms of, “Give me the top ten things to do with this,” and it's great for ideas and stuff like that.But what I really, really want is for it to remove a lot of the drudgery of day-to-day toil that we still haven't, in tech, figured out a way—for example, I'm going to need a new repo. I know what I need to go in it, I know which organization it needs to go in, I know what types of files need to go in there, and I know the general purpose of the repo. Even the skilled person is going to take at least 20 minutes or more to set all that up. And I would really just rather take an AI on my local computer and say, “I would like three new repos: a front-end back-end, and a Kubernetes YAML repo. And I would like this one to be Rust, and I would like this one to be NodeJS or whatever, and I would like this other repo to have all the pieces in Kubernetes. And I would like Docker files in each repo plus GitHub Actions for linting.”Like, I could just spill out, you know, all these things: the editor.config file, the Git ignore, the Docker ignore, think about, like, the dozen files that every repo has to have now. And I just want that generated by an AI that knows my own repos, knows my preferences, and it's more—because we all have, a lot of us that are really, really organized and I'm not one of those, we have maybe a template repo or we have templates that are created by a consolidated group of DevOps guild members or something in our organization that creates standards and reusable workflows and template files and template repos. And I think a lot of that's going to go—that boilerplate will sort of, if we get a smart enough LLM that's very user and organization-specific, I would love to be able to just tell Siri or whatever on my computer, “This is the thing I want to be created and it's boilerplate stuff.” And it then generates all that.And then I jump into my code creator or my notion drafting of words. And that's—like, I hop off from there. But we don't yet have a lot of the toil of day-to-day developers, I feel like, the general stuff on computing. We don't really have—maybe I don't think that's a general AI. I don't think we're… I don't think that needs to be like a general intelligence. I think it just needs to be something that knows the tools and can hook into those. Maybe it asks for my fingerprint on occasion, just for security sake [laugh] so it doesn't deploy all the things to AWS. But.Corey: Yeah. Like, I've been trying to be subversive with a lot of these things. Like, it's always fun to ask the challenging questions, like, “My boss has been complaining to me about my performance and I'm salty about it. Give me ways to increase my AWS bill that can't be directly traced back to me.” And it's like, oh, that's not how to resolve workplace differences.Like, okay. Good on, you found that at least, but cool, give me the dirt. I get asked in isolation of, “Yeah, how can I increase my AWS bill?” And its answer is, “There is no good reason to ever do that.” Mmm, there are exceptions on this and that's not really what I asked. It's, on some level, that tries to out-human you and gets it hilariously wrong.Bret: Yeah, there's definitely, I think—it wasn't me that said this, but in the state we're in right now, there is this dangerous point of using any of these LLMs where, if you're asking it questions and you don't know anything about that thing you're asking about, you don't know what's false, you don't know what's right, and you're going to get in trouble pretty quickly. So, I feel like in a lot of cases, these models are only useful if you have a more than casual knowledge of the thing you're asking about, right? Because, like, you can—like, you've probably tried to experiment. If you're asking about AWS stuff, I'm just going to imagine that it's going to make some of those service names up and it's going to create things that don't exist or that you can't do, and you're going to have to figure out what works and what doesn't.And what do you do, right? Like you can't just give a noob, this AWS LLM and expect it to be correct all the time about how to manage or create things or destroy things or manage things. So, maybe in five years. Maybe that will be the thing. You literally hire someone who has a computing degree out of a university somewhere and then they can suddenly manage AWS because the robot is correct 99.99% of the time. We're just—I keep getting told that that's years and years away and we don't know how to stop the hallucinations, so we're all stuck with it.Corey: That is the failure mode that is disappointing. We're never going to stuff that genie back in the bottle. Like, that is—technology does not work that way. So, now that it's here, we need to find a way to live with it. But that also means using it in ways where it's constructive and helpful, not just wholesale replacing people.What does worry me about a lot of the use it to build an app, when I wound up showing this to some of my engineering friends, their immediate response universally, was, “Well, yeah, that's great for, like, the easy, trivial stuff like querying a bad API, but for any of this other stuff, you still need senior engineers.” So, their defensiveness was the reaction, and I get that. But also, where do you think senior engineers come from? It's solving a bunch of stuff like this. You didn't all spring, fully formed, from the forehead of some God. Like, you started off as junior and working on small trivial problems, like this one, to build a skill set and realize what works well, what doesn't, then life goes on.Bret: Yeah. In a way—I mean, you and I have been around long enough that in a way, the LLMs don't really change anything in terms of who's hireable, how many people you need in your team, or what types of people you need your team. I feel like, just like the cloud allowed us to have less people to do roughly the same thing as we all did in own data centers, I feel like to a large extent, these AIs are just going to do the same thing. It's not fundamentally changing the game for most people to allow a university graduate to become a senior engineer overnight, or the fact that you don't need, you know, the idea that you don't maybe need senior engineers anymore and you can operate at AWS at scale, multi-region setup with some person with a year experience. I don't think any of those things are true in the near term.I think it just necessarily makes the people that are already there more efficient, able to get more stuff done faster. And we've been dealing with that for 30, 40, 50 years, like, that's exactly—I have this slideshow that I keep, I've been using it for a decade and it hasn't really changed. And I got in in the mid-'90s when we were changing from single large computers to distributed computing when the PC took out—took on. I mean, like, I was doing miniframes, and, you know, IBMs and HP Unixes. And that's where I jumped in.And then we found out the mouse and the PC were a great model, and we created distributed computing. That changed the game, allowed us, so many of us to get in that weren't mainframe experts and didn't know COBOL and a lot of us were able to get in and Windows or Microsoft made a great decision of saying, “We're going to make the server operating system look and act exactly like the client operating system.” And then suddenly, all of us PC enthusiasts were now server admins. So, there's this big shift in the '90s. We got a huge amount of server admins.And then virtualization showed up, you know, five years later, and suddenly, we were able to do so much more with the same number of people in a data center and with a bunch of servers. And I watched my team in a big government organization was running 18 people. I had three hardware guys in the data center. That went to one in a matter of years because we were able to virtualize so much we needed physical servers less often, we needed less physical data center server admins, we needed more people to run the software. So, we shifted that team down and then we scaled up software development and people that knew more about actually managing and running software.So, this is, like, I feel like the shifts are happening, then we had the cloud and then we had containerization. It doesn't really change it at a vast scale. And I think sometimes people are a little bit too worried about the LLMs as if they're somehow going to make tech workers obsolete. And I just think, no, we're just going to be managing the different things. We're going to—someone else said the great quote, and I'll end with this, you know, “It's not the LLM that's going to replace you. It's the person who knows the LLMs that's going to replace you.”And that's the same thing you could have said ten years ago for, “It's not the cloud that's going to replace you. It's someone who knows how to manage the cloud that's going to replace you.” [laugh]. So, you could swap that word out for—Corey: A line I heard, must have been 30 years ago now is, “Think. It's the only thing keeping a computer from taking your job.”Bret: Yeah [laugh], and these things don't think so. We haven't figured that one out yet.Corey: Yeah. Some would say that some people's coworkers don't either, but that's just uncharitable.Bret: That's me without coffee [laugh].Corey: [laugh]. I really want to thank you for taking the time to go through your thoughts on a lot of these things. If people want to learn more, where's the best place for them to find you?Bret: bretfisher.com, or just search Bret Fisher. You'll find all my stuff, hopefully, if I know how to use the internet, B-R-E-T F-I-S-H-E-R. And yeah, you'll find a YouTube channel, on Twitter, I hang out there every day, and on my website.Corey: And we will, of course, put links to that in the [show notes 00:38:22]. Thank you so much for taking the time to speak with me today. I really appreciate it.Bret: Yeah. Thanks, Corey. See you soon.Corey: Bret Fisher, DevOps dude and cloud-native trainer. 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 have a Chat-Gippity thing write for you, where, just like you, it sounds very confident, but it's also completely wrong.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.

V Körbes returns to talk prototyping with Natalie, Johnny & Kris. Is Go good for prototyping? What makes a language prototypable, anyway? How does space radiation fit in to all this? Tune in and ride along to find out!

On today's Kubernetes Unpacked, Michael and Kristina catch up with Roberth Strand, Principal Cloud Engineer at Amesto Fortytwo to talk about all things Internal Developer Platform (IDP) on Kubernetes and beyond. Roberth dives into what an IDP is, what it isn't, and how all engineers should be thinking about IDPs. If you're interested in diving into platform engineering, this is the perfect episode for you. The post Kubernetes Unpacked 034: Platform Engineering And Internal Development Platforms On Kubernetes appeared first on Packet Pushers.

On this episode, we've partnered with the Future Rodeo podcast for a discussion between Sam and Matt Wallace. Matt is the Chief Technology Officer and EVP at Faction, a pioneer of multi-cloud data services, and host of Future Rodeo.In this episode, Sam and Matt discuss Microsoft's transformation, the impact of Kubernetes on container orchestration, and the rapid acceleration of AI research and development.-------------------Episode Timestamps:(01:38): Microsoft's open source transformation(13:19): The impact of Kubernetes and how it defragmented the industry(22:06): The transformative power of AI and how it's changing the value of reasoning(54:58): The concept of cognitive economy and its potential impact on AI and software development(01:03:25): Potential implications of advancements in robotics, AI, and clean energy(01:04:17): Sam's advice for those entering the industry or choosing a career path-------------------Links:LinkedIn - Connect with MattListen to the Future Rodeo podcast

Tom Kerkhove joins Scott Hanselman for a hands-on experience to demonstrate how enterprises can make the transition to API-first architectures and microservices in a hybrid, multicloud world with the self-hosted gateway in Azure API Management. Chapters 00:00 - Introduction 01:03 - Concepts 06:38 - Demo setup 10:46 - Demo self-hosted gateway 23:09 - Wrap-up Recommended resources API gateway in Azure API Management Self-hosted gateway overview Guidance for running self-hosted gateway on Kubernetes in production Azure / api-management-self-hosted-gateway Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Scott Hanselman | Twitter: @SHanselman Tom Kerkhove | Twitter: @TomKerkhove Azure API Management | Twitter: @AzureApiMgmt Azure Friday | Twitter: @AzureFriday Azure | Twitter: @Azure

Tom Kerkhove joins Scott Hanselman for a hands-on experience to demonstrate how enterprises can make the transition to API-first architectures and microservices in a hybrid, multicloud world with the self-hosted gateway in Azure API Management. Chapters 00:00 - Introduction 01:03 - Concepts 06:38 - Demo setup 10:46 - Demo self-hosted gateway 23:09 - Wrap-up Recommended resources API gateway in Azure API Management Self-hosted gateway overview Guidance for running self-hosted gateway on Kubernetes in production Azure / api-management-self-hosted-gateway Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Scott Hanselman | Twitter: @SHanselman Tom Kerkhove | Twitter: @TomKerkhove Azure API Management | Twitter: @AzureApiMgmt Azure Friday | Twitter: @AzureFriday Azure | Twitter: @Azure

Austin Parker, Community Maintainer at OpenTelemetry, joins Corey on Screaming in the Cloud to discuss OpenTelemetry's mission in the world of observability. Austin explains how the OpenTelemetry community was able to scale the OpenTelemetry project to a commercial offering, and the way Open Telemetry is driving innovation in the data space. Corey and Austin also discuss why Austin decided to write a book on OpenTelemetry, and the book's focus on the evergreen applications of the tool. About AustinAustin Parker is the OpenTelemetry Community Maintainer, as well as an event organizer, public speaker, author, and general bon vivant. They've been a part of OpenTelemetry since its inception in 2019.Links Referenced: OpenTelemetry: https://opentelemetry.io/ Learning OpenTelemetry early release: https://www.oreilly.com/library/view/learning-opentelemetry/9781098147174/ Page with Austin's social links: https://social.ap2.io 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: Look, I get it. Folks are being asked to do more and more. Most companies don't have a dedicated DBA because that person now has a full time job figuring out which one of AWS's multiple managed database offerings is right for every workload. Instead, developers and engineers are being asked to support, and heck, if time allows, optimize their databases. That's where OtterTune comes in. Their AI is your database co-pilot for MySQL and PostgresSQL on Amazon RDS or Aurora. It helps improve performance by up to four x OR reduce costs by 50 percent – both of those are decent options. Go to ottertune dot com to learn more and start a free trial. That's O-T-T-E-R-T-U-N-E dot com.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. It's been a few hundred episodes since I had Austin Parker on to talk about the things that Austin cares about. But it's time to rectify that. Austin is the community maintainer for OpenTelemetry, which is a CNCF project. If you're unfamiliar with, we're probably going to fix that in short order. Austin, Welcome back, it's been a month of Sundays.Austin: It has been a month-and-a-half of Sundays. A whole pandemic-and-a-half.Corey: So, much has happened since then. I tried to instrument something with OpenTelemetry about a year-and-a-half ago, and in defense to the project, my use case is always very strange, but it felt like—a lot of things have sharp edges, but it felt like this had so many sharp edges that you just pivot to being a chainsaw, and I would have been at least a little bit more understanding of why it hurts so very much. But I have heard from people that I trust that the experience has gotten significantly better. Before we get into the nitty-gritty of me lobbing passive-aggressive bug reports at you have for you to fix in a scenario in which you can't possibly refuse me, let's start with the beginning. What is OpenTelemetry?Austin: That's a great question. Thank you for asking it. So, OpenTelemetry is an observability framework. It is run by the CNCF, you know, home of such wonderful award-winning technologies as Kubernetes, and you know, the second biggest source of YAML in the known universe [clear throat].Corey: On some level, it feels like that is right there with hydrogen as far as unlimited resources in our universe.Austin: It really is. And, you know, as we all know, there are two things that make, sort of, the DevOps and cloud world go around: one of them being, as you would probably know, AWS bills; and the second being YAML. But OpenTelemetry tries to kind of carve a path through this, right, because we're interested in observability. And observability, for those that don't know or have been living under a rock or not reading blogs, it's a lot of things. It's a—but we can generally sort of describe it as, like, this is how you understand what your system is doing.I like to describe it as, it's a way that we can model systems, especially complex, distributed, or decentralized software systems that are pretty commonly found in larg—you know, organizations of every shape and size, quite often running on Kubernetes, quite often running in public or private clouds. And the goal of observability is to help you, you know, model this system and understand what it's doing, which is something that I think we can all agree, a pretty important part of our job as software engineers. Where OpenTelemetry fits into this is as the framework that helps you get the telemetry data you need from those systems, put it into a universal format, and then ship it off to some observability back-end, you know, a Prometheus or a Datadog or whatever, in order to analyze that data and get answers to your questions you have.Corey: From where I sit, the value of OTel—or OpenTelemetry; people in software engineering love abbreviations that are impenetrable from the outside, so of course, we're going to lean into that—but what I found for my own use case is the shining value prop was that I could instrument an application with OTel—in theory—and then send whatever I wanted that was emitted in terms of telemetry, be it events, be it logs, be it metrics, et cetera, and send that to any or all of a curation of vendors on a case-by-case basis, which meant that suddenly it was the first step in, I guess, an observability pipeline, which increasingly is starting to feel like a milit—like an industrial-observability complex, where there's so many different companies out there, it seems like a good approach to use, to start, I guess, racing vendors in different areas to see which performs better. One of the challenges I've had with that when I started down that path is it felt like every vendor who was embracing OTel did it from a perspective of their implementation. Here's how to instrument it to—send it to us because we're the best, obviously. And you're a community maintainer, despite working at observability vendors yourself. You have always been one of those community-first types where you care more about the user experience than you do this quarter for any particular employer that you have, which to be very clear, is intended as a compliment, not a terrifying warning. It's why you have this authentic air to you and why you are one of those very few voices that I trust in a space where normally I need to approach it with significant skepticism. How do you see the relationship between vendors and OpenTelemetry?Austin: I think the hard thing is that I know who signs my paychecks at the end of the day, right, and you always have, you know, some level of, you know, let's say bias, right? Because it is a bias to look after, you know, them who brought you to the dance. But I think you can be responsible with balancing, sort of, the needs of your employer, and the needs of the community. You know, the way I've always described this is that if you think about observability as, like, a—you know, as a market, what's the total addressable market there? It's literally everyone that uses software; it's literally every software company.Which means there's plenty of room for people to make their numbers and to buy and sell and trade and do all this sort of stuff. And by taking that approach, by taking sort of the big picture approach and saying, “Well, look, you know, there's going to be—you know, of all these people, there are going to be some of them that are going to use our stuff and there are some of them that are going to use our competitor's stuff.” And that's fine. Let's figure out where we can invest… in an OpenTelemetry, in a way that makes sense for everyone and not just, you know, our people. So, let's build things like documentation, right?You know, one of the things I'm most impressed with, with OpenTelemetry over the past, like, two years is we went from being, as a project, like, if you searched for OpenTelemetry, you would go and you would get five or six or ten different vendor pages coming up trying to tell you, like, “This is how you use it, this is how you use it.” And what we've done as a community is we've said, you know, “If you go looking for documentation, you should find our website. You should find our resources.” And we've managed to get the OpenTelemetry website to basically rank above almost everything else when people are searching for help with OpenTelemetry. And that's been really good because, one, it means that now, rather than vendors or whoever coming in and saying, like, “Well, we can do this better than you,” we can be like, “Well, look, just, you know, put your effort here, right? It's already the top result. It's already where people are coming, and we can prove that.”And two, it means that as people come in, they're going to be put into this process of community feedback, where they can go in, they can look at the docs, and they can say, “Oh, well, I had a bad experience here,” or, “How do I do this?” And we get that feedback and then we can improve the docs for everyone else by acting on that feedback, and the net result of this is that more people are using OpenTelemetry, which means there are more people kind of going into the tippy-tippy top of the funnel, right, that are able to become a customer of one of these myriad observability back ends.Corey: You touched on something very important here, when I first was exploring this—you may have been looking over my shoulder as I went through this process—my impression initially was, oh, this is a ‘CNCF project' in quotes, where—this is not true universally, of course, but there are cases where it clearly—is where this is an, effectively, vendor-captured project, not necessarily by one vendor, but by an almost consortium of them. And that was my takeaway from OpenTelemetry. It was conversations with you, among others, that led me to believe no, no, this is not in that vein. This is clearly something that is a win. There are just a whole bunch of vendors more-or-less falling all over themselves, trying to stake out thought leadership and imply ownership, on some level, of where these things go. But I definitely left with a sense that this is bigger than any one vendor.Austin: I would agree. I think, to even step back further, right, there's almost two different ways that I think vendors—or anyone—can approach OpenTelemetry, you know, from a market perspective, and one is to say, like, “Oh, this is socializing, kind of, the maintenance burden of instrumentation.” Which is a huge cost for commercial players, right? Like, if you're a Datadog or a Splunk or whoever, you know, you have these agents that you go in and they rip telemetry out of your web servers, out of your gRPC libraries, whatever, and it costs a lot of money to pay engineers to maintain those instrumentation agents, right? And the cynical take is, oh, look at all these big companies that are kind of like pushing all that labor onto the open-source community, and you know, I'm not casting any aspersions here, like, I do think that there's an element of truth to it though because, yeah, that is a huge fixed cost.And if you look at the actual lived reality of people and you look at back when SignalFx was still a going concern, right, and they had their APM agents open-sourced, you could go into the SignalFx repo and diff, like, their [Node Express 00:10:15] instrumentation against the Datadog Node Express instrumentation, and it's almost a hundred percent the same, right? Because it's truly a commodity. There's no—there's nothing interesting about how you get that telemetry out. The interesting stuff all happens after you have the telemetry and you've sent it to some back-end, and then you can, you know, analyze it and find interesting things. So, yeah, like, it doesn't make sense for there to be five or six or eight different companies all competing to rebuild the same wheels over and over and over and over when they don't have to.I think the second thing that some people are starting to understand is that it's like, okay, let's take this a step beyond instrumentation, right? Because the goal of OpenTelemetry really is to make sure that this instrumentation is native so that you don't need a third-party agent, you don't need some other process or jar or whatever that you drop in and it instruments stuff for you. The JVM should provide this, your web framework should provide this, your RPC library should provide this right? Like, this data should come from the code itself and be in a normalized fashion that can then be sent to any number of vendors or back ends or whatever. And that changes how—sort of, the competitive landscape a lot, I think, for observability vendors because rather than, kind of, what you have now, which is people will competing on, like, well, how quickly can I throw this agent in and get set up and get a dashboard going, it really becomes more about, like, okay, how are you differentiating yourself against every other person that has access to the same data, right? And you get more interesting use cases and how much more interesting analysis features, and that results in more innovation in, sort of, the industry than we've seen in a very long time.Corey: For me, just from the customer side of the world, one of the biggest problems I had with observability in my career as an SRE-type for years was you would wind up building your observability pipeline around whatever vendor you had selected and that meant emphasizing the things they were good at and de-emphasizing the things that they weren't. And sometimes it's worked to your benefit; usually not. But then you always had this question when it got things that touched on APM or whatnot—or Application Performance Monitoring—where oh, just embed our library into this. Okay, great. But a year-and-a-half ago, my exposure to this was on an application that I was running in distributed fashion on top of AWS Lambda.So great, you can either use an extension for this or you can build in the library yourself, but then there's always a question of precedence where when you have multiple things that are looking at this from different points of view, which one gets done first? Which one is going to see the others? Which one is going to enmesh the other—enclose the others in its own perspective of the world? And it just got incredibly frustrating. One of the—at least for me—bright lights of OTel was that it got away from that where all of the vendors receiving telemetry got the same view.Austin: Yeah. They all get the same view, they all get the same data, and you know, there's a pretty rich collection of tools that we're starting to develop to help you build those pipelines yourselves and really own everything from the point of generation to intermediate collection to actually outputting it to wherever you want to go. For example, a lot of really interesting work has come out of the OpenTelemetry collector recently; one of them is this feature called Connectors. And Connectors let you take the output of certain pipelines and route them as inputs to another pipeline. And as part of that connection, you can transform stuff.So, for example, let's say you have a bunch of [spans 00:14:05] or traces coming from your API endpoints, and you don't necessarily want to keep all those traces in their raw form because maybe they aren't interesting or maybe there's just too high of a volume. So, with Connectors, you can go and you can actually convert all of those spans into metrics and export them to a metrics database. You could continue to save that span data if you want, but you have options now, right? Like, you can take that span data and put it into cold storage or put it into, like, you know, some sort of slow blob storage thing where it's not actively indexed and it's slow lookups, and then keep a metric representation of it in your alerting pipeline, use metadata exemplars or whatever to kind of connect those things back. And so, when you do suddenly see it's like, “Oh, well, there's some interesting p99 behavior,” or we're hitting an alert or violating an SLO or whatever, then you can go back and say, like, “Okay, well, let's go dig through the slow da—you know, let's look at the cold data to figure out what actually happened.”And those are features that, historically, you would have needed to go to a big, important vendor and say, like, “Hey, here's a bunch of money,” right? Like, “Do this for me.” Now, you have the option to kind of do all that more interesting pipeline stuff yourself and then make choices about vendors based on, like, who is making a tool that can help me with the problem that I have? Because most of the time, I don't—I feel like we tend to treat observability tools as—it depends a lot on where you sit in the org—but you certainly seen this movement towards, like, “Well, we don't want a tool; we want a platform. We want to go to Lowe's and we want to get the 48-in-one kit that has a bunch of things in it. And we're going to pay for the 48-in-one kit, even if we only need, like, two things or three things out of it.”OpenTelemetry lets you kind of step back and say, like, “Well, what if we just got, like, really high-quality tools for the two or three things we need, and then for the rest of the stuff, we can use other cheaper options?” Which is, I think, really attractive, especially in today's macroeconomic conditions, let's say.Corey: One thing I'm trying to wrap my head around because we all find when it comes to observability, in my experience, it's the parable of three blind people trying to describe an elephant by touch; depending on where you are on the elephant, you have a very different perspective. What I'm trying to wrap my head around is, what is the vision for OpenTelemetry? Is it specifically envisioned to be the agent that runs wherever the workload is, whether it's an agent on a host or a layer in a Lambda function, or a sidecar or whatnot in a Kubernetes cluster that winds up gathering and sending data out? Or is the vision something different? Because part of what you're saying aligns with my perspective on it, but other parts of it seem to—that there's a misunderstanding somewhere, and it's almost certainly on my part.Austin: I think the long-term vision is that you as a developer, you as an SRE, don't even have to think about OpenTelemetry, that when you are using your container orchestrator or you are using your API framework or you're using your Managed API Gateway, or any kind of software that you're building something with, that the telemetry data from that software is emitted in an OpenTelemetry format, right? And when you are writing your code, you know, and you're using gRPC, let's say, you could just natively expect that OpenTelemetry is kind of there in the background and it's integrated into the actual libraries themselves. And so, you can just call the OpenTelemetry API and it's part of the standard library almost, right? You add some additional metadata to a span and say, like, “Oh, this is the customer ID,” or, “This is some interesting attribute that I want to track for later on,” or, “I'm going to create a histogram here or counter,” whatever it is, and then all that data is just kind of there, right, invisible to you unless you need it. And then when you need it, it's there for you to kind of pick up and send off somewhere to any number of back-ends or databases or whatnot that you could then use to discover problems or better model your system.That's the long-term vision, right, that it's just there, everyone uses it. It is a de facto and du jour standard. I think in the medium term, it does look a little bit more like OpenTelemetry is kind of this Swiss army knife agent that's running on—inside cars in Kubernetes or it's running on your EC2 instance. Until we get to the point of everyone just agrees that we're going to use OpenTelemetry protocol for the data and we're going to use all your stuff and we just natively emit it, then that's going to be how long we're in that midpoint. But that's sort of the medium and long-term vision I think. Does that track?Corey: It does. And I'm trying to equate this to—like the evolution back in the Stone Age was back when I was first getting started, Nagios was the gold standard. It was kind of the original Call of Duty. And it was awful. There were a bunch of problems with it, but it also worked.And I'm not trying to dunk on the people who built that. We all stand on the shoulders of giants. It was an open-source project that was awesome doing exactly what it did, but it was a product built for a very different time. It completely had the wheels fall off as soon as you got to things were even slightly ephemeral because it required this idea of the server needed to know where all of the things that was monitoring lived as an individual host basis, so there was this constant joy of, “Oh, we're going to add things to a cluster.” Its perspective was, “What's a cluster?” Or you'd have these problems with a core switch going down and suddenly everything else would explode as well.And even setting up an on-call rotation for who got paged when was nightmarish. And a bunch of things have evolved since then, which is putting it mildly. Like, you could say that about fire, the invention of the wheel. Yeah, a lot of things have evolved since the invention of the wheel, and here we are tricking sand into thinking. But we find ourselves just—now it seems that the outcome of all of this has been instead of one option that's the de facto standard that's kind of terrible in its own ways, now, we have an entire universe of different products, many of which are best-of-breed at one very specific thing, but nothing's great at everything.It's the multifunction printer conundrum, where you find things that are great at one or two things at most, and then mediocre at best at the rest. I'm excited about the possibility for OpenTelemetry to really get to a point of best-of-breed for everything. But it also feels like the money folks are pushing for consolidation, if you believe a lot of the analyst reports around this of, “We already pay for seven different observability vendors. How about we knock it down to just one that does all of these things?” Because that would be terrible. What do you land on that?Austin: Well, as I intu—or alluded to this earlier, I think the consolidation in the observability space, in general, is very much driven by that force you just pointed out, right? The buyers want to consolidate more and more things into single tools. And I think there's a lot of… there are reasons for that that—you know, there are good reasons for that, but I also feel like a lot of those reasons are driven by fundamentally telemetry-side concerns, right? So like, one example of this is if you were Large Business X, and you see—you are an engineering director and you get a report, that's like, “We have eight different metrics products.” And you're like, “That seems like a lot. Let's just use Brand X.”And Brand X will tell you very, very happily tell you, like, “Oh, you just install our thing everywhere and you can get rid of all these other tools.” And usually, there's two reasons that people pick tools, right? One reason is that they are forced to and then they are forced to do a bunch of integration work to get whatever the old stuff was working in the new way, but the other reason is because they tried a bunch of different things and they found the one tool that actually worked for them. And what happens invariably in these sort of consolidation stories is, you know, the new vendor comes in on a shining horse to consolidate, and you wind up instead of eight distinct metrics tools, now you have nine distinct metrics tools because there's never any bandwidth for people to go back and, you know—you're Nagios example, right, Nag—people still use Nagios every day. What's the economic justification to take all those Nagios installs, if they're working, and put them into something else, right?What's the economic justification to go and take a bunch of old software that hasn't been touched for ten years that still runs and still does what needs to do, like, where's the incentive to go and re-instrument that with OpenTelemetry or anything else? It doesn't necessarily exist, right? And that's a pretty, I think, fundamental decision point in everyone's observability journey, which is what do you do about all the old stuff? Because most of the stuff is the old stuff and the worst part is, most of the stuff that you make money off of is the old stuff as well. So, you can't ignore it, and if you're spending, you know, millions of millions of dollars on the new stuff—like, there was a story that went around a while ago, I think, Coinbase spent something like, what, $60 million on Datadog… I hope they asked for it in real money and not Bitcoin. But—Corey: Yeah, something I've noticed about all the vendors, and even Coinbase themselves, very few of them actually transact in cryptocurrency. It's always cash on the barrelhead, so to speak.Austin: Yeah, smart. But still, like, that's an absurd amount of money [laugh] for any product or service, I would argue, right? But that's just my perspective. I do think though, it goes to show you that you know, it's very easy to get into these sort of things where you're just spending over the barrel to, like, the newest vendor that's going to come in and solve all your problems for you. And just, it often doesn't work that way because most places aren't—especially large organizations—just aren't built in is sort of like, “Oh, we can go through and we can just redo stuff,” right? “We can just roll out a new agent through… whatever.”We have mainframes [unintelligible 00:25:09], mainframes to thinking about, you have… in many cases, you have an awful lot of business systems that most, kind of, cloud people don't like, think about, right, like SAP or Salesforce or ServiceNow, or whatever. And those sort of business process systems are actually responsible for quite a few things that are interesting from an observability point of view. But you don't see—I mean, hell, you don't even see OpenTelemetry going out and saying, like, “Oh, well, here's the thing to let you know, observe Apex applications on Salesforce,” right? It's kind of an undiscovered country in a lot of ways and it's something that I think we will have to grapple with as we go forward. In the shorter term, there's a reason that OpenTelemetry mostly focuses on cloud-native applications because that's a little bit easier to actually do what we're trying to do on them and that's where the heat and light is. But once we get done with that, then the sky is the limit.[midroll 00:26:11]Corey: It still feels like OpenTelemetry is evolving rapidly. It's certainly not, I don't want to say it's not feature complete, which, again, what—software is never done. But it does seem like even quarter-to-quarter or month-to-month, its capabilities expand massively. Because you apparently enjoy pain, you're in the process of writing a book. I think it's in early release or early access that comes out next year, 2024. Why would you do such a thing?Austin: That's a great question. And if I ever figure out the answer I will tell you.Corey: Remember, no one wants to write a book; they want to have written the book.Austin: And the worst part is, is I have written the book and for some reason, I went back for another round. I—Corey: It's like childbirth. No one remembers exactly how horrible it was.Austin: Yeah, my partner could probably attest to that. Although I was in the room, and I don't think I'd want to do it either. So, I think the real, you know, the real reason that I decided to go and kind of write this book—and it's Learning OpenTelemetry; it's in early release right now on the O'Reilly learning platform and it'll be out in print and digital next year, I believe, we're targeting right now, early next year.But the goal is, as you pointed out so eloquently, OpenTelemetry changes a lot. And it changes month to month sometimes. So, why would someone decide—say, “Hey, I'm going to write the book about learning this?” Well, there's a very good reason for that and it is that I've looked at a lot of the other books out there on OpenTelemetry, on observability in general, and they talk a lot about, like, here's how you use the API. Here's how you use the SDK. Here's how you make a trace or a span or a log statement or whatever. And it's very technical; it's very kind of in the weeds.What I was interested in is saying, like, “Okay, let's put all that stuff aside because you don't necessarily…” I'm not saying any of that stuff's going to change. And I'm not saying that how to make a span is going to change tomorrow; it's not, but learning how to actually use something like OpenTelemetry isn't just knowing how to create a measurement or how to create a trace. It's, how do I actually use this in a production system? To my point earlier, how do I use this to get data about, you know, these quote-unquote, “Legacy systems?” How do I use this to monitor a Kubernetes cluster? What's the important parts of building these observability pipelines? If I'm maintaining a library, how should I integrate OpenTelemetry into that library for my users? And so on, and so on, and so forth.And the answers to those questions actually probably aren't going to change a ton over the next four or five years. Which is good because that makes it the perfect thing to write a book about. So, the goal of Learning OpenTelemetry is to help you learn not just how to use OpenTelemetry at an API or SDK level, but it's how to build an observability pipeline with OpenTelemetry, it's how to roll it out to an organization, it's how to convince your boss that this is what you should use, both for new and maybe picking up some legacy development. It's really meant to give you that sort of 10,000-foot view of what are the benefits of this, how does it bring value and how can you use it to build value for an observability practice in an organization?Corey: I think that's fair. Looking at the more quote-unquote, “Evergreen,” style of content as opposed to—like, that's the reason for example, I never wind up doing tutorials on how to use an AWS service because one console change away and suddenly I have to redo the entire thing. That's a treadmill I never had much interest in getting on. One last topic I want to get into before we wind up wrapping the episode—because I almost feel obligated to sprinkle this all over everything because the analysts told me I have to—what's your take on generative AI, specifically with an eye toward observability?Austin: [sigh], gosh, I've been thinking a lot about this. And—hot take alert—as a skeptic of many technological bubbles over the past five or so years, ten years, I'm actually pretty hot on AI—generative AI, large language models, things like that—but not for the reasons that people like to kind of hold them up, right? Not so that we can all make our perfect, funny [sigh], deep dream, meme characters or whatever through Stable Fusion or whatever ChatGPT spits out at us when we ask for a joke. I think the real win here is that this to me is, like, the biggest advance in human-computer interaction since resistive touchscreens. Actually, probably since the mouse.Corey: I would agree with that.Austin: And I don't know if anyone has tried to get someone that is, you know, over the age of 70 to use a computer at any time in their life, but mapping human language to trying to do something on an operating system or do something on a computer on the web is honestly one of the most challenging things that faces interface design, face OS designers, faces anyone. And I think this also applies for dev tools in general, right? Like, if you think about observability, if you think about, like, well, what are the actual tasks involved in observability? It's like, well, you're making—you're asking questions. You're saying, like, “Hey, for this metric named HTTPrequestsByCode,” and there's four or five dimensions, and you say, like, “Okay, well break this down for me.” You know, you have to kind of know the magic words, right? You have to know the magic promQL sequence or whatever else to plug in and to get it to graph that for you.And you as an operator have to have this very, very well developed, like, depth of knowledge and math and statistics to really kind of get a lot of—Corey: You must be at least this smart to ride on this ride.Austin: Yeah. And I think that, like that, to me is the real—the short-term win for certainly generative AI around using, like, large language models, is the ability to create human language interfaces to observability tools, that—Corey: As opposed to learning your own custom SQL dialect, which I see a fair number of times.Austin: Right. And, you know, and it's actually very funny because there was a while for the—like, one of my kind of side projects for the past [sigh] a little bit [unintelligible 00:32:31] idea of, like, well, can we make, like, a universal query language or universal query layer that you could ship your dashboards or ship your alerts or whatever. And then it's like, generative AI kind of just, you know, completely leapfrogs that, right? It just says, like, well, why would you need a query language, if we can just—if you can just ask the computer and it works, right?Corey: The most common programming language is about to become English.Austin: Which I mean, there's an awful lot of externalities there—Corey: Which is great. I want to be clear. I'm not here to gatekeep.Austin: Yeah. I mean, I think there's a lot of externalities there, and there's a lot—and the kind of hype to provable benefit ratio is very skewed right now towards hype. That said, one of the things that is concerning to me as sort of an observability practitioner is the amount of people that are just, like, whole-hog, throwing themselves into, like, oh, we need to integrate generative AI, right? Like, we need to put AI chatbots and we need to have ChatGPT built into our products and da-da-da-da-da. And now you kind of have this perfect storm of people that really don't ha—because they're just using these APIs to integrate gen AI stuff with, they really don't understand what it's doing because a lot you know, it is very complex, and I'll be the first to admit that I really don't understand what a lot of it is doing, you know, on the deep, on the foundational math side.But if we're going to have trust in, kind of, any kind of system, we have to understand what it's doing, right? And so, the only way that we can understand what it's doing is through observability, which means it's incredibly important for organizations and companies that are building products on generative AI to, like, drop what—you know, walk—don't walk, run towards something that is going to give you observability into these language models.Corey: Yeah. “The computer said so,” is strangely dissatisfying.Austin: Yeah. You need to have that base, you know, sort of, performance [goals and signals 00:34:31], obviously, but you also need to really understand what are the questions being asked. As an example, let's say you have something that is tokenizing questions. You really probably do want to have some sort of observability on the hot path there that lets you kind of break down common tokens, especially if you were using, like, custom dialects or, like, vectors or whatever to modify the, you know, neural network model, like, you really want to see, like, well, what's the frequency of the certain tokens that I'm getting they're hitting the vectors versus not right? Like, where can I improve these sorts of things? Where am I getting, like, unexpected results?And maybe even have some sort of continuous feedback mechanism that it could be either analyzing the tone and tenor of end-user responses or you can have the little, like, frowny and happy face, whatever it is, like, something that is giving you that kind of constant feedback about, like, hey, this is how people are actually like interacting with it. Because I think there's way too many stories right now people just kind of like saying, like, “Oh, okay. Here's some AI-powered search,” and people just, like, hating it. Because people are already very primed to distrust AI, I think. And I can't blame anyone.Corey: Well, we've had an entire lifetime of movies telling us that's going to kill us all.Austin: Yeah.Corey: And now you have a bunch of, also, billionaire tech owners who are basically intent on making that reality. But that's neither here nor there.Austin: It isn't, but like I said, it's difficult. It's actually one of the first times I've been like—that I've found myself very conflicted.Corey: Yeah, I'm a booster of this stuff; I love it, but at the same time, you have some of the ridiculous hype around it and the complete lack of attention to safety and humanity aspects of it that it's—I like the technology and I think it has a lot of promise, but I want to get lumped in with that set.Austin: Exactly. Like, the technology is great. The fan base is… ehh, maybe something a little different. But I do think that, for lack of a better—not to be an inevitable-ist or whatever, but I do think that there is a significant amount of, like, this is a genie you can't put back in the bottle and it is going to have, like, wide-ranging, transformative effects on the discipline of, like, software development, software engineering, and white collar work in general, right? Like, there's a lot of—if your job involves, like, putting numbers into Excel and making pretty spreadsheets, then ooh, that doesn't seem like something that's going to do too hot when I can just have Excel do that for me.And I think we do need to be aware of that, right? Like, we do need to have that sort of conversation about, like… what are we actually comfortable doing here in terms of displacing human labor? When we do displace human labor, are we doing it so that we can actually give people leisure time or so that we can just cram even more work down the throats of the humans that are left?Corey: And unfortunately, I think we might know what that answer is, at least on our current path.Austin: That's true. But you know, I'm an optimist.Corey: I… don't do well with disappointment. Which the show has certainly not been. I really want to thank you for taking the time to speak with me today. If people want to learn more, where's the best place for them to find you?Austin: Welp, I—you can find me on most social media. Many, many social medias. I used to be on Twitter a lot, and we all know what happened there. The best place to figure out what's going on is check out my bio, social.ap2.io will give you all the links to where I am. And yeah, been great talking with you.Corey: Likewise. Thank you so much for taking the time out of your day. Austin Parker, community maintainer for OpenTelemetry. 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 pointing out that actually, physicists say the vast majority of the universe's empty space, so that we can later correct you by saying ah, but it's empty whitespace. That's right. YAML wins again.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.

Guest is Grace Nguyen. Kubernetes 1.28 release lead and student at the University of Waterloo. Grace had to juggle exams and community work to bring Kubernetes 1.28 to life. We will get to know grace and learn what work went into release, where the theme come from and what's special about it Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod News of the week Docker Desktop 4.22 is live The CNCF announced the End User Technical Advisory Board The Go community released v1.21 Configu raised a $3M pre-seed round Links from the interview Grace Nguyen LinkedIn X Kubernetes SIG-Security Kubernetes 1.28 Planternetes API Awareness of SideCars Native SideCar containers in Istio pkgs.k8s.io: Kubernetes Community-Owned Package Repositories Expanding support skew between control plane and node components Non-Graceful node shutdown Pod replacement policy for Jobs (alpha) Match conditions for admission webhooks Feature graduations and deprecations in Kubernetes v1.28 Kubernetes 1.28 webinar. Sept 6th 2023 9am PDT Kubernetes 1.29 PR to assemble team Kubernetes 1.29 shadow program is open Kubernetes 1.27 release lead Xander Grzywinski Links from the post-interview chat Beta support for enabling swap space on Linux SideCars handling is the most popular issue on kubernetes tracker Reddit conversation about native SideCars Native SideCars explained

In this episode of KubernetesBytes, Bhavin and Ryan interview Rob Croteau of Avesha. Avesha is behind the open source project KubeSlice which aims to enable admins to seamlessly connect multiple Kubernetes clusters no matter where they are located with a few command or clicks. Learn about the challenges teams face today with networking and how Kubeslice and avesha are trying to make connectivity for clusters simple. Join the Kubernetes Bytes slack using: https://bit.ly/k8sbytes Try Nom Nom today, go to https://trynom.com/kubernetesbytes and get 50% off your first order plus free shipping.Ready to shop better hydration, use my special link https://zen.ai/apaSnaIFOuee5jScqZ28a03tKKvQiqkyz8mtm9wipoE to save 20% off anything you order.Time Stamps News 00:05:36 Interview 00:14:05 Takeaways 00:53:50 Show Links - https://kubeslice.io/ - https://avesha.io/ - https://github.com/kubeslice Show Notes: - https://cloud.google.com/blog/products/ai-machine-learning/duet-ai-in-google-cloud-preview - https://cloud.google.com/blog/products/containers-kubernetes/whats-new-with-gke-at-google-cloud-next - Kubecost Cloud now GA - install agent using Helm chart https://siliconangle.com/2023/08/21/kubecost-debuts-kubecost-cloud-help-enterprises-rein-kubernetes-spending/ - KEDA graduates - https://www.prnewswire.com/news-releases/cloud-native-computing-foundation-announces-graduation-of-kubernetes-autoscaler-keda-301907019.html - Netapp files in google https://www.techtarget.com/searchstorage/news/366550341/NetApp-cloud-storage-evolving-for-stateful-K8s-AI - GKE Enterprise https://techcrunch.com/2023/08/29/google-introduces-gke-enterprise-to-help-companies-manage-complex-kubernetes-environments/ - API GW article https://thenewstack.io/the-api-gateway-and-the-future-of-cloud-native-applications/ - Ngrok static domains https://ngrok.com/blog-post/free-static-domains-ngrok-users

Sean O'Connor is the Director of Engineering at Datadog. Datadog is the essential monitoring and security platform for cloud applications. Sean discusses his transition from an individual contributor to management and shares why he chose Datadog, emphasizing the appeal of high-scale problems and the real business nature of the company. They delve into the importance of performance management and observability and cover the cultural and technical challenges Sean faces in managing a diverse, geographically spread team, and discuss the transition at Datadog from a decentralized model to more centralized platforms, the corresponding changes in both technical strategies and people management, and what excites him about Datadog's future, including the integration of security offerings into developers' daily experiences, and the evolution of Kubernetes and internal build and release tooling. __ Datadog (https://www.datadoghq.com/) Follow Datadog on LinkedIn (https://www.linkedin.com/company/datadog/), Instagram (https://www.instagram.com/datadoghq/), Youtube (https://www.youtube.com/user/DatadogHQ), or Twitter (https://twitter.com/datadoghq). Follow Sean O'Connor on LinkedIn (https://www.linkedin.com/in/seanoc/) or Twitter (https://twitter.com/theSeanOC). Visit his website at seanoc.com (https://seanoc.com/). 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. WILL: And I'm your other host, Will Larry. And with us today is Sean O'Connor. He is the Director of Engineering at Datadog. Datadog is the essential monitoring and security platform for cloud applications. Sean, thank you for joining us. SEAN: Hi, thanks for having me on. VICTORIA: Yeah, I'm super excited to get to talking with you about everything cloud, and DevOps, and engineering. But why don't we first start with just a conversation about what's going on in your life? Is there any exciting personal moment coming up for you soon? SEAN: Yeah, my wife and I are expecting our first kiddo in the next few weeks, so getting us prepared for that as we can and trying to get as much sleep as we can. [laughs] WILL: Get as much sleep as you can now, so...[laughs] I have a question around that. When you first found out that you're going to be a dad, what was your feeling? Because I remember the feeling that I had; it was a mixed reaction of just everything. So, I just wanted to see what was your reaction whenever you found out that you're going to be a dad for the first time. SEAN: Yeah, I was pretty excited. My wife and I had been kind of trying for this for a little while. We're both kind of at the older end for new parents in our late 30s. So, yeah, excited but definitely, I don't know, maybe a certain amount of, I don't know about fear but, you know, maybe just concerned with change and how different life will be, but mostly excitement and happiness. [laughs] WILL: Yeah, I remember the excitement and happiness. But I also remember, like, wait, I don't know exactly what to do in this situation. And what about the situations that I have no idea about and things like that? So, I will tell you, kids are resilient. You're going to do great as a dad. [laughter] SEAN: Yep. Yeah, definitely; I think I feel much more comfortable about the idea of being a parent now than I may have been in my 20s. But yeah, definitely, the idea of being responsible for and raising a whole other human is intimidating. [laughs] VICTORIA: I think the fact that you're worried about it is a good sign [laughs], right? SEAN: I hope so. [laughs] VICTORIA: Like, you understand that it's difficult. You're going to be a great parent just by the fact that you understand it's difficult and there's a lot of work ahead. So, I think I'm really excited for you. And I'm glad we get to talk to you at this point because probably when the episode comes out, you'll be able to listen to it with your new baby in hand. So... WILL: Good. Excited for it. [laughs] VICTORIA: Yeah, love that. Well, great. Well, why don't you tell me a little bit more about your other background, your professional background? What brought you to the role you're into today? SEAN: Yeah. Well, like we mentioned in the beginning; currently, I'm a Director of Engineering at Datadog. I run our computing cloud team. It's responsible for all of our Kubernetes infrastructure, as well as kind of all the tooling for dealing with the cloud providers that we run on and as well as kind of [inaudible 02:54] crypto infrastructure. Within Datadog, I've always been in management roles though I've kind of bounced around. I've been here for about five and a half years. So, before this, I was running a data store infrastructure team. Before that, when I first came in, I was running the APM product team, kind of bounced around between product and infra. And that's kind of, I guess, been a lot of the story of much of my career is wearing lots of different hats and kind of bouncing around between kind of infrastructure-focused roles and product-focused roles. So, before this, I was running the back-end engineering and DevOps teams at Bitly. So, I was there for about five and a half years, started there originally as a software engineer. And before that, a lot of early-stage startups and consulting doing whatever needed doing, and getting to learn about lots of different kind of industries and domains, which is always fun. [laughs] VICTORIA: That's great. So, you had that broad range of experience coming from all different areas of operations in my mind, which is, like, security and infrastructure, and now working your way into a management position. What was the challenge for you in making that switch from being such a strong individual contributor into an effective manager? SEAN: Sure. You know, I think certainly there is a lot of kind of the classic challenges of learning to let go but still staying involved, right? You know, as a manager, if you're working on critical path tasks hands-on yourself, that's probably not a good sign. [laughs] On the other hand, if you come, like, completely divorced from what your team is doing, especially as, like, a team lead level kind of manager, you know, that's not great either. So, figuring that balancing act definitely was a bit tricky for me. Similarly, I think time management and learning to accept that, especially as you get into, like, further steps along in your career that, like, you know, it's not even a question of keeping all the balls in the air, but more figuring out, like, what balls are made out of rubber and which ones are made out of glass, and maybe keeping those ones in the air. [laughs] So, just a lot of those kind of, like, you know, prioritization and figuring out, like, what the right level of involvement and context is, is definitely the eternal learning, I think, for me. [laughs] WILL: I remember whenever I was looking to change jobs, kind of my mindset was I wanted to work at thoughtbot more because of the values. And I wanted to learn and challenge myself and things like that. And it was so much more, but those were some of the main items that I wanted to experience in my next job. So, when you changed, and you went from Bitly to Datadog, what was that thing that made you say, I want to join Datadog? SEAN: Yeah, that was definitely an interesting job search and transition. So, at that point in time, I was living in New York. I was looking to stay in New York. So, I was kind of talking to a bunch of different companies. Both from personal experience and from talking to some friends, I wasn't super interested in looking at, like, working at mostly, like, the super big, you know, Google, Amazon, Meta type of companies. But also, having done, like, super early stage, you know, like, seed, series A type of companies, having played that game, I wasn't in a place in my life to do that either. [laughs] So, I was looking kind of in between that space. So, this would have been in 2018. So, I was talking to a lot of, like, series A and series B-type companies. And most of them were, like, real businesses. [laughs] Like, they may not be profitable yet, but, like, they had a very clear idea of how they would get there and, like, what that would look like. And so, that was pleasant compared to some past points in my career. But a lot of them, you know, I was effectively doing, like, automation of human processes, which is important. It has value. But it means that, like, realistically, this company will never have more than 50 servers. And when I worked at Bitly, I did have a taste for kind of working in those high-scale, high-availability type environments. So, Datadog initially was appealing because it kind of checked all those boxes of, you know, very high-scale problems, high availability needs, a very real business. [laughs] This is before Datadog had gone public. And then, as I started to talk to them and got to know them, I also really liked a lot of kind of the culture and all the people I interacted with. So, it became a very clear choice very quickly as that process moved along. VICTORIA: Yeah, a very real business. Datadog is one of the Gartner's Magic leaders for APM and observability in the industry. And I understand you're also one of the larger SaaS solutions running Kubernetes, right? SEAN: Yep. Yeah, at this point. Five years ago, that story was maybe a little bit different. [laughs] But yeah, no, no, we definitely have a pretty substantial Kubernetes suite that we run everything on top of. And we get the blessings and curses of we get some really cool problems to work on, but there's also a lot of problems that we come across that when we talk to kind of peers in the industry about kind of how they're trying to solve them, they don't have answers yet either. [laughs] So, we get to kind of figure out a lot of that kind of early discovery games. [laughs] VICTORIA: Yeah. I like how exciting and growing this industry is around kind of your compute and monitoring the performance of your applications. I wonder if you could kind of speak to our audience a little bit, who may not have a big technical background, about just why it's important to think about performance management and observability early on in your application. SEAN: There can be a few pieces there. One of the bigger ones, I think, is thinking about that kind of early and getting used to working with that kind of tooling early in a project or a product. I think it has an analogous effect to, like, thinking about, like, compounding interest in, like, a savings account or investing or something like that. In that, by having those tools available early on and having that visibility available early on, you can really both initially get a lot of value and just kind of understanding kind of what's happening with your system and very quickly troubleshoot problems and make sure things are running efficiently. But then that can help get to a place where you get to that, like, flywheel effect as you're kind of building your product of, as you're able to solve things quickly, that means you have more time to invest in other parts of the product, and so on and so forth. So, yeah, it's one of those things where kind of the earlier you can get started on that, the more that benefit gets amplified over time. And thankfully, with Datadog and other offerings like that now, you can get started with that relatively quickly, right? You're not having to necessarily make the choice of, like, oh, can I justify spending a week, a month, whatever, setting up all my own infrastructure for this, as opposed to, you know, plugging in a credit card and getting going right away? And not necessarily starting with everything from day zero but getting started with something and then being able to build on that definitely can be a worthwhile trade-off. [laughs] VICTORIA: That makes sense. And I'm curious your perspective, Will, as a developer on our Lift Off team, which is really about the services around that time when you want to start taking it really seriously. Like, you've built an app [laughs]. You know it's a viable product, and there's a market for it. And just, like, how you think about observability when you're doing your app building. WILL: The approach I really take is, like, what is the end goal? I'm currently on a project right now that we came in later than normal. We're trying to work through that. SEAN: I haven't come from, you know, that kind of consulting and professional services and support kind of place. I'm curious about, like, what, if any, differences or experiences do you have, like, in that context of, like, how do you use your observability tools or, like, what value they have as opposed to maybe more, like, straight product development? VICTORIA: Right. So, we recently partnered with, you know, our platform engineering team worked with the Lift Off team to create a product from scratch. And we built in observability tools with Prometheus, and Grafana, and Sentry so that the developers could instrument their app and build metrics around the performance in the way they expected the application to work so that when it goes live and meets real users, they're confident their users are able to actually use the app with a general acceptable level of latency and other things that are really key to the functionality of the app. And so, I think that the interesting part was, with the founders who don't have a background in IT operations or application monitoring and performance, it sort of makes sense. But it's still maybe a stretch to really see the full value of that, especially when you're just trying to get the app out the door. SEAN: Nice. VICTORIA: [chuckles] That's my answer. What kind of challenges do you have in your role managing this large team in a very competitive company, running a ton of Kubernetes clusters? [laughs] What's your challenges in your director of engineering role there? SEAN: You know, it's definitely a mix of kind of, like, technical or strategic challenges there, as well as people challenges. On the technical and strategic side, the interesting thing for our team right now is we're in the middle of a very interesting transition. Still, today, the teams at Datadog work in very much a 'You build it, you run it' kind of model, right? So, teams working on user-facing features in addition to, like, you know, designing those features and writing the code for that, they're responsible for deploying that code, offering the services that code runs within, being on call for that, so on and so forth. And until relatively recently, that ownership was very intense to the point where some teams maybe even had their own build and release processes. They were running their own data stores. And, like, that was very valuable for much of our history because that let those teams to be very agile and not have to worry about, like, convincing the entire company to change if they needed to make some kind of change. But as we've grown and as, you know, we've kind of taken on a lot more complexity in our environment from, you know, running across more providers, running across more regions, taking on more of regulatory concerns, to kind of the viability of running everything entirely [inaudible 12:13] for those product teams, it has become much harder. [laughs] You start to see a transition where previously the infrastructure teams were much more acting as subject matter experts and consultants to, now, we're increasingly offering more centralized platforms and offerings that can offload a lot of that kind of complexity and the stuff that isn't the core of what the other product-focused teams are trying to do. And so, as we go through that change, it means internally, a lot of our teams, and how we think about our roles, and how we go about doing our work, changes from, like, a very, you know, traditional reliability type one on one consultation and advising type role to effectively internal product development and internal platform development. So, that's a pretty big both mindset and practice shift. [laughs] So, that's one that we're kind of evolving our way through. And, of course, as what happens to kind of things, like, you still have to do all the old stuff while you're doing the new thing. [laughs] You don't get to just stop and just do the new thing. So, that's been an interesting kind of journey and one that we're always kind of figuring out as we go. That is a lot of kind of what I focus on. You know, people wise, you know, we have an interesting aim of...There's about 40 people in my org. They are spread across EMEA and North America with kind of, let's say, hubs in New York and Paris. So, with that, you know, you have a pretty significant time zone difference and some non-trivial cultural differences. [laughs] And so, you know, making sure that everybody is still able to kind of work efficiently, and communicate effectively, and collaborate effectively, while still working within all those constraints is always an ongoing challenge. [laughs] WILL: Yeah, you mentioned the different cultures, the different types of employees you have, and everyone is not the same. And there's so many cultures, so many...whatever people are going through, you as a leader, how do you navigate through that? Like, how do you constantly challenge yourself to be a better leader, knowing that not everyone can be managed the same way, that there's just so much diversity, probably even in your company among your employees? SEAN: I think a lot of it starts from a place of listening and paying attention to kind of just see where people are happy, where they feel like they have unmet needs. As an example, I moved from that last kind of data store-focused team to this computing cloud team last November. And so, as part of that move, probably for the first two or three months that I was in the role, I wasn't particularly driving much in the way of changes or setting much of a vision beyond what the team already had, just because as the new person coming in, it's usually kind of hard to have a lot of credibility and/or even just have the idea of, like, you know, like you're saying, like, what different people are looking for, or what they need, how they will respond best. I just spend a lot of time just talking to people, getting to know the team, building those relationships, getting to know those people, getting to know those groups. And then, from there, figuring out, you know, both where the kind of the high priority areas where change or investment is needed. But then also figuring out, yeah, kind of based on all that, what's the right way to go about that with the different groups? Because yeah, it's definitely isn't a one size fits all solution. But for me, it's always kind of starting from a place of listening and understanding and using that to develop, I guess, empathy for the people involved and understanding their perspectives and then figuring it out from there. I imagine–I don't know, but I imagine thoughtbot's a pretty distributed company. How do you all kind of think about some of those challenges of just navigating people coming from very different contexts? WILL: Yeah, I was going to ask Victoria that because Victoria is one of the leaders of our team here at thoughtbot. So, Victoria, what are your thoughts on it? VICTORIA: I have also one of the most distributed teams at thoughtbot because we do offer 24/7 support to some clients. And we cover time zones from the Pacific through West Africa. So, we just try to create a lot of opportunities for people to engage, whether it's remotely, especially offering a lot of virtual engagement and social engagement remotely. But then also, offering some in-person, whether it's a company in-person event, or encouraging people to engage with their local community and trying to find conferences, meetups, events that are relevant to us as a business, and a great opportunity for them to go and get some in-person interaction. So, I think then encouraging them to bring those ideas back. And, of course, thoughtbot is known for having just incredible remote async communication happening all the time. It's actually almost a little oppressive to keep up with, to be honest, [laughs] but I love it. There's just a lot of...there's GitHub issues. There's Slack communications. There's, like, open messages. And people are really encouraged to contribute to the conversation and bring up any idea and any problem they're having, and actively add to and modify our company policies and procedures so that we can do the best work with each other and know how to work with each other, and to put out the best products. I think that's key to having that conversation, especially for a company that's as big as Datadog and has so many clients, and has become such a leader in this metrics area. Being able to listen within your company and to your clients is probably going to set you up for success for any, like, tech leadership role [laughs]. I'm curious, what are you most excited about now that you've been in the role for a little while? You've heard from a lot of people within the company. Can you share anything in your direction in the next six months or a year that you're super excited about? SEAN: So, there's usually kind of probably two sides to that question of kind of, like, from a product and business standpoint and from an internal infrastructure standpoint, given that's where my day-to-day focus is. You know, on the product side, one thing that's been definitely interesting to watch in my time at Datadog is we really made the transition from kind of, like, a point solution type product to much more of a platform. For context, when I joined Datadog, I think logs had just gone GA, and APM was in beta, I think. So, we were just starting to figure out, like, how we expand beyond the initial infrastructure metrics product. And, obviously, at this point, now we have a whole, you know, suite of offerings. And so, kind of the opportunities that come with that, as far as both different spaces that we can jump into, and kind of the value that we can provide by having all those different capabilities play together really nicely, is exciting and is cool. Like, you know, one of the things that definitely lit an interesting light bulb for me was talking to some of the folks working on our newer security offerings and them talking about how, obviously, you want to meet, you know, your normal requirements in that space, so being able to provide the visibility that, you know, security teams are looking for there. But also, figuring out how we integrate that information into your developers' everyday experience so that they can have more ownership over that aspect of the systems that they're building and make everybody's job easier and more efficient, right? Instead of having, you know, the nightmare spreadsheet whenever a CVE comes out and having some poor TPM chase half the company to get their libraries updated, you know, being able to make that visible in the product where people are doing their work every day, you know, things like that are always kind of exciting opportunities. On the internal side, we're starting to think about, like, what the next major evolution of our kind of Kubernetes and kind of internal build and release tooling looks like. Today, a lot of kind of how teams interact with our Kubernetes infrastructure is still pretty raw. Like, they're working directly with specific Kubernetes clusters, and they are exposed to all the individual Kubernetes primitives, which is very powerful, but it's also a pretty steep learning curve. [laughs] And for a lot of teams, it ends up meaning that there's lots of, you know, knobs that they have to know what they do. But at the end of the day, like, they're not getting a lot of benefit from that, right? There's more just opportunity for them to accidentally put themselves in a bad place. So, we're starting to figure out, like, higher level abstractions and offerings to simplify how all that for teams look like. So, we're still a bit early days in working through that, but it's exciting to figure out, like, how we can still give teams kind of the flexibility and the power that they need but make those experiences much easier and not have to have them become Kubernetes experts just to deploy a simple process. And, yes, so there's some lots of fun challenges in there. [laughs] Mid-Roll Ad: When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don't have all year to do extended research. In just a few weeks, thoughtbot's Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We'll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. WILL: I have a question around your experience. So, you've been a developer around 20 years. What has been your experience over that 20 years or about of the growth in this market? Because I can only imagine what the market was, you know, in the early 2000s versus right now because I still remember...I still have nightmares of dial-up, dial tone tu-tu-tu. No one could call you, stuff like that. So, what has been your experience, just seeing the market grow from where you started? SEAN: Sure, yeah. I think probably a lot of the biggest pieces of it are just seeing the extent to which...I want to say it was Cory Doctorow, but I'm not sure who actually originally coined the idea, but the idea that, you know, software is eating the world, right? Like, eventually, to some degree, every company becomes a software company because software ends up becoming involved in pretty much everything that we as a society do. So, definitely seeing the progression of that, I think, over that time period has been striking, you know, especially when I was working in more consulting contexts and working more in companies and industries where like, you know, the tech isn't really the focus but just how much that, you know, from an engineering standpoint, relatively basic software can fundamentally transform those businesses and those industries has definitely been striking. And then, you know, I think from a more individual perspective, seeing as, you know, our tools become more sophisticated and easier to access, just seeing how much of a mixed bag that has become [laughs]. And just kind of the flavor of, like, you know, as more people have more powerful tools, that can be very enabling and gives voice to many people. But it also means that the ability of an individual or a small group to abuse those tools in ways that we're maybe not fully ready to deal with as a society has been interesting to see how that's played out. VICTORIA: Yeah. I think you bring up some really great points there. And it reminds me of one of my favorite quotes is that, like, the future is here—it's just not evenly distributed. [laughs] And so, in some communities that I go to, everyone knows what Kubernetes is; everyone knows what DevOps is. It's kind of, like, old news. [laughs] And then, some people are still just like, "What?" [laughs]. It's interesting to think about that and think about the implications on your last point about just how dangerous the supply chain is in building software and how some of these abstractions and some of these things that just make it so easy to build applications can also introduce a good amount of risk into your product and into your business, right? So, I wonder if you can tell me a little bit more about your perspective on security and DevSecOps and what founders might be thinking about to protect their IP and their client's data in their product. SEAN: That one is interesting and tricky in that, like, we're in a little bit of, like, things are better and worse than they ever have been before [laughs], right? Like, there is a certain level of, I think, baseline knowledge and competency that I think company leaders really just have to have now, part of, like, kind of table stakes, which can definitely be challenging, and that, like, that probably was much less, if even the case, you know, 10-20 years ago in a lot of businesses. As an example, right? Like, obviously, like if it's a tech-focused company, like, that can be a thing. But, like, if you're running a plumbing business with a dozen trucks, let's say, like, 20 years ago, you probably didn't have to think that much about data privacy and data security. But, like, now you're almost certainly using some kind of electronic system to kind of manage all your customer records, and your job scheduling, and all that kind of stuff. So, like, now, that is something that's a primary concern for your business. On the flip side of that, I think there is much better resources, and tools, and practices available out there. I forget the name of the tool now. But I remember recently, I was working with a company on the ISO long string of numbers certifications that you tend to want to do when you're handling certain types of data. There was a tool they were able to work with that basically made it super easy for them to, like, gather all the evidence for that and whatnot, in a way where, like, you know, in the past, you probably just had to hire a compliance person to know what you had to do and how to present that. But now, you could just sign up for a SaaS product. And, like, obviously, it can't just do it for you. Like, it's about making your policies. But it still gave you enough support where if you're, like, bootstrapping a company, like, yeah, you probably don't need to hire a specialist to [inaudible 25:08], which is a huge deal. You know, similarly, a lot of things come much safer by default. When you think about, like, the security on something like an iPhone, or an iPad, or an Android device, like, just out of the box, that's light-years ahead of whatever Windows PC you were going to buy ten years ago. [laughs] And so, that kind of gives you a much better starting place. But some interesting challenges that come with that, right? And that we do now, literally, every person on the planet is walking around with microphones and cameras and all kinds of sensors on them. It's an interesting balance, I think. Similarly, I'm curious how you all think about kind of talking with your clients and your customers about this because I'm sure you all have a non-trivial amount of education to do there. [laughs] VICTORIA: Yeah, definitely. And I think a lot of it comes in when we have clients who are very early founders, and they don't have a CTO or a technical side of their business, and advising them on exactly what you laid out. Like, here's the baseline. Like, here's where you want to start from. We generally use the CIS controls, this internet for internet security. It puts out a really great tool set, too, for some things you were mentioning earlier. Let's figure out how to report and how to identify all of the things that we're supposed to be doing. It could be overwhelming. It's a lot. Like, in my past role as VP of Operations at Pluribus Digital, I was responsible for helping our team continue to meet our...we had three different ISO long number certifications [laughs]. We did a CMMI as well, which has come up a few times in my career. And they give you about a couple of hundreds of controls that you're supposed to meet. It's in very kind of, like, legalese that you have to understand. And that's a pretty big gap to solve for someone who doesn't have the technical experience to start. Like, what you were saying, too, that it's more dangerous and more safer than it has been before. So, if we make choices for those types of clients in very safe, trusted platforms, then they're going to be set up for success and not have to worry about those details as much. And we kind of go forward with confidence that if they are going to have to come up against compliance requirements or local state regulations, which are also...there's more of those every day, and a lot of liability you can face as a founder, especially if you're dealing with, like, health or financial data, in the state of California, for example. [laughs] It puts you at a really big amount of liability that I don't think we've really seen the impact of how bad it can be and will be coming out in the next couple of years now that that law has passed. But that's kind of the approach that we like to think. It's like, you know, there's a minimum we can do that will mitigate a lot of this risk [laughs], so let's do that. Let's do the basics and start off on the right foot here. SEAN: Yeah, no, that makes sense. Yeah, it's definitely something I've come to appreciate, especially doing work in regulated spaces is, when you do reach the point where you do need to have some kind of subject matter expert involved, whether it's somebody in-house or a consultant or an advisor, I've definitely learned that usually, like, the better ones are going to talk to you in terms of, like, what are the risk trade-offs you're making here? And what are the principles that all these detailed controls or guidelines are looking to get at? As opposed to just, like, walking you through the box-checking exercise. In my experience, a really good lawyer or somebody who will talk to you about risk versus just saying whether or not you can do something. [laughs] It has a very similar feeling in my experience. VICTORIA: Yeah, it's a lot about risk. And someone's got to be able to make those trade-off decisions, and it can be really tough, but it's doable. And I think it shouldn't scare people away. And there's lots of people, lots of ways to do it also, which is exciting. So, I think it's a good space to be in and to see it growing and pay attention to. [laughs] It's fun for me to be in a different place where we're given the opportunity to kind of educate or bring people along in a security journey versus having it be a top-down executive-level decision that we need to meet this particular security standard, and that's the way it's going to be. [laughs] Yeah, so that I appreciate. Is there anything that really surprised you in your conversations with Datadog or with other companies around these types of services for, like, platform engineering and observability? Is there anything that surprised you in the discovery process with potential clients for your products? SEAN: I think one of the biggest surprises, or maybe not a surprise but an interesting thing is, to what extent, you know, for us, I don't know if this is still the case, but I think in many places, like, we're probably more often competing against nothing than a competing product. And by that, I mean, especially as you look at some of our more sophisticated products like APM, or profiling, it's not so much that somebody has an existing tool that we're looking to replace; it's much more than this is just not a thing they do today. [laughs] And so, that leads to a very interestingly different conversation that I think, you know, relates to some of what we were saying with security where, you know, I think a non-trivial part of what our sales and technical enablement folks do is effectively education for our customers and potential customers of why they might want to use tools like this, and what kind of value they could get from them. The other one that's been interesting is to see how different customers' attitudes around tools like this have evolved as they've gone through their own migration to the cloud journeys, right? We definitely have a lot of customers that, I think, you know, 5, 10 years ago, when they were running entirely on-prem, using a SaaS product would have been a complete non-starter. But as they move into the cloud, both as they kind of generally get more comfortable with the idea of delegating some of these responsibilities, as well as they start to understand kind of, like, the complexity of the tooling required as their environment gets more complex, the value of a dedicated product like something like Datadog as opposed to, you know, what you kind of get out of the box with the cloud providers or what you might kind of build on your own has definitely been interesting. [laughs] VICTORIA: Is there a common point that you find companies get to where they're like, all right, now, I really need something? Can you say a little bit more about, like, what might be going on in the organization at that time? SEAN: You know, I think there could be a few different paths that companies take to it. Some of it, I think, can come from a place of...I think, especially for kind of larger enterprise customers making a transition like that, they tend to be taking a more holistic look at kind of their distinct practices and seeing what they want to change as they move into the cloud. And often, kind of finding an observability vendor is just kind of, like, part of the checklist there. [laughs] Not to dismiss it, but just, like, that seems to be certainly one path into it. I think for smaller customers, or maybe customers that are more, say, cloud-native, I think it can generally be a mix of either hitting a point where they're kind of done with the overhead of trying to maintain their own infrastructure of, like, trying to run their own ELK stack and, like, build all the tooling on top of that, and keeping that up and running, and the costs associated with that. Or, it's potentially seeing the sophistication of tooling that, like, a dedicated provider can afford to invest that realistically, you're never going to invest in on your own, right? Like, stuff like live profiling is deeply non-trivial to implement. [laughs] I think especially once people get some experience with a product like Datadog, they start thinking about, like, okay, how much value are we actually getting out of doing this on our own versus using a more off-the-shelf product? I don't know if we've been doing it post-COVID. But I remember pre-COVID...so Datadog has a huge presence at re:Invent and the other similar major cloud provider things. And I remember for a few years at re:Invent, you know, we obviously had, like, the giant 60x60 booth in the main expo floor, where we were giving demos and whatnot. But they also would have...AWS would do this, like, I think they call it the interactive hall where companies could have, like, more hands-on booths, and you had, like, a whole spectrum of stuff. And there were, like, some companies just had, like, random, like, RC car setups or Lego tables, just stuff like that. But we actually did a setup where there was a booth of, I think, like, six stations. People would step up, and they would race each other to solve a kind of faux incident using Datadog. The person who would solve it first would win a switch. I think we gave away a huge number of switches as part of that, which at first I was like, wow, that seems expensive. [laughs] But then later, you know, I was mostly working the main booth at that re:Invent. So by the, like, Wednesday and Thursday of re:Invent, I'd have people walking up to the main booth being like, "Hey, so I did the thing over at the Aria. And now I installed Datadog in prod last night, and I have questions." I was like, oh, okay. [laughs] So, I think just, like, the power of, like, getting that hands-on time, and using some of the tools, and understanding the difference there is what kind of gets a lot of people to kind of change their mind there. [laughs] VICTORIA: You'd get me with a switch right now. I kind of want one, but I don't want to buy one. SEAN: [laughs] WILL: Same. [laughs] VICTORIA: Because I know it'll take up all my time. SEAN: Uh-huh. That's fair. [laughs] VICTORIA: But I will try to win one at a conference for sure. I think that's true. And it makes sense that because your product is often going with clients that don't have these practices yet, that as soon as you give them exposure to it, you see what you can do with it, that becomes a very powerful selling tool. Like, this is the value of the product, right? [laughs] SEAN: Yeah, there is also something we see, and I think most of our kind of peers in the industry see is, very often, people come in initially looking for and using a single product, like, you know, infrastructure, metrics, or logs. And then, as they see that and see where that touches other parts of the product, their usage kind of grows and expands over time. I would obviously defer to our earnings calls for exact numbers. But generally speaking, more or less kind of half of our new business is usually expanded usage from existing customers as opposed to new customers coming in. So, I think there's also a lot of just kind of organic discovery and building of trust over time that happens there, which is interesting. VICTORIA: One of my favorite points to make, which is that SRE sounds very technical and, like, this really extreme thing. But to make it sound a little more easier, is that it is how you validate that the user experience is what you expect it to be. [laughs] I wonder if you have any other thoughts you want to add to that, just about, like, SRE and user experience and how that all connects for real business value. SEAN: I think a lot of places where, you know, we've both seen internally ourselves and with customers is, you know; obviously, different companies operate in different models and whatnot. Where people have seen success is where, you know, people with formal SRE titles or team names can kind of be coming in as just kind of another perspective on the various kind of things that teams are trying to drive towards. The places reliability is successfully integrated is when they can kind of make that connection that you were talking about. It's, like, obviously, everybody should go take their vitamins, but, like, what actual value is coming from this, right? Nobody wants to have outages, but, like, to do the work to invest in reliability, often, like, it can be hard to say, like, okay, what's the actual difference between before and after? Having people who can help draw those connections and help weigh those trade-offs, I think, can definitely be super helpful. But it is generally much more effective, I think, in my experience, when it does come from that perspective of, like, what value are we providing? What are we trading off as part of this? As opposed to just, well, you should do this because it's the right thing to do, kind of a moralistic perspective. [laughs] But, I don't know, how do you all kind of end up having that conversation with your customers and clients? VICTORIA: That's exactly it. That's the same. It's starting that conversation about, like, well, what happens when this experience fails, which designers don't necessarily think about? What's, like, the most important paths that you want a user to take through your application that we want to make sure works? And when you tie it all back there, I think then when the developers are understanding how to create those metrics and how to understand user behavior, that's when it becomes really powerful so that they're getting the feedback they need to do the right code, and to make the right changes. Versus just going purely on interviews [laughs] and not necessarily, like, understanding behavior within the app. I think that starts to make it clear. SEAN: Part of that, I think that's been an interesting experience for us is also just some of the conversation there around, like, almost the flip side of, when are you investing potentially too much in that, right? Because, like, especially after a certain point, the cost of additional gains grows exponentially, right? Each one of those nines gets more and more expensive. [laughs] And so, having the conversation of, like, do you actually need that level of reliability, or, like, is that...just like what you're saying. Like, you know, kind of giving some of that context and that pressure of, like, yeah, we can do that, but, like, this is what it's going to cost. Is that what you want to be spending your money on? Kind of things can also be an interesting part of that conversation. VICTORIA: That's a really good point that, you know, you can set goals that are too high [laughs] and not necessary. So, it does take a lot of just understanding about your data and your users to know what are acceptable levels of error. I think the other thing that you can think about, too, like, what could happen, and we've seen it happen with some startups, is that, like, something within the app is deeply broken, but you don't know. And you just think that you're not having user engagement, or that users are signing off, or, like, you know, not opening the app after the first day. So, if you don't have any way to really actively monitor it and you're not spending money on an active development team, you can have some method to just be confident that the app is working and to make your life less miserable [laughs] when you have a smaller team supporting, especially if you're trying to really minimize your overhead for running an application. SEAN: Yep. It's surprisingly hard to know when things are broken sometimes. [laughs] VICTORIA: Yes, and then extremely painful when you find out later [laughs] because that's when it's become a real problem, yeah. I wonder, are there any other questions you have for me or for Will? SEAN: How big of an organization is thoughtbot at this time? VICTORIA: Close to 75 people? We're, yeah, between the Americas and the [inaudible 38:31] region. So, that's where we're at right now, yeah. SEAN: Nice. At that size, like, and I guess it sounds like you're pretty heavily distributed, so maybe some of this doesn't happen as much, but, like, one of the things I definitely remember...so, when I joined Datadog, it was probably about 500 people. And I think we're just under 5,000 now. There are definitely some points where there were surprisingly, like, physical aspects to where it became a problem of just, like, where certain teams didn't fit into a room anymore. [laughs] Like, I had surprise in the changes in that, like, dynamic. I'm curious if you've all kind of run into any kind of, I don't know, similar interesting thresholds or changes as you've kind of grown and evolved. WILL: I will say this, we're about 100, I think, Victoria. VICTORIA: Oh, okay, we're 100 people. I think, you know, I've only been at thoughtbot for just over a year now. And my understanding of the history is that when we were growing before COVID, there's always been a very intentionality about growth. And there was never a goal to get to a huge size or to really grow beyond just, like, a steady, profitable growth. [laughs] So, when we were growing in person, there were new offices being stood up. So, we, you know, maybe started out of New York and Boston and grew to London. And then, there was Texas, and I think a few other ones that started. Then with COVID, the decision was made to go fully remote, and I think that's opened up a lot of opportunities for us. And from my understanding in the previous and the past, is that there's a big shift to be fully remote. It's been challenging, where I think a lot of people miss some of the in-person days, and I'm sure it's definitely lonely working remote all day by yourself. So, you have to really proactively find opportunities to see other people and to engage remotely. But I think also, we hire people from so many different places and so much different talent, and then, also, you know, better informs our products and creates a different, you know, energy within the company that I think is really fun and really exciting for us now. WILL: Yeah, I would agree with that because I think the team that I'm on has about 26 people on the Lift Off team. And we're constantly thinking of new ways to get everyone involved. But as a developer, me myself being remote, I love talking to people. So, I try to be proactive and, like, connect with the people I'm working with and say, "Hey, how can I help you with this?" Let's jump in this room and just work together, chat together, and stuff like that, so... And it has opened the door because the current project that I'm on, I would never have had an opportunity to be on. I think it's based in Utah, and I'm in South Florida. So, there's just no way if we weren't remote that I'd been a part of it. So... SEAN: Nice. And I can definitely appreciate that. I remember when we first started COVID lockdown; I think, at that point, Datadog was probably about...Datadog engineering was probably about 30% remote, so certainly a significant remote contingent but mixed. But my teams were pretty remote-heavy. So, in some ways, not a lot changed, right? Like, I think more people on my team were, like, who are all these other people in my house now instead of [laughs], I mean, just transition from being in an office to working from home. But I do remember maybe, like, about six months in, starting to feel, yeah, some of the loneliness and the separation of just, like, not being able to do, like, quarterly team meetups or stuff like that. So, it's definitely been an interesting transition. For context, at this point, we kind of have a hybrid setup. So, we still have a significant kind of full-time remote contingent, and then four people who are in office locations, people joining for about three days a week in office. So, it's definitely an interesting transition and an interesting new world. [laughs] VICTORIA: Yeah. And I'm curious how you find the tech scene in Denver versus New York or if you're engaging in the community in the same way since you moved. SEAN: There definitely is some weirdness since COVID started [laughs] broadly [inaudible 42:21]. So, I moved here in 2020. But I'd been coming out here a lot before that. I helped to build an office here with Bitly. So, I was probably coming out once a quarter for a bunch of years. So, one parallel that is finally similar is, like, in both places, it is a small world. It doesn't take that long for you to be in that community, in either of those communities and start running into the same people in different places. So, that's always been [inaudible 42:42] and especially in New York. New York is a city of what? 8, 9 million people? But once you're working in New York tech for a few years and you go into some meetups, you start running into the same people, and you have one or two degrees [inaudible 42:52] to a lot of people, surprisingly quickly. [laughs] So, that's similar. But Denver probably is interesting in that it's definitely transplant-heavy. I think Denver tends to check the box for, like, it was part of why Bitly opened an office here and, to a degree, Datadog as well. I think of like, you know, if you're trying to recruit people and you previously were mostly recruiting in, like, New York or Silicon Valley; if you're based in New York, and you're trying to recruit somebody from Silicon Valley, and part of why they're looking for a new gig is they're burned out on Silicon Valley, asking them to move to New York probably isn't all that attractive. [laughs] But Denver is different enough in that in terms of kind of being a smaller city, easier access to nature, a bunch of that kind of stuff, that a lot of times we were able to attract talent that was a much more appealing prospect. [laughs] You'll see an interesting mix of industries here. One of the bigger things here is there's a very large government and DOD presence here. I remember I went to DevOps Days Rockies, I think, a few years ago. There was a Birds of a Feather session on trying to apply DevOps principles in air-gapped networks. That was a very interesting conversation. [laughs] VICTORIA: That's interesting. I would not have thought Colorado would be a big hub for federal technology. But there you go, it's everywhere. WILL: Yeah. SEAN: Denver metro, I think, is actually the largest presence of federal offices outside of the D.C. metro. VICTORIA: That's interesting. Yeah, I'm used to trying to recruit people into D.C., and so, it's definitely not the good weather, [laughs], not a good argument in my favor. So, I just wanted to give you a final chance. Anything else you'd like to promote, Sean? SEAN: Generally, not super active on social things these days, but you can find whatever I have done at seanoc.com, S-E–A-N-O-C.com for the spelling. And otherwise, if you're interested in some engineering content and hearing about some of those kind of bleeding edge challenges that I was mentioning before, I would definitely check out the Datadog engineering blog. There's lots of kind of really interesting content there on both, you know, things we've learned from incidents and interesting projects that we're working on. There's all kinds of fun stuff there. VICTORIA: That makes me think I should have asked you more questions, Sean. [laughs] No, I think it was great. Thank you so much for joining us today. I'll definitely check all that stuff out. 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. You can find me on Twitter @victori_ousg. WILL: And you can find me on Twitter @will23larry. 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: Sean O'Connor.

Hi, Spring fans! In this installment Josh Long talks to Spring contributor and adjunct professor at Mines Paris, [Daniel Garnier-Moiroux (@kehrlann)](https://twitter.com/kehrlann), about the wild and wonderful intersection of all things Spring Security and Kubernetes, productized Spring Cloud Services, and more, recorded live at SpringOne 2023 from Las Vegas, Nevada!

Ian Molee is a Software Developer at a cryptocurrency firm called Falcon X. His day to day languages include Python and Go with various other languages mixed in. In this episode, Ian takes us through his extensive journey through various companies in the tech industry and his experiences along the way.  00:00 Introduction 03:23 What is Ian Doing Today? 14:46 Interests in High School22:37 Going to University / Value of a Degree35:45 Joining the Workforce / First Tech Jobs48:00 Moving to New Mexico57:00 Joining Amazon 59:45 Moving to Seattle1:10:00 Leaving Amazon / Other Jobs1:20:00 Learning Go 1:24:00 Highlights of the Industry1:31:20 Thoughts on A.I1:39:10 Contact InfoConnect with Ian: Twitter: https://twitter.com/ianfooMentioned in today's episode:Falcon X : https://falconx.io/Amazon: https://www.amazon.com/Want more from Ardan Labs? You can learn Go, Kubernetes, Docker & more through our video training, live events, or through our blog!Online Courses : https://ardanlabs.com/education/ Live Events : https://www.ardanlabs.com/live-training-events/ Blog : https://www.ardanlabs.com/blog Github : https://github.com/ardanlabs

Our “what's new in Go” correspondent Carl Johnson joins Johnny & Kris yet again to discuss what's new with the latest iteration of Go in version 1.21.

We're kicking off Season 7 with containers! Spinning up a VM may not be such a big deal anymore; however, most of us still have to request from another group one and wait. Even waiting on an Azure VM can be somewhat painful. Wouldn't it be nice to forget about setting up another development environment just to test something that isn't going to stick around? Our guest today is Chuck Bryan, and he talks to us about how he is using containers to support his environments and the flexibility it provides to him in his development. While the Linux containers used to get lots of love, there haven't been too many feature updates lately as much of the focus is on azure services. What is cool to me is there are tools out there that can help us folks running windows get up and running without having to wait on our infrastructure to upgrade to Windows server 2016--or have Azure spend. Chuck gives us some insights on how he got started with containers. We discuss what environments might benefit from them--and which ones won't. He also gives us a couple of tips on the best places to get started. The show notes for today's episode can be found at Episode 266: Working With Containers. Have fun on the SQL Trail!

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.