POPULARITY
62 episodes with gke
33 episodes with gke
36 episodes with gke
13 episodes with gke
10 episodes with gke
5 episodes with gke
3 episodes with gke
3 episodes with gke
5 episodes with gke
Send us a textApril 2025 news. A lot of news for you, dear listener, from Google, AWS and AzureTakeaway by the aiThe FinOps News podcast targets hardcore Phenops enthusiasts.Conflict can lead to better team dynamics and outcomes.Azure's VM hibernation feature offers cost-efficient workload management.Amazon EC2 introduces high-performance storage optimized instances.Bare metal instances provide significant performance improvements.Prompt optimization in Amazon Bedrock enhances AI model performance.AWS Database Migration Service now supports automatic storage scaling.Cloud gaming may benefit from new GPU instance offerings.The importance of feedback in improving cloud services is emphasized.The podcast aims to provide in-depth insights into cloud technology. Amazon S3 has significantly reduced its storage and request prices.Google Cloud's FinOps Hub 2.0 offers new tools for cost management.GKE now provides insights to optimize resource requests and limits.Azure AKS cost recommendations help identify savings opportunities.Google Cloud's backup services now support DB2 databases.Amazon Redshift introduces serverless reservations for cost predictability.AWS CodeBuild enhancements allow for better resource configuration.Microsoft Cost Management has improved export functionalities.Microsoft Copilot in Azure offers tailored prompts for cost analysis.Azure Static Web Apps will discontinue dedicated pricing plans.
In this episode, we're bringing you a curated selection of conversations from the KubeCon EU 2025 showfloor. We'll be diving into the rise of platform engineering, exploring some cutting-edge technologies, getting updates on core Kubernetes components, and hearing some truly unique user stories, like using Kubernetes on a dairy farm! Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod - bluesky: @kubernetespodcast.com News of the week CNCF Blog - Announcing the Automated Governance Maturity Model Kubernetes Blog CNCF Blog - Understanding Kubernetes Gateway API: A Modern Approach to Traffic Management Open Observability Summit Links from the interview NAIS at NAV, with Hans Kristian Flaatten and Audun Fauchald Strand Audun Fauchald Strand Hans Kristian Flaatten NAV (Norwegian Labor and Welfare Administration) Kubernetes Podcast 216: NAIS, with Johnny Horvi and Frode Sundby NAIS KubeCon EU 2025 Keynote: Adventures of Building a Platform as a Service for the Government - Hans Kristian Flaatten, Lead Platform Engineer, NAV & Audun Fauchald Strand, Principal Software Engineer, NAV GKE release notes Platform Engineering, with Max Körbächer and Andreas (Andi) Grabner Max Körbächer Andreas (Andi) Grabner Book: “Platform Engineering for Architects: Crafting modern platforms as a product” by Max Körbächer, Andreas Grabner, and Hilliary Lipsig Cloud Native Summit Munich Kubernetes at LinkedIn, with Ahmet Alp Balkan and Ronak Nathani Ahmet Alp Balkan Ronak Nathani Kubernetes Podcast 249: Kubernetes at LinkedIn, with Ahmet Alp Balkan and Ronak Nathani Ahmet's Blog Introducing Multi-Cluster Orchestrator: Scale your Kubernetes workloads across regions LLMs on Kubernetes, with Mofi and Abdel KubeCon EU 2025 talk: Yes You Can Run LLMs on Kubernetes - Abdel Sghiouar & Mofi Rahman, Google Cloud About the Gateway API Gateway API Inference Extension Deploy GKE Inference Gateway SIG etcd with Ivan Valdes Ivan Valdes etcd.io SIG etcd on GitHub Open Source Kubernetes, with Jago Macleod Jago Macleod Google Open Source: Kubernetes Schedmd Slurm Ray Run:ai from Nvidia Medium blog: “Deploy Slurm on GKE” by Abdel Sghiouar AI-Hypercomputer, xpk XPK (Accelerated Processing Kit, pronounced x-p-k) is a command line interface that simplifies cluster creation and workload execution on Google Kubernetes Engine (GKE). XPK generates preconfigured, training-optimized clusters and allows easy workload scheduling without any Kubernetes expertise. Cursor AI Editor Dairy Farm Automation & Banking with Kubernetes, with Clément Nussbaumer Clément Nussbaumer Talos Linux Cluster-api Cluster API is a Kubernetes subproject focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters. KubeCon EU 2025 Talk: “Day-2'000 - Migration From Kubeadm+Ansible To ClusterAPI+Talos: A Swiss Bank's Journey” - Clément Nussbaumer, PostFinance Kubeadm Kubeadm is a tool built to provide kubeadm init and kubeadm join as best-practice "fast paths" for creating Kubernetes clusters. Being a First-Time KubeCon Attendee, with Nick Taylor Kubernetes The Hard Way K3s - “The certified Kubernetes distribution built for IoT & Edge computing” Kubernetes Ingress Controllers Kubernetes Up and Running Kubernetes Docs KubeCon EU 2025 Sponsored Keynote: The Science of Winning: Oracle Red Bull Racing's Formula with Open Source, Kubernetes and AI - Sudha Raghavan, SVP of OCI Developer Platform, Oracle
At Google Cloud Next, Bobby Allen, Group Product Manager for Google Kubernetes Engine (GKE), emphasized GKE's foundational role in supporting AI platforms. While AI dominates current tech conversations, Allen highlighted that cloud-native infrastructure like Kubernetes is what enables AI workloads to function efficiently. GKE powers key Google services like Vertex AI and is trusted by organizations including DeepMind, gaming companies, and healthcare providers for AI model training and inference. Allen explained that GKE offers scalability, elasticity, and support for AI-specific hardware like GPUs and TPUs, making it ideal for modern workloads. He noted that Kubernetes was built with capabilities—like high availability and secure orchestration—that are now essential for AI deployment. Looking forward, GKE aims to evolve into a model router, allowing developers to access the right AI model based on function, not vendor, streamlining the development experience. Allen described GKE as offering maximum control with minimal technical debt, future-proofed by Google's continued investment in open source and scalable architecture.Learn more from The New Stack about the latest insights with Google Cloud: Google Kubernetes Engine Customized for Faster AI WorkKubeCon Europe: How Google Will Evolve Kubernetes in the AI EraApache Ray Finds a Home on the Google Kubernetes EngineJoin our community of newsletter subscribers to stay on top of the news and at the top of your game.
Welcome to episode 300 of The Cloud Pod – where the forecast is always cloudy! According to the title, this week's show is taking place inside of a Dr. Suess book, but don't despair – we're not going to make you eat green eggs and ham, but we WILL give you the low down on all things Vegas. Well, Google's Next event which recently took place in Vegas anyway. Did you make any Next predictions? Titles we almost went with this week: This is the CLOUDPOD Episode 300 Tonight we dine in the Cloud The Next Chapter Now in Preview: Episode 300 A big thanks to this week's sponsor: We're sponsorless! Want to get your brand, company, or service in front of a very enthusiastic group of cloud news seekers? You've come to the right place! Send us an email or hit us up on our slack channel for more info. GCP Pre-Next 02:35 Google shakes up Gemini leadership, Google Labs head taking the reins There was a lot of Gemini news at Next – but we'll get to all that. In this particular case, there's an employee shakeup. Sissie Hsiao is stepping down from leading the Google team, and is being replaced by Josh Woodward, who is currently leading the Google Labs. 04:35 Filestore instance replication now available GCP says customers have been asking for help in meeting business and regulatory goals, and so they are releasing Filestore instance replication. This new feature offers an efficient replication point objective (RPO) that can reach 30 minutes for data change rates of 100 MB/sec. 05:16 Multi-Cluster Orchestrator for cross-region Kubernetes workloads The public preview of Multi-Cluster Orchestrator was recently announced. This lets platform and application teams optimize resource utilization, enhance application resilience, and accelerate innovation in complex, multi-cluster environments. The need for effective multi-cluster management has become essential as organizations increasingly use Kubernetes to deploy and manage their applications; Challenges such as resource scarcity, ensuring high availability, and managing deployments across diverse environments create significant operational overhead. Multi-Cluster Orchestrator addresses these challenges by providing a centralized orchestration layer that abstracts away the complexities of underlying Kubernetes infrastructure matching workloads with capacity across regions. 06:26 GKE at 65,000 nodes: Evaluating performance for simulated mixed AI workloads Recently GKE announced it can now support up to 65,000 nodes (up from 15,000.) Saint Carrie be with your CFO. 09:15
Ever tried solving DNS security across a multi-cloud, multi-cluster Kubernetes setup? In this episode recorded live at KubeCon, Ashish chats with Nimisha Mehta and Alvaro Aleman from Confluent's Kubernetes Platform Team.Together, they break down the complex journey of migrating to Cilium from default CNI plugins across Azure AKS, AWS EKS, and Google GKE. You'll hear:How Confluent manages Kubernetes clusters across cloud providers.Real-world issues encountered during DNS security migration.Deep dives into cloud-specific quirks with Azure's overlay mode, GKE's Cilium integration, and AWS's IP routing limitations.Race conditions, IP tables, reverse path filters, and practical workarounds.Lessons they'd share for any platform team planning a similar move.Guest Socials: Alvaro's Linkedin + Nimisha's Linkedin Podcast Twitter - @CloudSecPod If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our other Cloud Security Social Channels:-Cloud Security Podcast- Youtube- Cloud Security Newsletter - Cloud Security BootCampIf you are interested in AI Cybersecurity, you can check out our sister podcast - AI Cybersecurity PodcastQuestions asked:(00:00) Introduction(01:55) A bit about Alvaro(02:41) A bit about Nimisha(03:11) About their Kubecon NA talk(03:51) The Cilium use case(05:16) Using Kubernetes Native tools in all 3 cloud providers(011:41) Lessons learnt from the projectResources spoken about during the interviewConfluent's Multi-Cloud Journey to Cilium: Pitfalls and Lessons Lea... Nimisha Mehta & Alvaro Aleman
Send us a textWhat happens when you get Eyvonne, William, and our special guest Nick Eberts in the same conversation? You get a GKE party! In this episode, we dive deep into the world of multi-cluster Kubernetes management with Nick Eberts, Product Manager for GKE Fleets & Teams at Google. Nick shares his expertise on platform engineering, the evolution from traditional infrastructure to cloud-native platforms, and the challenges of managing multiple Kubernetes clusters at scale. We explore the parallels between enterprise architecture and modern platform teams, discuss the future of multi-cluster orchestration, and unpack Google's innovative work with Spanner database integration for GKE. Nick also shares his passion for contributing to open source through SIG Multi-Cluster and provides valuable guidance for those interested in getting involved with the Kubernetes community.Where to Find Nick EbertsLinkedIn: https://www.linkedin.com/in/nicholasebertsTwitter: https://twitter.com/nicholasebertsBluesky: @nickeberts.devShow LinksSIG Multi-Cluster: https://github.com/kubernetes/community/tree/master/sig-multiclusterGoogle Kubernetes Engine (GKE): https://cloud.google.com/kubernetes-engineSpanner Database: https://cloud.google.com/spannerKubernetes: https://kubernetes.io/KubeCon: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/Argo CD: https://argoproj.github.io/cdFlux: https://fluxcd.io/CNCF: https://www.cncf.io/Follow, Like, and Subscribe!Podcast: https://www.thecloudgambit.com/YouTube: https://www.youtube.com/@TheCloudGambitLinkedIn: https://www.linkedin.com/company/thecloudgambitTwitter: https://twitter.com/TheCloudGambitTikTok: https://www.tiktok.com/@thecloudgambit
EU Cloud Sovereignty & Open Source AlternativesMarket OverviewCurrent EU Cloud Market ShareAWS: ~33% market share (Frankfurt, Ireland, Paris regions)Microsoft Azure: ~25% market shareGoogle Cloud Platform: ~10% market shareOVHcloud: ~5% market share (largest EU-headquartered provider)EU Sovereign Cloud ProvidersFull-Stack European SolutionsOVHcloud (France)33 datacenters across 4 continents, 400K+ serversVertical integration: custom server manufacturing in RoubaixProprietary Linux-based virtualization layerSelf-built European fiber backboneIn-house distributed storage system (non-S3 compatible)Scaleway (France)Growing integration with French AI companies (e.g., Mistral)Custom hypervisor and management planeARM-based server architecturesDatacenters in France, Poland, NetherlandsGrowing rapidly in SME/startup segmentHetzner (Germany)Bare metal-focused infrastructureProprietary virtualization layer100% European datacenters (Germany, Finland)Custom DDoS protection systems designed in GermanyComplete physical/logical isolation from US networksOther European ProvidersDeutsche Telekom/T-Systems (Germany)Orange Business Services (France)SAP (Germany)Leading Open Source Cloud PlatformsTier 1OpenStackMost mature, enterprise-ready open source cloud platformComprehensive IaaS functionality with modular architectureKey components: Nova (compute), Swift (object storage), Neutron (networking)Strong adoption in telecommunications, research, government sectorsKubernetes"Cloud in a box" container orchestration platformNot a complete cloud solution but foundational componentCross-cloud compatibility (GKE, EKS, AKS)Key features: exceptional scalability, self-healing, declarative configurationFacilitates workload portability between cloud providersTier 2Apache CloudStackEnterprise-grade IaaS platformSingle management server architectureStraightforward installation, less architectural flexibilityMature and stable for productionOpenNebulaLightweight virtualization managementLower resource requirements than OpenStackStrong integration with VMware and KVM environmentsEmerging PlatformsRancher/K3sLightweight Kubernetes distributionOptimized for edge computingSimplified binary deployment modelGrowing edge computing ecosystemOKD (OpenShift Kubernetes Distribution)Upstream project for Red Hat OpenShiftDeveloper-focused capabilities on KubernetesGeopolitical & Strategic ContextGrowing US-EU tension creating market opportunity for European cloud sovereigntyEuropean emphasis on data privacy, rights-based innovation, and technological independencePotential bifurcation between US and European technology ecosystemsRising concern about Big Tech's influence on governance and sovereigntyEuropean cloud providers positioned as alternatives emphasizing human rights, privacyTechnical Independence ChallengesProcessor architecture dependencies (Intel/AMD dominance)European Processor Initiative and SiPearl developing EU alternativesFull software stack independence remains aspirationalNetwork equipment supply chain complexities
Guests are Maciej Rozacki, Product Manager on GKE for AI Training, and Wojciech Tyczyński, Software Engineer on the GKE team at Google. We explore what it means for GKE to support 65k nodes, and the open source contributions that made this possible 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 The Kubernetes Podcast is on Bluesky OpenTelemetry expanding into CI/CD observability Gitpod is moving away from Kubernetes OpenCost is a CNCF Incubated project Links from the interview Guests: Maciek Wojciech Kubernetes OSS Scalability thresholds PGS on the Kubernetes Podcast Batch Working Group Serving Working Group episode on the podcast Dynamic Resource Allocation Kueue Multitenancy and Fairness at Scale with Kueue SIG Scalability Links from the post-interview chat Consistent Reads from Cache Kubernetes Scalability: A Multi-Dimensional Analysis
In this episode, Frank and Steve discuss the July 2024 FinOps announcements from AWS, Azure, and Google Cloud. They cover topics such as committed use discounts, fully licensed commitments, hibernation for VMs, cost management features, and service discontinuations. The conversation is filled with insights and analysis of the latest developments in the cloud industry.There are new machine types available on GCP, such as the C3 bare metal machine types and the sixth generation Intel-based VMs.Serverless compute options, like Azure Databricks and OpenSearch serverless, provide efficient and cost-effective ways to run workloads without managing infrastructure.Storage enhancements, such as the Convert Azure Premium SSD v2 disk and Amazon FSX for Open ZFS, offer improved performance and cost optimization.Log management tools, like Azure Monitor Logs and AWS Cost Categories, help users collect, analyze, and act on telemetry data from various resources.Cost optimization features, like AWS Focus 1.0 and GCP backup commitment-based use discounts, provide ways to optimize cloud spending. Committed use discounts are available for backup for GKE, allowing users to commit to a consistent amount of usage in exchange for a discounted rate.AWS now offers fully licensed commitments and portable license commitments for purchasing VMware engine commitments, providing customers with more options for using VMware in the cloud.VM hibernation is now generally available in Azure and AWS, allowing users to save compute costs by persisting the VM state in memory and deallocating the VM.Azure has introduced a cost card in the portal, allowing engineers to estimate costs and adjust as needed before deploying VMs.Google Cloud's FinOps Hub now allows users to view their carbon footprint and estimated greenhouse gas emissions for their Google Cloud usage.AWS has announced the discontinuation of several services, including Cloud9, SimpleDB, Forecast, and CodeCommit, indicating a shift in focus and priorities.
In this episode, we talk to three active leaders who have been around since the very beginning of Kubernetes. We explore how Kubernetes has changed since its inception, with a particular focus on current efforts in Open source Kubernetes to support AI/ML style workloads. Maciej Szulik is currently taking a seat in the Kubernetes Steering Committee. He's also leading Special Interests Groups responsible for kubectl, workload and batch controllers. Maciej has been contributing to Kubernetes since the early days, jumping from one area to another where help was needed. He authored the first version of audit and helped shape its current one, as well as touched multiple other places in apimachinery. He was also responsible for designing and implementing Job and CronJob controllers. In kubectl he was responsible for the plugin mechanism and several major refactors to simplify the code. Since May 2024 he joined the ranks of Production Readiness Review (PRR) approvers helping ensure high production standards for the future of Kubernetes releases. Clayton Coleman is a long-time Kubernetes contributor, having helped launch Kubernetes as open source, being on the bootstrap steering committee, and working across a number of SIGs to make Kubernetes a reliable and powerful foundation for workloads. At Red Hat he led OpenShift's pivot onto Kubernetes and its growth across on-premise, edge, and into cloud. At Google he is now focused on enabling the next generation of key workloads, especially AI/ML in Kubernetes and on GKE. Dawn Chen has been a Principal Software Engineer at Google cloud since May 2007. Dawn has worked on an open source project called Kubernetes before the project was founded. She has been one of tech leads in both Kubernetes and GKE, and founded SIG Node from scratch. She also led Anthos platform team for the last 4 years, and mainly focuses on the core infrastructure. Prior to Kubernetes, she was the one of the tech leads for Google internal container infrastructure -- Borg for about 7 years. Outside of work, she is a wife, a mother of a 16-year old boy and a good friend. She enjoys reading, cooking, hiking and traveling. 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 Kubernetes 1.31 Code Freeze is on July 9th Links from the interview Kubernetes Working Group Batch Kubernetes Working Group Serving Blog: Introducing Indexed Jobs (2021) Docs: Kubernetes Jobs KEP: Elastic Indexed Jobs Docs: Kubernetes CronJobs KubeCon EU 2021: The Long, Winding and Bumpy Road to CronJob's GA - Maciej Szulik, Red Hat & Alay Patel, Red Hat KubeCon EU 2018: Writing Kube Controllers for Everyone - Maciej Szulik, Red Hat (Beginner Skill Level) Kubernetes Working Group Device Management Kubernetes Enhancement Proposal process README DockerCon 2014: The announcement of Kubernetes at DockerCon Blog: AI & Kubernetes (by Kaslin) Kueue - “Kueue is a cloud-native job queueing system for batch, HPC, AI/ML, and similar applications in a Kubernetes cluster.” Whitepaper: Large-scale cluster management at {Google} with {Borg} Email: “Containers: Introduction” - An email introducing the concept of Linux containers to the Linux community Links from the post-interview chat Blog - “Scaling Kubernetes to 7,500 nodes” - OpenAI Ray on Kubernetes
Welcome to episode 264 of the Cloud Pod Podcast – where the forecast is always cloudy! Justin, Jonathan, Ryan (and eventually) Matthew are all on hand this week – and *announcement noise* this week it's the return of the Cloud Journey Series! There's also a lot of news from Re:inforce, a ground-breaking partnership between Oracle and Google Cloud, and updates to GKE. The guys also look ahead to Finops ‘24. Titles we almost went with this week: First, AI came for Writers/Artists, then it came for Developers, and now it comes for Security… What’s Next? Amazon Reinforces my Lack of Interest in Attending – JPB rl Object Storage Malware protection, everyone, please copy it! Amazon is the last man out in Oracle next-gen partnerships Dear Google, A partnership with Oracle is not Groundbreaking when Azure already did it AWS Announces some “We finally got around to it feature updates” Protect your S3 buckets from themselves with Amazon Guard Duty The CloudPod and AI play Guess Who? with IAM Access Analyzer. A big thanks to this week's sponsor: We're sponsorless! Want to reach a dedicated audience of cloud engineers? Send us an email, or hit us up on our Slack Channel and let's chat! AWS 01:04 Simplify risk and compliance assessments with the new common control library in AWS Audit Manager AWS Audit Manager is introducing a common control library that provides common controls with predefined and pre-mapped AWS data sources. This makes it easy for the GRC teams to use the common control library to save time when mapping enterprise controls into Audit Manager for evidence collection, reducing their dependence on IT teams. You can view the compliance requirements for multiple frameworks such as PCI or HIPAA, associated with the same common control in one place, making it easier to understand your audit readiness across multiple frameworks simultaneously. Interested in pricing? You can find that info here. 01:37 Ryan – “It’s the dream! Automated evidence generation. And now with the context of known frameworks. Yeah; because that’s always the challenge, you know, are the last step of the translation – this is the control. Hey, we need all these controls to do this level of compliance.” 04:36 Centrally manage member account root email addresses across your AWS Organization 2017 Justin is really digging all these quality-of-life features coming out, and we like to think that AWS has just finally gotten to our pile of feature requests from back then. This week, it’s now easier for AWS Organizations customers to centrally manage the root email address of member accounts across their organization using the CLI, SDK and Organizations Console.
In this episode, Corey chats with Google's Nick Eberts about how Kubernetes helps manage applications across different cloud environments. They cover the benefits and challenges of using Kubernetes, especially in Google's cloud (GKE), and discuss its role in making applications more flexible and scalable. The conversation also touches on how Kubernetes supports a multi-cloud approach, simplifies the deployment process, and can potentially save costs while avoiding being tied down to one cloud provider. They wrap up by talking about best practices in cloud infrastructure and the future of cloud-native technologies.Show Highlights: (00:00) - Introduction to the episode(03:28) - Google Cloud's approach to egress charges and its impact on Kubernetes(04:33) - Data transfer costs and Kubernetes' verbose telemetry(07:23) - The nature of Kubernetes and its relationship with cloud-native principles.. (11:14) - Challenges Nick's faced managing a Kubernetes cluster in a home lab setting(13:25) - Simplifying Kubernetes with Google's Fleets(17:34) - Introduction to GKE Fleets for managing Kubernetes clusters (20:39) - Building Kubernetes-like systems for complex application portfolios (24:06) - Internal company platforms and the utility of Kubernetes for CI/CD (27:49) - Challenges and strategies of updating old systems for today's cloud environment(32:43) - The dividing line between Kubernetes and GKE from a product perspective. (35:07) - Where to find Nick (36:48) - Closing remarks About Nick:Nick is an absolute geek who would prefer to spend his time building systems but has succumbed to capitalism and moved into product management at Google. For the last 20 years he has worked as a systems engineer, solution architect, and an outbound product manager. He is currently the product manager for GKE Fleets & Teams focusing on multi-cluster capabilities that streamline GCP customers experience while building platforms on GKE. Links referenced: Duck Bill Group's website:http://www.duckbillgroup.com Nick on Twitter/X : @nicholasebertsNicholas Eberts on instagram: https://www.instagram.com/neberts1/Nick on Linkedin: https://www.linkedin.com/in/nicholaseberts/
Guest is Bill Mulligan. Bill is Community Pollinator at Isovalent working on Cilium and eBPF. We learned how to properly pronounce Isovalent and what it actually means. We also spoke in depth about eBPF, Cilium, network function in Kubernetes and more. 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 The Kubernetes legacy Linux package repositories are going away in January 2024 Kubernetes 1.29 is now available on GKE in the Rapid Channel The Vmware Tanzu Application Catalog is fully compliant with the SLSA Level 3 AWS extended support for Kubernetes minor versions pricing update The Kubernetes Contributor Summit Paris CFP is Open, closes Feb 4th KubeCon and CloudNativeCon EU 2024 co-located events agenda is live The Cloud Native Glossary is now available in French Blixt a new experimental LoadBalancer based on the Gateway API and eBPF Links from the interview Bill Mulligan: LinkedIn Twitter/X Covalent bonds on Wikipedia Isovalent Hybridization on Wikipedia Isovalent company site BPF - Berkeley Packet Filtering eBPF project site Fast by Friday: Why eBPF is Essential - Brendan Gregg GKE Dataplane V2 Cilium project site Hubble documentation Cilium Service Mesh Cilium annual report Cilium Certified Associate (CCA) CCA Study Guide from Isovalent on GitHub Istio Certified Associate (ICA) Certified Kubernetes Administrator (CKA) Certified Kubernetes Application Developer (CKAD) Kubernetes and Cloud Native Associate (KCNA) Resources to prepare for the CCA certification Isovalent library The World of Cilium Cisco acquired Isovalent Developing eBPF Apps in Java BGP in eBPF
Portability and ease of deployment are the driving forces behind Acorn, a Kubernetes management platform based on the DevOps concept to simplify the work of Ops and Devs.To discuss how this Open Source project was born and is being developed, Kubicast brings in Darren Shepherd and Shannon Williams, co-founders of Acorn and also creators of Rancher.O Kubicast é uma produção da Getup, empresa especialista em Kubernetes e projetos open source para Kubernetes. Os episódios do podcast estão em getup.io/kubicast, nas principais plataformas de áudio digital e no YouTube.com/@getupcloud.
O Kubicast é uma produção da Getup, empresa especialista em Kubernetes e projetos open source para Kubernetes. Os episódios do podcast estão em getup.io/kubicast, nas principais plataformas de áudio digital e no YouTube.com/@getupcloud.
Not Escaping Containers but escaping Clusters - Managed Kubernetes distributions such as Amazon EKS, Google Kubernetes Engine (GKE) and Azure Kubernetes Service (AKS) attack vectors can allow you to reach the underlying AWS Account etc. In conversation with Christophe Tafani-Dereeper & Nick Frichette, from Datadog on how this is possible in Amazon EKS and achieving potentially the same in GKE & AKS too. Thank you to our episode sponsor Sagetap Guest Socials: Nick's and Christophe's Linkedin (Nick Frichette + Christophe Tafani-Dereeper) Podcast Twitter - @CloudSecPod If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our other Cloud Security Social Channels: - Cloud Security Newsletter - Cloud Security BootCamp Questions asked: (00:00) Introduction (04:11) A bit about Christophe (04:37) A bit about Nick (05:03) What is managed Kubernetes? (06:26) Security of managed Kubernetes (09:02) Comparison between different managed Kubernetes (10:41) Service accounts and managed Kubernetes (14:22) What is container escape? (18:20) IMDSv2 for EKS (19:51) IMDSv2 in EKS vs AKES and GKE (22:01) Benchmark compliance for Kubernetes architecture (24:49) Low hanging fruits for container escape (27:17) Shared responsibility for managed Kubernetes (29:34) Fargate for Managed Kubernetes (32:00) Different ways to run containers (33:37) Escaping Managed Kubernetes cluster (38:39) Find more about this attack path (42:38) Escalation priviledge in EKS cluster (44:19) Reducing the Kubernetes attack service (44:58) MKAT for Kubernetes Security (48:23) Preventing AWS AuthConfig (50:11) Propagation Security (54:55) The fun section (57:47) Resources for latest Kubernetes updates Resources spoken about during the episode Nick Frichette's Blog - Hacking the Cloud Christophe Tafani-Dereeper' Blog Corey Quinn's - 17 ways to run containers on AWS MKAT cloudseclist newsletter
Com a consolidação das fintechs, os avanços do Open Finance e clientes cada vez mais exigentes em relação à digitalização de produtos e serviços, as instituições financeiras estão encontrando na tecnologia um caminho para inovar e se destacar em um mercado cada vez mais competitivo. De olho nesse cenário, o Google Cloud lançou este ano a segunda edição do Finfacts - Descobertas e oportunidades que valorizam os serviços financeiros. Nesse estudo, foi analisado como é o processo de contratação de produtos nos canais digitais nas 21 principais empresas do setor no país e como a tecnologia entra para melhorar essa experiência. No episódio de hoje, convidamos o Banco BV para compartilhar um pouco da sua trajetória de transformação digital e repercutir os principais insights do Finfacts. Marisa Kinoshita, gerente sênior de marketing do Google Cloud Brasil e responsável também pelo Finfacts e outros estudos voltados para diferentes Indústrias, recebe Ricardo Sanfelice, Diretor Executivo de Clientes, Produtos e Inovação do Banco BV; Pedro Britto, Field Sales Representative do Google Cloud; e Fausto Novaes, especialista em Financial Services Industry do Google Cloud. No Conversas na Nuvem, recebemos empresas que estão transformando e inovando o setor em que atuam com a tecnologia em nuvem. Confira os links deste episódio: Finfacts - Descobertas e oportunidades que valorizam os serviços financeiros: https://bit.ly/3rIllFb Banco BV modernizes its banking apps with GKE and Anthos: https://bit.ly/48MJsDe Transcrição do episódio: https://bit.ly/495Z5Wy
Implantar banco de dados em Kubernetes é desafiador, mas possível e cada vez mais comum. Trabalhando há mais de 17 anos com banco de dados, o Sebastian Webber, Senior Software Engineer na Timescale, vem ao Kubicast para contar como foi essa descoberta e como segue sua saga para convencer as pessoas de que “tem que usar banco de dados em Kubernetes!”.Nessa conversa, também falamos de casos de fracasso com banco de dados, operadores de banco para Kubernetes e como convencer na “linguagem do lucro” sobre a importância de investir em infra. Links do episódio:Supercomputer Fugaku: https://www.fujitsu.com/global/about/innovation/fugaku/Meetup com o Somatório: https://www.youtube.com/watch?v=aAiqLwAdYvQOperadores de banco pra K8s: https://github.com/zalando/postgres-operatorhttps://stackgres.io/https://github.com/CrunchyData/postgres-operatorRecomendações do programa:Person of Interest - série Barbie - filme Oppenheimer - filmeO Kubicast é uma produção da Getup, empresa especialista em Kubernetes e projetos open source para Kubernetes. Os episódios do podcast estão em getup.io/kubicast, nas principais plataformas de áudio digital e no YouTube.com/@getupcloud.
Welcome episode 226 of the Cloud Pod podcast - where the forecast is always cloudy! This week Justin, Matt and Ryan chat about all the news and announcements from Google Next, including - surprise surprise - the hot topic of AI, GKE Enterprise, Duet, Co-Pilot, Code Whisperer and more! There's even some non-Next news thrown into the episode. So whether you're interested in BART or Bard, we've got the news from SF just for you. Titles we almost went with this week:
This week, we discuss Netflix's DVD deprecation, the remote work debate, and how to fork an open-source project. Plus, thoughts on why Europe needs more ice. Watch the YouTube Live Recording of Episode (https://www.youtube.com/watch?v=lFr-ysPYxnA) 431 (https://www.youtube.com/watch?v=lFr-ysPYxnA) Runner-up Titles Try Harder It's a necessary luxury Someone's drinking too much water here A culture of ice Where are the high performers, at home or at work Quit using your Gmail address Thou shalt export to CSV Rundown Netflix Says You Can Keep Their DVDs (and Request More, Too) (https://www.nytimes.com/2023/08/24/arts/netflix-dvds.html?smid=nytcore-ios-share&referringSource=articleShare) Zoom's CEO thinks Zoom sucks for building trust, leaked audio reveals (https://arstechnica.com/tech-policy/2023/08/leaked-audio-reveals-zoom-ceo-believes-its-hard-to-build-trust-on-zoom/) Meta is back in the office three days a week, as WFH continues to die (https://www.theverge.com/2023/9/5/23860073/meta-return-to-office-three-days-wfh-work-from-home) Can you trust 'open source' companies? (https://www.theregister.com/2023/08/18/opinion_column/) OpenTF created a fork of Terraform! (https://opentf.org/announcement) OpenTF pulls the trigger on its open-source Terraform fork (https://opensourcewatch.beehiiv.com/p/opentf-pulls-trigger-opensource-terraform-fork) Relevant to your Interests VMware's future: Navigating multicloud complexity and generative AI (https://siliconangle.com/2023/08/19/vmwares-future-navigating-multicloud-complexity-generative-ai-broadcoms-wing/) VMware Tanzu portfolio reshuffled ahead of Broadcom close | TechTarget (https://www.techtarget.com/searchitoperations/news/366549332/VMware-Tanzu-portfolio-reshuffled-ahead-of-Broadcom-close) Nvidia's blowout offers a giddy whiff of 1995 (https://www.axios.com/newsletters/axios-ai-plus-937b329c-8072-4f8a-a5d6-1039a0e794a5.html?chunk=0&utm_term=emshare#story0) Announcing AWS Dedicated Local Zones (https://aws.amazon.com/about-aws/whats-new/2023/08/aws-dedicated-local-zones/?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axioslogin&stream=top) Top Ten social media platforms we spend the most time on (https://www.traveldailymedia.com/top-ten-social-media-platforms-we-spend-the-most-time-on/) Max will launch a 24/7 CNN stream for all subscribers next month (https://www.theverge.com/2023/8/24/23844121/cnn-max-warnerbros-discovery-news) Meta launches own AI code-writing tool: Code Llama (https://www.theverge.com/2023/8/24/23843487/meta-llama-code-generation-generative-ai-llm?stream=top) As TikTok Ban Looms, ByteDance Battles Oracle For Control Of Its Algorithm (https://www.forbes.com/sites/emilybaker-white/2023/08/24/tiktok-ban-oracle-bytedance-algorithm-fight/?sh=6cf5105e3ef0) Slack's Migration to a Cellular Architecture - Slack Engineering (https://slack.engineering/slacks-migration-to-a-cellular-architecture/) The Cloud 100 2023 (https://www.forbes.com/lists/cloud100/) Data isn't everything. Judgement counts too. (https://www.tiktok.com/t/ZT8YFUFju/) Amazon Elastic Block Store at 15 Years (https://perspectives.mvdirona.com/2023/08/amazon-elastic-block-store-at-15-years/?ck_subscriber_id=512840665) Instacart is the Best and Worst Grocery Business Imaginable (https://www.thediff.co/archive/instacart-is-the-best-and-worst-grocery-business-imaginable/) Amazon CEO Andy Jassy tells employees it's 'past' time to commit to the company's RTO mandate and their jobs are at stake (https://www.businessinsider.com/amazon-andy-jassy-rto-office-policy-employee-jobs-2023-8?op=1) Duet AI, Google's AI assistant suite, expands across Google Cloud (https://techcrunch.com/2023/08/29/duet-ai-googles-ai-assistant-suite-expands-across-google-cloud/) Halloween creeps a little closer: Seasonal supply chains accelerate (https://www.spglobal.com/marketintelligence/en/mi/research-analysis/halloween-creeps-closer-seasonal-supply-chains-accelerate.html) What's new with GKE at Google Cloud Next | Google Cloud Blog (https://cloud.google.com/blog/products/containers-kubernetes/whats-new-with-gke-at-google-cloud-next) Duet AI in Google Cloud Preview | Google Cloud Blog (https://cloud.google.com/blog/products/ai-machine-learning/duet-ai-in-google-cloud-preview) What's new in Oracle to PostgreSQL database migrations with DMS | Google Cloud Blog (https://cloud.google.com/blog/products/databases/whats-new-in-oracle-to-postgresql-database-migrations-with-dms) US AI startup Poolside raises $126m seed round and relocates to France (https://sifted.eu/articles/poolside-raises-126m-relocated-france-news) Ping, ForgeRock, Thoma Bravo, the power of open source, and the madness of IAM (https://callmeleach.substack.com/p/ping-forgerock-thoma-bravo-the-power?utm_medium=web) Thoma Bravo Completes Acquisition of ForgeRock; Combines ForgeRock into Ping Identity (https://www.prnewswire.com/news-releases/thoma-bravo-completes-acquisition-of-forgerock-combines-forgerock-into-ping-identity-301908059.html) Interoperability between Google Chat and other messaging platforms — powered by Mio (https://workspaceupdates.googleblog.com/2023/08/goolge-chat-slack-interoperability-mio.html) Broadcom boss dismisses notion China could derail VMware buy (https://www.theregister.com/2023/09/01/broadcom_vmware_nutanix_results/) Microsoft blames outage on small staff, automation failures (https://www.theregister.com/2023/09/04/microsoft_australia_outage_incident_report/) Amazon QuickSight adds scheduled and programmatic export to Excel format (https://aws.amazon.com/about-aws/whats-new/2023/08/amazon-quicksight-scheduled-programmatic-export-excel-format/?ck_subscriber_id=512840665) Google unveils AI tools for enterprise customers at $30 a month (https://www.reuters.com/technology/google-unveil-ai-tools-corporate-gmail-customers-30-month-wsj-2023-08-29/) Chip design firm Arm seeks up to $52 billion valuation in blockbuster U.S. IPO (https://www.cnbc.com/2023/09/05/chip-design-firm-arm-sets-share-price-between-47-and-51-for-blockbuster-us-ipo.html) Birmingham City Council goes under after Oracle disaster (https://www.theregister.com/2023/09/05/birmingham_city_council_oracle/?s=08) IBM Introduces 'Watsonx Your Business' (https://finance.yahoo.com/news/ibm-introduces-watsonx-business-160000392.html) Meta May Allow Instagram, Facebook Users in Europe to Pay and Avoid Ads (https://www.nytimes.com/2023/09/01/technology/meta-instagram-facebook-ads-europe.html?smid=nytcore-ios-share&referringSource=articleShare) Announcing Kubecost Cloud in General Availability: The Easiest Way to Optimize Your Kubernetes Costs (https://blog.kubecost.com/blog/kubecost-cloud-general-availability/) Platform Engineering - What You Need To Know Now (https://tanzu.vmware.com/content/ebooks/platformengineering-whatyouneedtoknownow?utm_source=cote&utm_campaign=devrel&utm_medium=newsletter&utm_content=newsletter20230830) The lifespans of technological adoptions in the US (http://www.asymco.com/2022/01/10/the-lifespans-of-technological-adoptions-in-the-us/) Introducing ONCE (https://once.com/) Nonsense The fight for the right to repair McFlurry machines (https://www.morningbrew.com/daily/stories/2023/08/31/the-fight-for-the-right-to-repair-mcflurry-machines) Delta Airlines Offers Woman $1,800 After Losing Her Dog (https://www.yahoo.com/entertainment/delta-airlines-offers-woman-1-142849291.html) Conferences Sep 18th to 19th SHIFT (https://shift.infobip.com/) in Zadar, Coté speaking. October 6, 2023, KCD Texas 2023 (https://community.cncf.io/events/details/cncf-kcd-texas-presents-kcd-texas-2023/), CFP Closes: August 30, 2023 November 6-9, 2023, KubeCon NA (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/), SDT's a sponsor, Matt's there November 6-9, 2023 VMware Explore Barcelona (https://www.vmware.com/explore/eu.html), Coté's attending Jan 29, 2024 to Feb 1, 2024 That Conference Texas (https://that.us/events/tx/2024/schedule/) If you want your conference mentioned, let's talk media sponsorships. SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Get a SDT Sticker! Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us: Twitch (https://www.twitch.tv/sdtpodcast), Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/), Mastodon (https://hachyderm.io/@softwaredefinedtalk), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk), Threads (https://www.threads.net/@softwaredefinedtalk) and YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured). Use the code SDT to get $20 off Coté's book, Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Become a sponsor of Software Defined Talk (https://www.softwaredefinedtalk.com/ads)! Recommendations Brandon: JUST ONE MILE | Official Trailer (https://www.youtube.com/watch?v=80V5o06yEZ4) Matt: Deadloch (https://www.imdb.com/title/tt14671678/) Coté: Rick Rubin interviews Rory Sutherland (https://www.youtube.com/watch?v=VnYlChfORRw). I doubt much of the airport business book stuff in here is “true,” but that's sort of the whole point, and it's fantastic listening. His book (https://amzn.to/462Mvov) Alchemy (https://amzn.to/462Mvov) has a great one word review right there in the title. But, again: it's fun! When you've listened to too much If Books Could Kill (https://en.wikipedia.org/wiki/If_Books_Could_Kill) you can check in on Rory if you need to take the cure (https://idioms.thefreedictionary.com/take+the+cure). Photo Credits Header (https://unsplash.com/photos/PsBTqRHVilU) Artwork (https://labs.openai.com/e/bKjqW8kPJyI2wuzBA0FogiKb/UJeLhuIFmvkrNFbfcCc4jE29)
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
Kendall Miller is the Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. The first half of the conversation with host Victoria Guido and special guest host, Joe Ferris, CTO of thoughtbot revolves around the use, adoption, and growth of Kubernetes within the technology industry. The discussion explores Kubernetes' history, influence, and its comparison with other platforms like Heroku and WordPress, emphasizing its adaptability and potential. The second half focuses on more practical aspects of Kubernetes, including its adoption and scalability. It centers on the appropriateness of adopting Kubernetes for different projects and how it can future-proof infrastructure. The importance of translating technical language into business speak is emphasized to influence executives and others in the decision-making process and Kendall also discuss communication and empathy in tech, particularly the skill of framing questions and understanding others' emotional states. __ CTO Lunches (http://ctolunches.com/) Follow CTO Lunches on LinkedIn (https://www.linkedin.com/company/ctolunches/) or Twitter (https://twitter.com/cto_lunches). Follow Kendall Miller on LinkedIn (https://www.linkedin.com/in/kendallamiller/). Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Kendall Miller, Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. Kendall, thank you for joining me. KENDALL: Thanks for having me. I'm excited. VICTORIA: And today, we have a special guest host, Joe Ferris, CTO of thoughtbot. Joe, thank you for joining us. JOE: Hello there. Thank you for having me. KENDALL: Hi, Joe. Thanks for being here. It's exciting. VICTORIA: Yes. It's so exciting. I think this is going to be a great episode. So, Kendall, I met you at a San Diego CTO lunch recently, and I know that's not the only thing that you do. So, you're also an advisor, a board member, and CXO. So, maybe tell us a little bit more about your background. KENDALL: Gosh, my background is complicated. I've been involved in tech for a very long time. In college, I worked for a company that started Twitter about five years too soon, and then worked in the nonprofit space in China for ten years, then came back, got back involved in tech. Today, I'm usually the business guy. So, when technical founders start technical products and want help turning them into successful technical businesses, that's when they call me. So, I have the technical background. I have never been paid to write code, which is probably a good thing. But I can hang in the technical conversations for the most part, but I'm much more interested in the business side and the people leadership side of business. So that tends to be where I play. Every organization hires me to do something different. VICTORIA: Thank you for that. And I'm just curious about the CTO Lunches. Just tell me a little bit more about that. And what's the idea behind it that led you to co-found it? KENDALL: CTO Lunches has actually been around for about eight years. And I didn't start the initial incarnation of it. It was two people that got us started, and I was trying to hire one of them; one thing led to another. Actually, originally, they did not want me to join. I think, at the time, my title was COO at a company that I was working with. About six months later, I took over engineering as VP of engineering, and then they're like, you can join the group now. We're less strict about that [laughs] now. Although it is highly focused on senior engineering leaders, it's not exclusively CTOs. But the group's been in place for a very long time, just intended as a place to network, have conversation with people who are in that senior-most technical position at technical organization. So, the CTO role is a lonely role. CTOs get fired all the time. There's not a technical person at the company that doesn't think they can do the job better than them. So, the CTO is always getting feedback. You're doing this wrong. The trade-offs you're making are wrong. This isn't going where it should be going. We should automate that. Why haven't we automated that? We should switch to this other tool. I've used it before; it's 100 times better. Joe, let me know if I'm getting any of this wrong. But that's the experience that I've had. Having a place where people can get together and, you know, half the time just complain to each other, hey, this is hard, is really why the networking group exists. So, it's a listserv. And there are local lunches that started in Boulder, Colorado. It's gotten pretty global. About a year ago, a little over a year ago, I was talking with one of the people who'd gotten it started. I've been involved in the Denver chapter for most of those eight years. And I was suggesting to him that he change a few things about it, to monetize it so that he could invest in it further. And he came back a few months later and said, "I want to take your advice and do this, but I want you to come do it with me." So, we founded the company officially...I think in December is when paperwork went into place. And we started investing in it a little bit more heavily. I was living in Europe last year, so we went and put on lunches in Paris, and Lisbon, and London, and, gosh, all over the place. I'm sure I'm missing some, Amsterdam. But there's been chapters all over the U.S. and a couple of other parts of the world for a long time. VICTORIA: That reflects my experience attending a CTO lunch. It's just very casual, like, just get together and eat food and talk about what you've worked on recently, issues you're having, just get ideas and make some friends. So, I really appreciated the group, and I'm going to personally plug the San Diego Chapter has picked up again. And we're meeting next Friday down in Del Mar. And we're going to be meeting on the last Friday of every month through October. So, I'm super excited to be a part of the group. And Joe, yeah, I'm curious about your perspective. As a CTO with thoughtbot, just what are your thoughts about that kind of thing? KENDALL: Yeah. How right am I about how lonely you are, Joe? JOE: [laughs] You know, I've been lonelier since we went remote. I used to work in the office, and I was a CTO, but also, I had lunch with people, which was nice. So, I'm lonelier. But yeah, I think everybody needs a group like that, like, senior developer therapy just to talk about your woes together, drown your sorrows. KENDALL: Well, I think years ago, I heard that CTOs are the most fired C-level executive. JOE: You're making me nervous now. KENDALL: [laughs] You've been there a long time, Joe. I know you've been there a long time. If you haven't been fired yet, you probably got a little while longer in you. This will be really awkward if it's published and you've already been fired. VICTORIA: We can always edit that out afterwards. [laughter] KENDALL: Yeah, no, I think it is a particularly lonely position. And, again, I think a lot of it is the average engineer in a technical company doesn't look at the COO or the CFO or even the CEO and think I could do that. But they're all looking at the CTO and thinking, what does that person do that I can't do? It's ridiculous because most of them would make terrible CTOs because it does require some of the business sense. Or, you know, right out of the gate, they might make terrible CTOs. It actually is quite a skill to be the most technical person and speak the business language. I mean, am I right about that, Joe? Like, was that hard for you to learn? JOE: Yeah, I definitely think...so, my background is also technical. I have a background in consulting. So, I always did a lot of metaprogramming, if you will. But making that transition to thinking about organizations that way, thinking about how all the other pieces play into it, was a pretty big step for me, even before I became a CTO as a consultant. KENDALL: Well, because you can't just chase the newest, hottest technology. You have to make business trade-offs. And not everything can be resume-driven development, right? Even if that technology over there is newer or hotter, it doesn't mean you have a business model that supports it. And it doesn't mean that migrating to it can be done, right? JOE: Yeah. I mean, even beyond choosing technologies, just choosing where to invest in your software stack, like, what needs to be reworked, what doesn't, and trying to explain those trade-offs, I think, is a rare skill. Being able to explain why something would be harder than something else when you're working with the leadership to prioritize a backlog it's a puzzle. KENDALL: Well, and I think when I'm in an executive conversation, and the CTO says, "Here's the thing that I think is the best decision technically, and I think it's the wrong decision for the business because of X, Y, or Z," I'm always super impressed, right? Like, this is the right technical solution for what we want. However, we shouldn't pursue that for business reasons right now. Maybe we can in six months, but right now, we need to prioritize this other thing. I don't know, that's always when I feel like, oh, this person knows what they're doing. JOE: There's nothing more dangerous to software than a bored developer. [laughs] One nice thing about being a consultant is that I don't have to invent problems to solve with technology at my company because sooner or later, I'll run across a company that has those problems, and I'll get to use that technology. But I think a lot of people are mostly happy...they might be happy in their role. They might be happy with our team. But they're very interested in whatever is hot right now, like machine learning, AI. And so, suddenly, that surreptitiously makes its way into the tech stack. And then, years later, it's somebody's problem to maintain. KENDALL: [laughs] Well, I have a specific memory of a firm in New York City that was, you know, this is relevant to y'all as thoughtbot is that, you know, at least historically, it was, to me, the premier Ruby on Rails consulting shop. I think that's still largely y'alls focus. Am I right about that? JOE: We still do a ton of Rails, yeah. KENDALL: Okay. Well, so this organization was all Ruby on Rails. It was a big organization. They had a very large customer base. And they hired a new CTO who came in, told everybody in the company they were stupid, laid off 70% of the engineering organization, and told the CEO he was going to completely rewrite the product from scratch in .NET, and he could do it in three weeks. And I'm pretty sure the business went under about three months later [laughs] because that was just so outrageously nuts to me. JOE: It's too bad he laid everybody off beforehand. I've been in that situation where somebody tells me, "I'm going to rewrite this. It'll be ready in three weeks." And I could fight with them and try and convince them they're wrong. But I feel like somebody who's approaching that with that attitude they're missing all of the nuance and context that would make it possible to explain to them why it's not going to work. And so, it's easier to just say, "You know, take the three weeks. I'll talk to you in three weeks." But if you've already laid off your development team, that's hard [laughs] to recover from. KENDALL: That's exactly right. VICTORIA: There's got to be a name for that kind of CTO who just wants to come in and blow everything up [laughs]. Yeah, so you spend a lot of time talking to different CTOs and doing this social networking aspect. I'm wondering if there's, like, patterns that you see. You've mentioned already one about just, like, the most often getting fired. [laughs] But what are the patterns you see, like, in challenges, and then what makes someone successful in that CTO role? KENDALL: Well, oh gosh, I have so many thoughts about this. First of all, I run into a couple of different categories of CTOs. There's a lot of people who come to CTO Lunches who are small company CTOs. I mean, it makes sense that there's a lot more small company CTOs than there are big company CTOs. But the small company CTO who maybe it's their first gig in the role or they're a serial CTO. There's the fractional CTOs that come that are doing it across several different organizations at the same time, and then there's the big company CTO who shows up. And honestly, all of their problems are very different. The thing that they have in common is even at a very large organization, in that position, they can make a decision that causes the company to go under. So, there is a significant amount of volatility in the amount of power that they wield. So, what's interesting about that is not everybody understands that. And so, first of all, there's the kind of CTO that just doesn't get that, and that doesn't matter if they're fractional, or a small company CTO, or a big company CTO. If they don't understand that, they're going to cause significant problems, right? Like the person I just mentioned who said, "I can just re-platform this in three weeks in .NET." There's that. I mean, I think, as with any senior leadership position, the comfort with volatility, the ability to know what to communicate down versus across and versus up, and then the ability to speak the business language. For everybody, the CFO's job is to communicate the financial needs alongside of the business leads, right? If the CFO's sole goal is to cut costs or make sure we're running as lean as possible, they're a bad CFO. But they're not as good of a CFO as the CFO who can say, "Hey, we're underspending right here. And I can look at the numbers and know we should invest more there. How can we invest more there and invest it well?" And it's the same thing for a technology executive to be able to look at the business context and communicate it back. And there are so many CTOs that I've worked with who they're the most technical person in the room, and they know it. And as a result, they're just a jerk to everyone around them, like, everything you did here was wrong. You know, that's where they fail. And so, if they can communicate the business needs, navigate the volatility, and support a team that's going to make decisions that aren't always the same decision they're going to make, they're going to be successful. Honestly, there's very, very few CTOs that I've met like that. People who are excited to meet you at work, excited to see you succeed, excited to see that you went and built a thing is great. I mean, the reason I was VP of engineering is the CTO that I was working with at the time...it's a terrible story. There was an engineer who had seen something that we were doing on repeat all the time and, in his spare time, spent about 40 hours outside of work, not during work hours, automating this task that we were doing regularly. And it was related to standing up a whole bunch of things in our standard infrastructure. He brings it to the CTO and says, "Look what I built." And the CTO, instead of saying, "Hey, this is incredible. Thank you. This is going to save us a bunch of time. Let's iterate on it. Here's some things I'd like to tweak. Can we bring it in this direction? Can we..." you know, whatever, said, "Why is this in Python? It should be in Ansible," something like that. I can't remember. And the engineer literally burst into tears. [laughs] JOE: Oh my God. KENDALL: [laughs] Well, I mean, yeah, it was like; literally, that's why the CTO stopped managing people that day. There's a lot of examples that I have like that. Joe, I appreciate that your response is, "Oh my God." Because I think there's a lot of people who'd be like, wait, what was wrong with that? Shouldn't it have been in Ansible? JOE: [laughs] Yeah, I've seen CTOs come into primarily two groups. One is the CTO who just tells, you know, like, they make the decisions, and they tell everybody what to do. They obviously don't have all of the information because you can't be in every room all the time. And the other is the CTO, who just wants to be one of the team members and doesn't make any decisions and tries to get people to make decisions collectively on their own without any particular guidance or structure. And finding that middle spot of, like, not just saying, "Hey, everything's in Ansible," allowing for the creativity and initiative, but also coalescing the group into a single direction, I think, is what makes a good CTO. KENDALL: Well, yeah, because the CTO does have to say no, sometimes, right? Like, the best product, people say, "No." Good CTOs say, "No." There is some amount of, hey, I need you to come to me with trade-offs about this. Why are you going to make that decision? And I'm sorry, you still didn't convince me, right? Like, I mean, those are appropriate things to say. But yeah, I'm with you on that. You said they fall into two categories. But you really mean the third and that middle ground. Is it easy for you to walk that middle ground, Joe? JOE: I wouldn't say it's easy. [laughs] KENDALL: Yeah. Well, I'm always nervous to say something. I'm doing well because I know there's a report out there that can point at every time I failed at it, right? So... MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you're tight on time and investment, which is why we've created targeted 1-hour remote workshops to help you develop a concrete plan for your product's next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at: tbot.io/entrepreneurs. VICTORIA: Yeah, what I'm getting from what you're saying, too, is this communication ability and not just, like, to communicate clearly but with a high level of empathy. So, if you say like, "Well, why is it in Python and not Ansible?" is different than being like, "What makes Python the best solution here?" Like, it's a different way to frame the question that could put someone on the defensive that just really requires, like, a high level of emotional intelligence. And also, if they've just worked, like, an 80-hour week, [laughs] I probably would maybe choose a different time to bring those questions up and notice that they have been burning the candle at both ends and prioritize getting them some rest. So, speaking of, like, communication and getting prioritization for [inaudible 15:34], especially on, like, infrastructure teams, maybe we could talk a little bit about Kubernetes, like, when that comes up as an appropriate solution, and how you talk about it with the business. KENDALL: My background with Kubernetes is long because a company that I still work with, Fairwinds, used to be called ReactiveOps, has been in the Kubernetes space for a very long time. I think we were one of the very first companies working with Kubernetes. It was coming up that people were running into the limits of something like Heroku, right? And I think it's Kelsey Hightower who said every company wants a PaaS. They just want the Paas that they built themselves. And that's really accurate. And I think Kubernetes isn't quite a framework for building your own PaaS or isn't quite a foundation where I think of a foundation for a house. Instead, it's more like rebar and cement and somebody saying, "Good luck, buddy." You know, you still have to know how to put the rebar and cement together to even make the foundation, but it is the building blocks that help get you to a custom-built PaaS. And it's become something that a lot of people have landed on as, you know, the broadly accepted way to build cloud-native infrastructure. The reason I've been in the Kubernetes space and the space that I see Kubernetes still filling is we need to standardize on something. We can choose a cloud provider's PaaS. We can choose a third-party PaaS, or we can standardize on something like Kubernetes. And even though we're not going to migrate from AWS to Azure, the flexibility that Kubernetes gives us as a broadly adopted pattern is going to give us some ability to be future-proofed in our infrastructure in a way that previous stacks were not, you know, it was Puppet, and it was Ansible. And it was SaltStack. And it was all Terraform all the time. I'm not saying those things don't exist anymore. I'm saying Kubernetes kind of has won that battle. Joe, since you're here and I know y'all are doing some Kubernetes work now at thoughtbot, I'm curious if you agree with that characterization. JOE: Yeah, I think that's true. I think it's the center for people to coalesce around. Like, for an effort in the industry to move forward, there needs to be some common language, some common ground. And I think Kubernetes struck the right balance of being abstract. So, you can use it in different environments but still making some decisions, so you don't have to make them all. And so, like, all of the things you had to do with containers like figuring out what your data solution is going to be, what your networking solution is going to be, Kubernetes didn't even really make those decisions. [laughs] They just made a platform where those decisions can be made in a common way. And that allowed the community and the ecosystem to grow. KENDALL: I mean, I think of it a lot like WordPress; you know, WordPress is hated by many. When WordPress came out, it was hot, right? And it was PHP, which everybody was super excited about at the time. Kubernetes is going to reach a point where it's as long in the tooth and terrible as people think WordPress is, but it has become the standard. And the advantage of the standard is you can use the not standard. You can go build a website in Jekyll instead of WordPress, and there's going to be some things that are nicer about Jekyll. But because WordPress is so broadly adopted, there's a plugin for everything. And I think that's where Kubernetes sits is because it's become so widely adopted everybody's building for it. Everybody's adapting for it. If you run into a problem, you're going to find somebody else out there who has that problem. In fact, I think of one organization that I know that was on HashiCorp's Nomad. And they said, "Actually, we think Nomad has better technology through and through. But we think we're the only company at this size and scale using Nomad. And so, when we run into a problem, we can't Google for it. There's no such thing as a plugin that exists to solve this. Nobody has ever run into this before on Nomad. But there's 100 companies dealing with the same problem in Kubernetes, and there's ten solutions." And I think that's the power that it brings. VICTORIA: So, it's not just a trend that CTOs are moving towards, you think. KENDALL: I mean, I think it's already won the battle and the hockey stick of adoption. We're still right at the very bottom of that tick-up because it takes people a long time to adapt new technology like this, especially in their infrastructure. It's a big migration, to move. So, I don't think it's the widely adopted infrastructure technology even yet. I think a lot of the biggest organizations are still running on things that predate Kubernetes. But I think it has won the battle, and it is winning the battle and is going to be the thing going forward, so yeah. JOE: I think it also has a lot of room to grow still. Like, there are other technologies that I used previously, like Docker, and they were a big step up from some of the things I was doing at the time. But you quickly hit the ceiling, or it was, like, I don't know where to go with this next. I don't know what else is going to happen. Whereas with Kubernetes, there are so many directions it can go in. Like, the serverless Kubernetes offerings that are starting to pop up are extremely interesting, where, you know, you don't actually maintain a cluster or anything. You just deploy things to this ethereal cluster that always exists. And so, that sort of combination of platform as a service, function as a service, Kubernetes, as that evolves, I think there are a lot of exciting things that have yet to come in the Kubernetes space. KENDALL: Well, so say more about that, Joe, because I've been going to KubeCon for a very long time, maybe...I don't know if it's 2016 or so when I first went. And it felt for a number of years...maybe those first four-ish years it was always the people at KubeCon were the, like, big dreamers and thinkers and, like, we're here to change the future of cloud infrastructure. And this is going places, and we're excited to be here and be a part of it. And here's what I'm going to do that changes the next thing. And I feel like now if I go to KubeCon, it's a lot of people from, you know, IBM and some big bank that are, like, deep sigh, well, I have to adopt Kubernetes. I need to know what the vendors are. What do you guys do, and how does this work? Can you please teach it to me? Because I'm being told by my boss, I have to do it. I don't see that excitement around Kubernetes anymore. The excitement I see is all around further up the stack, you know, things like Wasm, WebAssembly, or eBPF, the networking things and tracing things that are possible. Maybe that's further down the stack. I guess it depends on how you think about it, but different part of the stack. So, I'm curious, touching on the serverless components of Kubernetes; sure, I get that. And I do think, increasingly, the PaaSs of the future are all going to be Kubernetes-based, whether that's exposed or not. But where are the places that you think it's still going to go? Because I feel like it's already gotten boring, maybe in a positive way. But I don't see the excitement around it like I saw a few years back. And I'm curious what else you think is going to happen. JOE: Yeah, I mean, I don't think I disagree. I think Kubernetes itself, the core concept, is, like, it's still changing. But you're right that the excitement about Kubernetes existing has gone down because it's been there for a while. But I feel like the ecosystem is still growing pretty rapidly. Like, the things you mentioned, like Wasm and Istio, and all the tools in that ecosystem that continue to grow, is where I think the interesting things will happen. Like, it's created this new lower-level layer of abstraction that makes it possible to build concepts and technology that could not have existed before. KENDALL: Yeah, well, and I'm, you know, talking to people who are working really hard at making short-run ephemeral workloads work better on things like GPUs for the sake of AI, right? Like, I mean, there is some really interesting things happening, and people are doing this in Kubernetes. So, I get that. I agree with that. It is interesting that Kubernetes has become sort of the stable thing, and now it's about who can build the interesting add-ons. It's almost like, okay, we've built Half-Life. What is Counter-Strike going to look like? You know. That's a terrible (I'm aging myself.) example. But still. VICTORIA: I think it's interesting, I mean, to look at the size of the market for platform engineering right now. In 2022, was 4.8 billion, and it's estimated to be in 10 years $41 billion. So, there is this emerging trend of different platform engineering products, different abstractions on top of Kubernetes. And I wonder what advice you would have for a technical founder who's looking to build and solve some of these interesting issues in Kubernetes and create a business around it. KENDALL: Well, okay, let me clarify that question. Are you thinking, I'm a startup, and I need to build my infrastructure, and I'm going to choose Kubernetes. What advice do I need? Or are you thinking, I am founder, and I want to go build on the Kubernetes ecosystem. What advice do you have? VICTORIA: Now I want to know the answer to both. But my question was the second one to start. KENDALL: One of the things that is hard about the Kubernetes ecosystem is there's not a ton of companies that have made a whole bunch of money in Kubernetes because, as I said, I still think we're actually really early in the adoption curve. The kinds of companies that have adopted Kubernetes are the kinds of companies that don't spend lots and lots of money on an infrastructure. [laughs] They're the kinds of companies that are fast-moving, early adopters, or, you know, those first followers, and so they're under $100 million companies for the most part. Where the JP Morgans and Chase are running Kubernetes somewhere in their stack, but they haven't adopted it across the stack to need the biggest, best tools about it. So, the first piece of advice that I'd give is, be a little wary. It's still very early to the market. Maybe now is the time to build the thing. When ReactiveOps pivoted to Kubernetes, I think it was six months of having conversations with companies who were just, like, so excited about it, and this is definitely what we want to do. But nobody was doing it yet. You know, it was, we have, like, six solid months of just excitement and nobody actually pulling the trigger. And, you know, we were a little too early to that market. And that was just the people adopting it. So, I think there is some nervousness that cloud-native solutions the only people who are really making money in Kubernetes are named Amazon, Google, and Microsoft because it's the cloud providers that are making a ton off of it. Now, there's Rancher. There is StackPointCloud. There's a few others that have had big exits in this space. But I don't think it's actually as big of a booming economy as a lot of people think, in part because EKS is an incredibly amazing product. Like, eight years ago, the thing people paid us the most to do at ReactiveOps was just stand up Kubernetes because it was so stinking hard to just get it up and working. And now you click some buttons. Anybody can go do that. So, it's changed a lot, right? And I think be wary when you're entering that ecosystem. And then, my advice to the founder that's not building on the ecosystem but just looking to adopt a technology that's going to be a future-proofed infrastructure is just adopt one of the cloud-native platforms. And there are a whole bunch of sort of default best-in-class add-ons out there that you need to throw in. Don't adopt too many because then you have to maintain them forever. That's the easiest way to get started. You can figure out all the rest of it later. But if you go use EKS, or GKE, AKS, you can get started pretty easily and build something that is going to be future-proofed. I don't know, Joe; I'm curious if you disagree with any of that. JOE: Well, I think it's interesting to think about who's making money in Kubernetes. Like, I think there might not be as many companies who are doing only Kubernetes and Kubernetes-focused products that are massively successful. But I think because it has had a good amount of adoption and because it's easier to work with something that's standardized, it has helped companies sell things that they wanted to sell anyway. Like, all the Datadog, all the Scalas, the logging companies, they all have Kubernetes add-ons. And now everybody is paying Datadog [laughs] to have a dashboard for their Kubernetes cluster. I think they're making more money than they would have been without targeting the market. And so, I think that's really...if you want to get into the market, it's not, like, I'm going to build a Kubernetes product. It's if I'm building operations and an infrastructure product, I should definitely have it work with Kubernetes, and people will want to click and install it. KENDALL: So, to be clear, you know, one of the companies that I work with is called Axiom, and they play in the same, you know, monitoring, observability space as Datadog does. And part of what makes Kubernetes interesting in that space is in a microservice environment; there's so much happening. Where are problems being caused? We don't live in a day where I can just run my code, and it tells me that there's an unexpected semicolon on line 23, right? Like, that still happens. You're still doing those things. But this microservice talking to that microservice is where things tend to break down. Did I communicate this correctly? What was sent? What was received? Where did it break down? What was the latency? And if you were doing things in the old way back when you were standing it up with, say, Ansible, or Puppet, or something like that, and you were orchestrating all of these cloud virtual machines, you had to really work hard to instrument the tracing and logging and everything involved in order to track what was going on. Whereas that's one of the magic things about Kubernetes is with a few of the add-ons or some of the things out of the box with Kubernetes, it's a couple of clicks to get so, so much of the data and have insight into where things are going and what's going wrong. And so, I 100% agree with that. Kubernetes is generating a tremendous amount of data. And if you're a data company, it's really nice to have all that come in, and it helps them make money, helps the user of Kubernetes in that situation understand where problems are happening and breaking down. Yeah, there's definitely some network effects of what Kubernetes is doing in that. I completely agree. JOE: I think there are also some interesting companies, like, where they make...Emissary, Ambassador, and they have that sort of dual -- KENDALL: Komodor, is that -- JOE: Yeah, maybe. They have open source, but then they have a product. KENDALL: You're thinking of Ambassador Labs. JOE: Yeah. Ambassador Labs, yeah. I guess I don't really know how much money they're making. But I think that's a really interesting concept as people who make open-source things then make a well-supported product built around it. KENDALL: Sure. What's interesting is, I think in the VC world, at least right now, and it may pick up again, but post-Silicon Valley Bank nearly caving in, I think that the VC tolerance for, yeah, just go get a billion open-source adopters, and we'll figure out how to monetize later I think that the tolerance for that is a lot lower than it was even six months ago. JOE: Yeah, I think you have to have a dual model right from the beginning now. KENDALL: Yeah. Agreed. VICTORIA: You got to figure out how to make money on Kubernetes before you can. [laughs] KENDALL: You know, minor detail. That's why I think services companies in this space still have a lot going for it. Because in order to even be able to sell software to a company using Kubernetes, you half the time have to go stand up Kubernetes for them because it is still that hard for so many people to really adopt it. VICTORIA: Yeah. And maybe, like, talking more about, like, when it is the right decision to start on Kubernetes because I think the question I get sometimes is just, is it overkill? Is it too much for what we're building? Especially, like, if you're building a brand-new product, you're not even sure if it's going to get adopted that widely. KENDALL: I mean, and I'm [laughs] curious your thought on this, Joe, but there's a good argument to be made that Heroku was enough for the vast majority of founders early on. But the thing is, Kubernetes isn't as hard as it used to be. Going and clicking a couple of buttons on GKE and deploying something into Kubernetes with GKE Autopilot running it's not as easy as Heroku, but it's not wildly far off. And it does substantially future-proof you. So, when is it too early? I'm not sure it's ever too early if you have an intention of scaling if you're planning on running some kind of legacy workload, like, things that are going to be stateful. Or maybe WordPress, for example, you don't probably need to deploy your WordPress blog onto Kubernetes. You can do that in your cPanel on Bluehost. I don't actually know if Bluehost even exists anymore, but I assume it's still a thing. I don't know, what would you say, Joe? JOE: I agree with that. I think it's a hard first pill to swallow. But I think the reality is that it's very easy to underestimate the infrastructure needs of even an early product. Like, it doesn't really matter what you're building. You're still going to have things like secrets management. You're still going to have to worry about networking. They just don't go away. There's no way you have a product without them. And so, rather than slowly solving all those problems from scratch on a platform that isn't designed for it, I think it's easier to just bite the bullet and use one of the managed solutions, especially, as you said, I think it's getting easier and easier. The activation energy from going from credit card to Kubernetes cluster is just getting lower. KENDALL: And so, the role of the CTO is just getting easier and easier because they can just adopt the one technology, and it's obviously Kubernetes. And it's obviously Rust, right? [laughter] Yeah, no, I'm with you. And I think if you find somebody who knows Kubernetes inside and out, it's really not going to take them long to get started. VICTORIA: Yeah, once again, change management is the biggest challenge for any new innovation coming into adoption. So, I'm curious to talk more about the influence that you need and how you influence others to come around to these types of ideas, like, in the executive suite and with the leadership of a company, especially on these types of topics, which can feel maybe a little abstract for people. KENDALL: How you influence them specifically to use Kubernetes, or just how you talk with them about technology adoption in general? Or what are you asking? VICTORIA: Yeah, like, how do I get people to not just turn their ears off when I say the word Kubernetes? [laughs] KENDALL: Yeah, I mean, I think...so I think that's where it's the technologist's job and the role of the CTO to translate these things into business speak. And that's why I'm using words like future-proofing your infrastructure is because there are companies that...I know one company that made a conscious decision that they were going to try to re-platform every single year, and that is not a good idea or sustainable for the vast majority [laughs] of companies. In fact, I can't think of a single situation where that makes sense. But if you can say to the CFO, "Hey, it's going to cost us a little bit more right now. It's going to save us substantially in the long term because this is the thing that's winning. And if we go standardize on Heroku right now, every company does eventually have to migrate off of Heroku. They either go out of business, or they get too big for it." That's the kind of thing that needs to be communicated in order to get people to adopt it. They don't care what the word is. They don't care if you're saying Kubernetes; you know, most CFOs understand it about as well as my mom does. My mom tries to bring it up in conversation because she's heard me use it. And she thinks it makes her sound smart, which maybe it does in the right climate. VICTORIA: My partner does the same thing. He says DevOps and Kubernetes all the time. I'm like; you don't know what you're talking about. [laughter] JOE: Those words do not come up in my house. KENDALL: One of my kids asked me to explain Kubernetes. And I do a whole talk, particularly at organizations where understanding Kubernetes is essential to the salespeople's role. And I give a whole talk about the background of how we got here from deploying on some servers in our back room. And, you know, what's different about the cloud, what containerization did, et cetera. And I have this long explanation. And I remember taking a deep breath and saying to my kids, "Do you really want to hear this?" And I had one son say, "Yes, absolutely." And my wife and three of the other kids all stood up and said, "No way," and left the room. So, when somebody asks me, "What do you do?" Actually, one of the key relationships I built with some of the early people at GCP when we were partnering closely with them was a person that I met, and I asked, "What do you do for a living?" And he said, "I can tell you, but it's not going to mean anything to you." And I was like, "That's what I say to people." And it turned out he was in charge of, you know, Kubernetes partnerships for Google. I can explain to you what it means and why it's important. But you're not going to be happy that I spent that time explaining it to you. VICTORIA: [laughs] That sounds awesome, though. It sounds like you built a server rack just to demo to your children what it was. KENDALL: No, no. I just talked back through the history of...that company that I mentioned that built Twitter about five years too early; we had a, you know, we had a server rack in the...literally physically in our closet that was serving up our product at the time. VICTORIA: Probably the best demo I ever saw was at Google headquarters in Herndon, and someone had built...They had 3D-printed a little mini server rack that they had put Raspberry Pis onto, and then they had Kubernetes deployed on it. And they did an automatic failover of a node to just demo how it works and had little lights that went with it. It was pretty fun. So maybe you should get one for yourself. [laughter] It's a fun project. KENDALL: They remember the things that it enables. They don't remember what it does. And so, when I say so, and so is a client that's using this technology, then they get real excited because they're like, "My dad makes that work." And I'm like, well, okay, that's kind of a stretch, but you get the idea. VICTORIA: Yeah, you got to lean into that kind of reputation in your house. KENDALL: That's right. VICTORIA: And you're like, yes, that's correct. KENDALL: That's right. [laughs] VICTORIA: I do make Kubernetes. I make all the clouds work, yeah. KENDALL: Actually, my most common explanation is Kubernetes is the plumbing of the internet. Unless you're a plumber, you don't care about the pipes. You just want your shit to flush when you use the toilet. You want the things to load when you click your buttons. You don't actually care what's going on behind the scenes, but this is what's orchestrating it increasingly across the internet. VICTORIA: So far, we've called Kubernetes WordPress or the toilet. [laughs] KENDALL: The plumbing. [laughter] VICTORIA: You are really good at selling it. [laughter] KENDALL: Hey, if you want to build a nice, clean city, you need good plumbing. You might not care what the pipes are made of, but you need good plumbing. [laughs] VICTORIA: Works for me. On that note -- [laughs] KENDALL: Yeah. Right? Right? VICTORIA: That's [inaudible 36:41] on a high note. Is there anything else that you'd like to promote? KENDALL: With regards to CTO Lunches, we have a free listserv. There are local lunches. If there isn't a local lunch where you are, it's very lightweight to start up a chapter. We often have folks who are willing to sponsor that first lunch to get you going. We do have a paid tier of CTO Lunches. If you want a small back room Slack channel of people to discuss, I think it's $99 a month. Yeah, if you're a CTO and/or a senior engineering leader and you want a community of people to process with, be it our free tier or our paid tier, we've got something for you. We're trying to invest in this to build community around it. And it's something we enjoy doing more than almost anything. Come take part. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Kendall Miller.
Esse episódio do Kubicast traz uma conversa “muito fixe” com Ricardo Castro, o mago do CI/CD, que nos fala diretamente de Portugal, e também é Principal Engineer (SRE) na FanDuel e CDF Ambassador na CNCF.CI/CD é uma filosofia e não um conjunto de ferramentas. É possível fazer CI/CD de uma maneira certa com Jenkins e errada com Argo CD. Também, fazer CI/CD sem automação não é escalável, mas é possível.Falar de CI/CD parece um tema antigo, mas vale a pena conferir o papo, porque talvez o seu GitHub Actions não seja tudo o que o seu CI/CD poderia ou deveria fazer por você!Link do episódio:Kubicast #121 - Platform Engineering com a Natura https://www.getup.io/blog/kubicast-121-platform-engineering-na-real-com-natura/Recomendações do programa:A melhor forma de quebrar silos entre equipes é se comunicar! Queira saber o que fazem as outras pessoas da sua empresaSeja empático!Faça reuniões abertas e informais para participação de quem se interessarTenha interesse pelo negócio e não apenas pela parte técnica!O Kubicast é uma produção da Getup, empresa especialista em Kubernetes e projetos open source para Kubernetes. Os episódios do podcast estão em getup.io/kubicast, nas principais plataformas de áudio digital e no YouTube.com/@getupcloud.
No episódio #128 do Kubicast, conversamos com Flávio Pimenta, Solutions Architect na Sensidea e palestrante dedicado à comunidade Cloud Native. O convidado compartilha sua incrível trajetória com a comunidade DevOps e enfatiza a importância dos feedbacks da comunidade para seu crescimento e aprimoramento. Flávio também se tornou um pilar na comunidade AWS, sendo reconhecido como referência na área. Não perca esse episódio inspirador para os interessados em Cloud Native e DevOps.
Nate Avery, Outbound Product Manager at Google, joins Corey on Screaming in the Cloud to discuss what it's like working in the world of tech, including the implications of AI technology on the workforce and the importance of doing what you love. Nate explains why he feels human ingenuity is so important in the age of AI, as well as why he feels AI will make humans better at the things they do. Nate and Corey also discuss the changing landscape of tech and development jobs, and why it's important to help others throughout your career while doing something you love. About NateNate is an Outbound Product Manager at Google Cloud focused on our DevOps tools. Prior to this, Nate has 20 years of experience designing, planning, and implementing complex systems integrating custom-built and COTS applications. Throughout his career, he has managed diverse teams dedicated to meeting customer goals. With a background as a manager, engineer, Sys Admin, and DBA, Nate is currently working on ways to better build and use virtualized computer resources in both internal and external cloud environments. Nate was also named a Cisco Champion for Datacenter in 2015.Links Referenced: Google Cloud: https://cloud.google.com/devops Not Your Dad's IT: http://www.notyourdadsit.com/ Twitter: https://twitter.com/nathaniel_avery LinkedIn: https://www.linkedin.com/in/nathaniel-avery-2a43574/ 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: It's easy to **BEEP** up on AWS. Especially when you're managing your cloud environment on your own!Mission Cloud un **BEEP**s your apps and servers. Whatever you need in AWS, we can do it. Head to missioncloud.com for the AWS expertise you need. Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn, and my guest today is Nate Avery, who's an outbound product manager over at Google Cloud. Nate, thank you for joining me.Nate: Thank you for having me. This is really a pretty high honor. I'm super thrilled to be here.Corey: One of my questions that I have about any large company when I start talking to them and getting to know people who work over there, pretty quickly emerges, which is, “What's the deal with your job title?” And it really doesn't matter what the person does, what the company is, there's always this strange nuance that tends to wind up creeping into the company. What is an outbound product manager and what is it you say it is you do here?Nate: Okay. That's an interesting question because I've been here for about a year now and I think I'm finally starting to figure it out. Sure, I should have known more when I applied for the job, [laugh] but there's what's on the paper and then there's what you do in reality. And so, what it appears to be, where I'm taking this thing now, is I talk to folks about our products and I try to figure out what it is they like, what it is they don't like, and then how do we make it better? I take that information back to our engineers, we huddle up, and we figure out what we can do, how to do it better, how to set the appropriate targets when it comes to our roadmaps. We look at others in the industry, where we are, where they are, where we think we can maybe have an advantage, and then we try to make it happen. That's really what it is.Corey: One of the strange things that happens at big companies, at least from my perspective, given that I've spent most of my career in small ones, is that everyone has a niche. There are very few people at large companies whose job description is yeah, I basically do everything. Where do you start? And where do you stop because Google Cloud, even bounding it to that business unit, is kind of enormous? You've [got 00:02:47] products that are outbound that you manage. And I feel like I should also call out that a product being outbound is not the same thing as being outgoing. I know that people are always wondering, what's Google going to turn off next, but Google Cloud mostly does the right thing in that respect. Good work.Nate: [laugh]. Nice. So, the products I focus on are the DevOps products. So, those are Cloud Build, Cloud Deploy, Artifact Registry, Artifact Analysis. I also work with some of our other dev tooling such as Cloud Workstations. That's in public preview right now, but maybe by the time this goes to air, it'll actually be in general availability.And then I also will talk about some of our other lesser-known tools like Skaffold or maybe on occasion, I'll throw out something about minikube. And also, Cloud Code, which is a really deep browser plugin for your IDE that gives you access to lots of different Google tools. So yeah, that's sort of my area.Corey: Well, I'm going to start with the last thing you mentioned, where you have Cloud Code as an IDE tooling and a plug-in for it. I'm relatively new to the world of IDEs because I come from the world of grumpy Unix admins; you never know what you're going to be remoting into next, but it's got VI on it, so worst case, you'll have that. So, I grew up using that, and as a result, that is still my default. I've been drifting toward VS Code a fair bit lately, as I've been regrettably learning JavaScript and TypeScript, just because having a lot of those niceties is great. But what's really transformative for me has been a lot of the generative AI offerings from various companies around hey, how about we just basically tab-complete your code for you, which is astonishing. I know people love to argue about that and then they go right back to their old approach of copying and pasting their code off a Stack Overflow.Nate: Yeah. That's an interesting one. When it works, it works and it's magical. And those are those experiences where you say, “I'm going to do this thing forever and ever I'm never going to go back.” And then when it doesn't work, you find yourself going back and then you maybe say, “Well, heck, that was horrible. Why'd I ever even go down this path?”I will say everyone's working on something along those lines. I don't think that that's much of a secret. And there are just so many different avenues at getting there. And I think that this is so early in the game that where we are today isn't where we're going to be.Corey: Oh, just—it's accelerating. Watching the innovation right now in the generative AI space is incredible. My light bulb moment that finally got me to start paying attention to this and viewing it as something other than hype that people are trying to sell us on conference stages was when I use one of them to spit out just, from a comment in VS Code, “Write a Python script that will connect to AWS pricing API and tell me what something costs, sorted from most to least expensive regions.” Because doing that manually would have taken a couple hours because their data structures are a sad joke and that API is garbage. And it sat and spun for a second and then it did it. But if I tell that story as, “This is the transformative moment that opened my eyes,” I sound incredibly sad and pathetic.Nate: No, I don't think so. I think that what it does, is it… one, it will open up more eyes, but the other thing that it does is you have to take that to the next level, which is great. That's great work, gone. Now that I have this information, what do I do with it? That's really where we need to be going and where we need to think about what this AI revolution is going to allow us to do, and that's to actually put this stuff into context.That's what humans do, which the computers are not always great at. And so, for instance, I see a lot of posts online about, “Hey, you know, I used to do job X, where I wrote up all these things,” or, “I used to write a blog and now because of AI, my boss wants me to write, you know, five times the output.” And I'm thinking, “Well, maybe the thing that you're writing doesn't need to be written if it can be easily queried and generated on the fly.” You know? Maybe those blog posts just don't have that much value anymore. So, what is it that we really should concentrate on in order to help us do better stuff, to have a higher order of importance in the world? That's where I think a lot of this really will wind up going is… you know, just as people, we've got to be better. And this will help us get there.Corey: One area of nuance on this, though, is—you're right when I talked about this with some of my developer friends, some of their responses were basically to become immediately defensive. Like, “Sure, it's great for the easy stuff, but it's not going to solve the high-level stuff that senior engineers are good at.” And I get that. This ridiculous thing that I had to do is not a threat to a senior engineer, but it is arguably a threat to someone I find on Upwork or Fiverr or whatnot to go and write this simple script for me.Nate: Oh yeah.Corey: Now, the concern that I have is one of approachability and accessibility because. Senior engineers don't form fully created from the forehead of some God somewhere that emerges from Google. They start off as simply people who have no idea what they're doing and have a burning curiosity about something, in many cases. Where is the next generation going to get the experience of writing a lot of that the small-scale stuff, if it's done for them? And I know that sounds alarmist, and oh, no, the sky is falling, and are the children going to be all right, as most people my age start to get into. But I do wonder what the future holds.Nate: That's legit. That's a totally legit question because it's always kind of hanging out there. I look at what my kids have access to today. They have freaking Oracle, the Oracle at Delphi on their phone; you know, and—Corey: If Oracle the database on their phone, I would hate to imagine what the cost of raising your kids to adulthood would be.Nate: Oh, it's mighty, mighty high [laugh]. But no, they have all of this stuff at their hands and then even just in the air, right? There's ambient computing, there's any question you want answered, you could speak it into the air and it'll come out. And it'll be, let's just say, I don't know, at least 85% accurate. But my kids still ask me [laugh].Corey: Having my kids, who are relatively young, still argue and exhaust their patience on a robot with infinite patience instead of me who has no patience? Transformative. “How do I spell whatever it is?” “Ask Alexa,” becomes a story instead of, “Look it up in the dictionary,” like my parents used to tell me. It's, “If I knew how to spell it, I would need to look it up in the dictionary, but I don't, so I can't.”Nate: Right. And I would never need to spell it again because I have the AI write my whole thing for me.Corey: That is a bit of concern for me when—some of the high school teachers are freaking out about students are writing essays with this thing. And, yeah, on the one hand, I absolutely see this as alarmism, where, oh, no, I'm going to have to do my job, on some level. But the reason you write so many of those boring, pointless essays in English class over the course of the K through 12 experience is ideally, it's teaching you how to frame your discussions, how to frame an argument, how to tell a compelling story. And, frankly, I think that's something that a lot of folks in the engineering cycle struggle with mightily. You're a product slash program manager at this point; I sort of assume that I don't need to explain to you that engineers are sometimes really bad at explaining what they mean.Nate: Yeah. Dude, I came up in tech. I'm… bad at it too sometimes [laugh]. Or when I think I'm doing a great job and then I look over and I see a… you know, the little blanky, blanky face, it goes, “Oh. Oh, hold on. I'll recalibrate that for you.” It's a thing.Corey: It's such a bad trope that they have now decided that they are calling describing what you actually mean slash want is now an entire field called prompt engineering.Nate: Dude, I hate that. I don't understand how this is going to be a job. It seems to be the most ridiculous thing in the world. If you say, “I sit down for six hours a day and I ask my computer questions,” I got to ask, “Well, why?” [laugh]. You know? And really, that's the thing. It gets back—Corey: Well, most of us do that all day long. It's just in Microsoft Excel or they use SQL to do it.Nate: Yeah… it is, but you don't spend your day asking the question of your computer, “Why.” Or really, most of us ask the question, “How?” That's really what it is we're doing.Corey: Yeah. And that is where I think it's going to start being problematic for some folks who are like, “Well, what is the point of writing blog posts if Chat-GIPITY can do it?” And yes, that's how I pronounce it: Chat-GIPITY. And the response is, “Look, if you're just going to rehash the documentation, you're right. There's no point in doing it.”Don't tell me how to do something. Tell me why. Tell me when I should consider using this tool, that tool, why this is interesting to me, why it exists. Because the how, one way or another, there are a myriad ways to find out the answer to something, but you've got to care first and convincing people to care is something computers still have not figured out.Nate: Bingo. And that gets back to your question about the engineers, right? Yeah. Okay. So sure, the little low-level tasks of, “Hey I need you to write this API.” All right, so maybe that stuff does get farmed out.However, the overall architecture still has to be considered by someone, someone still has to figure out where and how, and when things should be placed and the order in which these things should be connected. That never really goes away. And then there's also the act of creation. And by creation, I mean, just new ideas, things that—you know, that stroke of creativity and brilliance where you just say, “Man, I think there's a better way to do this thing.” Until I see that from one of these generative AI products, I don't know if anyone should truly feel threatened.Corey: I would argue that people shouldn't necessarily feel threatened regardless because things always change; that's the nature of it. I saw a headline on Hacker News recently where it said that 90% of my skills are worthless, but 10% of them are 10x what they were was worth. And I think that there's a lot of truth to that because it's, if you want a job where you never have to—you don't have to keep up with the continuing field, there are options. Not to besmirch them, but accountants are a terrific example of this. Yes, there's change to accountancy rules, but it happens slowly and methodically. You don't go on vacation for two years as an accountant—or a sabbatical—come back and discover that everything's different and math doesn't work the way it once did. Computers on the other hand, it really does feel like it's keep up or you never will.Nate: Unless you're a COBOL guy and you get called back for y2k.Corey: Oh, of course. And I'm sure—and now you're sitting around, you're waiting because when the epic time problem hits in 2038, you're going to get your next call out. And until then, it's kind of a sad life. You're the Maytag repair person.Nate: Yeah. I'm bad at humor, by the way, in case you have noticed. So, you touched on something there about the rate of change and how things change and whether or not these generative AI models are going to be able to—you know, just how far can they go? And I think that there's a—something happened over the last week or so that really got me thinking about this. There was a posting of a fake AI-generated song, I think from Drake.And say what you want about cultural appropriation, all that sort of thing, and how horrible that is, what struck me was the idea that these sorts of endeavors can only go so far because in any genre where there's language, and current language that morphs and changes and has subtlety to it, the generative AI would have to somehow be able to mimic that. And not to say that it could never get there, but again, I see us having some situations where folks are worried about a lot of things that they don't need to worry about, you know, just at this moment.Corey: I'm curious to figure out what your take is on how you see the larger industry because for a long time—and yes, it's starting to fade on some level, because it's not 2006 anymore, but there was a lot of hero worship going on with respect to Google, in particular. It was the mythical city on the hill where all the smart people went and people's entire college education was centered around the idea of, well, I'm going to get a job at Google when I graduate or I'm doomed. And it never seems to work out that way. I feel like there's a much more broad awareness these days that there's no one magical company that has the answers and there are a lot of different paths. But if you're giving guidance to someone who's starting down that path today, what would it be?Nate: Do what you love. Find something that you love, figure out who does the thing that you love, and go there. Or go to a place that does a thing that you love poorly. Go there. See if you can make a difference. But either way, you're working on something that you like to do.And really, in this business, if you can't get in the door at one of those places, then you can make your own door. It's becoming easier and easier to just sort of shoehorn yourself into this space. And a lot of it, yeah, there's got to be talent, yeah, you got to believe in yourself, all that sort of thing, but the barriers to entry are really low right now. It's super easy to start up a website, it costs you nothing to have a GitHub account. I really find it surprising when I talked to my younger cousins or someone else in that age range and they start asking, like, “Well, hey, how do I get into business?”And I'm like, “Well, what's your portfolio?” You know? And I ask them, “Do you want to work for someone else? Or would you like to at least try working for yourself first?” There are so many different avenues open to folks that you're right, you don't have to go to company X or you will never be anything anymore. That said, I am at [laugh] one of the bigger companies and do there are some brilliant people here. I bump into them and it's kind of wild. It really, really is.Corey: Oh, I want to be very clear, despite the shade that I throw at Google—and contemporary peers in the big tech company space—there are an awful lot of people who are freaking brilliant. And more importantly, by far, a lot of people who are extraordinarily kind.Nate: Yeah. Yeah. So, all right, in this business, there's that whole trope about, “Yeah, they're super smart, but they're such jerks.” It doesn't have to be that way. It really doesn't. And it's neat when you run into a place that has thousands of people who do not fit that horrible stereotype out there of the geek who can't, you know, who can't get along well with others. It's kind of nice.But I also think that that's because the industry itself is opening up. I go on to Twitter now and I see so many new faces and I see folks coming in, you know, for whatever reason, they're attracted to it for reasons, but they're in. And that's the really neat part of it. I used to worry that I didn't see a lot of young people being interested in this space. But I'm starting to notice it now and I think that we're going to wind up being in good hands.Corey: The kids are all right, I think, is a good way of framing it. What made you decide to go to Google? Again, you said you've been there about a year at this point. And, on some level, there's always a sense in hindsight of, well, yeah, obviously someone went from this job to that job to that job. There's a narrative here and it makes sense, but I've never once in my life found that it made sense and was clear while you're making the decision. It feels like it only becomes clear in hindsight.Nate: Yes, I am an extremely lucky person. I am super fortunate, and I will tell a lot of people, sometimes I have the ability to fall ass-backwards into success. And in this case, I am here because I was asked. I was asked and I didn't really think that I was the Google type because, I don't know what I thought the Google type was, just, you know, not me.And yet, I… talked it out with some folks, a really good, good buddy of mine and [laugh] I'll be darned, you know, next thing, you know, I'm here. So, gosh, what can I say except, don't limit yourself [laugh]. We do have a tendency to do that and oh, my God, it's great to have a champion and what I'd like to do now, now that you mention it and it's been something that I had on my mind for a bit is, I've got to figure out how to, you know how to start, you know, giving back, paying it forward, whatever the phrase it is you want to use? Because—Corey: I like, “Send the elevator back down.”Nate: Send the elevator back down? There you go, right? If that escalator stopped, turn it back on.Corey: Yeah, escalator; temporarily, stairs.Nate: Yes. You know, there are tons of ways up. But you know, if you can help someone, just go ahead and do it. You'd be surprised what a little bit of kindness can do.Corey: Well, let's tie this back to your day job for a bit, on some level. You're working on, effectively, developer tools. Who's the developer?Nate: Who's the developer? So, there's a general sense in the industry that anyone who works in IT or anyone who writes code is a developer. Sometimes there's the very blanket statement out there. I tend to take the view that a developer is the person who writes the code. That is a developer, that's [unintelligible 00:21:52] their job title. That's the thing that they do.The folks who assist developers, the folks who keep the servers up and running, they're going to have a lot of different names. They're DevOps admins, they're platform admins, they're server admins. Whatever they are, rarely would I call them developers, necessarily. So, I get it. We try to make blanket statement, we try to talk to large groups at a time, but you wouldn't go into your local county hospital and say that, “I want to talk to the dentist,” when you really mean, like, a heart surgeon.So, let's not do that, you know? We're known for our level of specificity when we discuss things in this field, so let's try to be a little more specific when we talk about the folks who do what they do. Because I came up on that ops track and I know the type of effort that I put in, and I looked at folks across from me and I know the kind of hours that they put in, I know all of the blood sweat and tears and nightless sleeps and answering the pagers at four in the morning. So, let's just call them what they are, [laugh] right? And it's not to say that calling them a developer is an insult in any way, but it's not a flex either.Corey: You do work at a large cloud company, so I have to assume that this is a revelation for you, but did you know that words actually mean things? I know, it's true. You wouldn't know it from a lot of the product names that wind up getting scattered throughout the world. The trophy for the worst one ever though, is Azure DevOps because someone I was talking to as a hiring manager once thought that they listed that is a thing they did on their resume and was about to can the resume. It's, “Wow, when your product name is so bad that it impacts other people's careers, that's kind of impressively awful.”But I have found that back when the DevOps movement was getting started, I felt a little offput because I was an operations person; I was a systems administrator. And suddenly, people were asking me about being a developer and what it's like. And honestly, on some level, I felt like an imposter, just because I write configuration files; I don't write code. That's very different. Code is something smart people write and I'm bad at doing that stuff.And in the fullness of time, I'm still bad at it, but at least now unenthusiastically bad at it. And, on some level, brute force also becomes a viable path forward. But it felt like it was gatekeeping, on some level, and I've always felt like the terms people use to describe what I did weren't aimed at me. I just was sort of against the edge.Nate: Yeah. And it's a weird thing that happens around here, how we get to these points, or… or somehow there's an article that gets written and then all of a sudden, everyone's life is changed in an industry. You go from your job being, “Hey, can you rack and stack the server?” To, “Hey, I need you to write this YAML code that's going to virtually instantiate a server and also connect it to a load balancer, and we need these done globally.” It's a really weird transition that happens in life.But like you said, that's part of our job: it morphs, it changes, it grows. And that's the fun of it. We hope that these changes are actually for the better and then they're going to make us more productive and they're going to make our businesses thrive and do things that they couldn't be before, like maybe be more resilient. You know, you look at the number of customers—customers; I think of them as customers—who had issues because of that horrible day in 9/11 and, you know, their business goes down the tube because there wasn't an adequate DR or COOP strategy, you know? And I know, I'm going way back in the wayback, but it's real. And I knew people who were affected by it.Corey: It is. And the tide is rising. This gets back to what we were talking about where the things that got you here won't necessarily get you there. And Cloud is a huge part of that. These days, I don't need to think about load balancers, in many cases, or all of the other infrastructure pieces because Google Cloud—among other companies, as well, lots of them—have moved significantly up the stack.I mean, people are excited about Kubernetes in a whole bunch of ways, but what an awful lot of enterprises are super excited about is suddenly, a hard drive failure doesn't mean their application goes down.Nate: [Isn't that 00:26:24] kind of awesome?Corey: Like, that's a transformative moment for them.Nate: It totally is. You know, I get here and I look at the things that people are doing and I kind of go, “Wow,” right? I'm in awe. And to be able to contribute to that in some way by saying, “Hey, you know what, we'll be cool? How about we try this feature?” Is really weird, [laugh] right?It's like, “Wow, they listened to me.” But we think about what it is we're trying to do and a lot of it, strangely enough, is not just helping people, but helping people by getting out of the way. And that is huge, right? You know, because you just want it to work, but more than it just working, you want it to be seamless. What's easier than putting your key in the ignition and turning it? Well, not having to use a key at all.So, what are those types of changes that we can bring to these different types of experiences that folks have? If you want to get your application onto a Kubernetes cluster, it shouldn't be some Herculean feat.Corey: And running that application responsibly should not require a team of people, each making a quarter million bucks a year, just to be able to do it safely and responsibly. There's going to be a collapsing down of what you have to know in order to run these things. I mean, web servers used to be something that required a month of your life and a fair bit of attention to run. Now, it's a checkbox in a cloud console.Nate: Yeah. And that's what we're trying to get it to, right? Why isn't everything a checkbox? Why can't you say, “Look, I wrote my app. I did the hard part.” Let's—you know, I just need to see it go somewhere. You know? Make it go and make it stay up. And how can I do that?And also, here's a feature that we're working on. Came out recently and we want folks to try it. It's a cloud deploy feature that works for Cloud Run as well as it does for GKE. And it's… I know it's going to sound super simple: it's our canary deployment method. But it's not just canary deployment, but also we can tie it into parallel deployment.And so, you can have your new version of your app stood up alongside your old version of the app and we can roll it out incrementally in parallel around the world and you can have an actual test that says, “Hey, is this working? Is it not working?” If it does, great, let's go forward. If it doesn't, let's roll back. And some of the stuff sounds like common sense, but it's been difficult to pull off.And now we're trying to do it with just a few lines a YAML. So, you know, is it as simple as it could be? Well, we're still looking at that. But the features are in there and we're constantly looking at what we can do to iterate and figure out what the next thing is.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you?Nate: Best place for them to find me used to be my blog, it's Not Your Dad's IT, However, I've been pretty negligent there since doing this whole Google thing, so I would say, just look me up on Twitter at @nathaniel_avery, look me up on Google. You can go to a pretty cool search engine and [laugh]—Corey: Oh, that's right. You guys have a search engine now. Good work.Nate: That's what I hear [laugh].Corey: Someday maybe it'll even come to Google Docs.Nate: [laugh]. Yes, so yeah, that's where to find me. You know, just look me up at Nathaniel Avery. I think that handle works for almost everything, Twitter, LinkedIn, wherever, and reach out.If there's something you like about our DevOps tools, let me know. If there's something you hate about our DevOps tools, definitely let me know. Because the only reason we're doing this is to try and help people. And if we're not doing that, then we need to know. We need to know why it isn't working out.And trust me, I talk to these engineers every day. That's the thing that really keeps them moving in the morning is knowing that they're doing something to make things better for folks. Real quick, I'll close out, and I think I may have mentioned this on some other podcasts. I come from the ops world. I was that guy who had to help get a deployment out on a Friday night and it lasted all weekend long and you're staring there at your phone at some absurd time on a Sunday night and everyone's huddled together and you're trying to figure out, are we going to rollback or are we going to go forward? What are we going to do by Monday?Corey: I don't miss those days.Nate: Oh, oh God no. I don't miss those days either. But you know what I do want? I took this job because I don't want anyone else to have those days. That's really what it is. We want to make sure that these tools give folks the ability to deploy safely and to deploy with confidence and to take that level of risk out of the equation, so that folks can, you know, just get back to doing other things. You know, spend that time with your family, spend the time reading, spend that time prompting ChatGPT with questions, [laugh] whatever it is you want to do, but you shouldn't have to sit there and wonder, “Oh, my God, is my app working? And what do I do when it doesn't?”Corey: I really want to thank you for being as generous with your time and philosophy on this. Thanks again. I've really enjoyed our conversation.Nate: Thank you. Thank you. I've been a big fan of your work for years.Corey: [laugh]. Nate Avery, outbound product manager at Google Cloud. 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 hate this podcast, please leave a five-star review on your podcast platform of choice along with an angry, insulting comment that you had Chat-GIPITY write for you in YAML.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.
Everett Berry, Growth and Open Source at Vantage, joins Corey at Screaming in the Cloud to discuss the complex world of cloud costs. Everett describes how Vantage takes a broad approach to understanding and cutting cloud costs across a number of different providers, and reveals which providers he feels generate large costs quickly. Everett also explains some of his best practices for cutting costs on cloud providers, and explores what he feels the impact of AI will be on cloud providers. Corey and Everett also discuss the pros and cons of AWS savings plans, why AWS can't be counted out when it comes to AI, and why there seems to be such a delay in upgrading instances despite the cost savings. About EverettEverett is the maintainer of ec2instances.info at Vantage. He also writes about cloud infrastructure and analyzes cloud spend. Prior to Vantage Everett was a developer advocate at Arctype, a collaborative SQL client acquired by ClickHouse. Before that, Everett was cofounder and CTO of Perceive, a computer vision company. In his spare time he enjoys playing golf, reading sci-fi, and scrolling Twitter.Links Referenced: Vantage: https://www.vantage.sh/ Vantage Cloud Cost Report: https://www.vantage.sh/cloud-cost-report Everett Berry Twitter: https://twitter.com/retttx Vantage Twitter: https://twitter.com/JoinVantage 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: LANs of the late 90's and early 2000's were a magical place to learn about computers, hang out with your friends, and do cool stuff like share files, run websites & game servers, and occasionally bring the whole thing down with some ill-conceived software or network configuration. That's not how things are done anymore, but what if we could have a 90's style LAN experience along with the best parts of the 21st century internet? (Most of which are very hard to find these days.) Tailscale thinks we can, and I'm inclined to agree. With Tailscale I can use trusted identity providers like Google, or Okta, or GitHub to authenticate users, and automatically generate & rotate keys to authenticate devices I've added to my network. I can also share access to those devices with friends and teammates, or tag devices to give my team broader access. And that's the magic of it, your data is protected by the simple yet powerful social dynamics of small groups that you trust.Try now - it's free forever for personal use. I've been using it for almost two years personally, and am moderately annoyed that they haven't attempted to charge me for what's become an essential-to-my-workflow service.Corey: Have you listened to the new season of Traceroute yet? Traceroute is a tech podcast that peels back the layers of the stack to tell the real, human stories about how the inner workings of our digital world affect our lives in ways you may have never thought of before. Listen and follow Traceroute on your favorite platform, or learn more about Traceroute at origins.dev. My thanks to them for sponsoring this ridiculous podcast. Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This seems like an opportune moment to take a step back and look at the overall trend in cloud—specifically AWS—spending. And who better to do that than this week, my guest is Everett Berry who is growth in open-source over at Vantage. And they've just released the Vantage Cloud Cost Report for Q1 of 2023. Everett, thank you for joining me.Everett: Thanks for having me, Corey.Corey: I enjoy playing slap and tickle with AWS bills because I am broken in exactly that kind of way where this is the thing I'm going to do with my time and energy and career. It's rare to find people who are, I guess, similarly afflicted. So, it's great to wind up talking to you, first off.Everett: Yeah, great to be with you as well. Last Week in AWS and in particular, your Twitter account, are things that we follow religiously at Vantage.Corey: Uh-oh [laugh]. So, I want to be clear because I'm sure someone's thinking it out there, that, wait, Vantage does cloud cost optimization as a service? Isn't that what I do? Aren't we competitors? And the answer that I have to that is not by any definition that I've ever seen that was even halfway sensible.If SaaS could do the kind of bespoke consulting engagements that I do, we would not sell bespoke consulting engagements because it's easier to click button: receive software. And I also will point out that we tend to work once customers are at a certain point at scale that in many cases is a bit prohibitive for folks who are just now trying to understand what the heck's going on the first time finance has some very pointed questions about the AWS bill. That's how I see it from my perspective, anyway. Agree? Disagree?Everett: Yeah, I agree with that. I think the product solution, the system of record that companies need when they're dealing with Cloud costs ends up being a different service than the one that you guys provide. And I think actually the to work in concert very well, where you establish a cloud cost optimization practice, and then you keep it in place via software and via sort of the various reporting tools that the Vantage provide. So, I completely agree with you. In fact, in the hundreds of customers and deals that Vantage has worked on, I don't think we have ever come up against Duckbill Group. So, that tells you everything you need to know in that regard.Corey: Yeah. And what's interesting about this is that you have a different scale of visibility into the environment. We wind up dealing with a certain profile, or a couple of profiles, in our customer base. We work with dozens of companies a year; you work with hundreds. And that's bigger numbers, of course, but also in many cases at different segments of the industry.I also am somewhat fond of saying that Vantage is more focused on going broad in ways where we tend to focus on going exclusively deep. We do AWS; the end. You folks do a number of different cloud providers, you do Datadog cost visibility. I've lost track of all the different services that you wind up tracking costs for.Everett: Yeah, that's right. We just launched our 11th provider, which was OpenAI and for the first time in this report, we're actually breaking out data among the different clouds and we're comparing services across AWS, Google, and Azure. And I think it's a bit of a milestone for us because we started on AWS, where I think the cost problem is the most acute, if you will, and we've hit a point now across Azure and Google where we actually have enough data to say some interesting things about how those clouds work. But in general, we have this term, single pane of glass, which is the idea that you use 5, 6, 7 services, and you want to bundle all those costs into one report.Corey: Yeah. And that is something that we see in many cases where customers are taking a more holistic look at things. But, on some level, when people ask me, “Oh, do you focus on Google bills, too,” or Azure bills in the early days, it was, “Well, not yet. Let's take a look.” And what I was seeing was, they're spending, you know, millions or hundreds of millions, in some cases, on AWS, and oh, yeah, here's, like, a $300,000 thing we're running over on GCP is a proof-of-concept or some bizdev thing. And it's… yeah, why don't we focus on the big numbers first? The true secret of cloud economics is, you know, big numbers first rather than alphabetical, but don't tell anyone I told you that.Everett: It's pretty interesting you say that because, you know, in this graph where we break down costs across providers, you can really see that effect on Google and Azure. So, for example, the number three spending category on Google is BigQuery and I think many people would say BigQuery is kind of the jewel of the Google Cloud empire. Similarly for Azure, we actually found Databricks showing up as a top-ten service. Compare that to AWS where you just see a very routine, you know, compute, database, storage, monitoring, bandwidth, down the line. AWS still is the king of costs, if you will, in terms of, like, just running classic compute workloads. And the other services are a little bit more bespoke, which has been something interesting to see play out in our data.Corey: One thing that I've heard that's fascinating to me is that I've now heard from multiple Fortune 500 companies where the Datadog bill is now a board-level concern, given the size and scale of it. And for fun, once I modeled out all the instance-based pricing models that they have for the suite of services they offer, and at the time was three or $400 a month, per instance to run everything that they've got, which, you know, when you look at the instances that I have, costing, you know, 15, 20 bucks a month, in some cases, hmm, seems a little out of whack. And I can absolutely see that turning into an unbounded growth problem in kind of the same way. I just… I don't need to conquer the world. I'm not VC-backed. I am perfectly content at the scale that I'm at—Everett: [laugh].Corey: —with the focus on the problems that I'm focused on.Everett: Yeah, Datadog has been fascinating. It's been one of our fastest-growing providers of sort of the ‘others' category that we've launched. And I think the thing with Datadog that is interesting is you have this phrase cloud costs are all about cloud architecture and I think that's more true on Datadog than a lot of other services because if you have a model where you have, you know, thousands of hosts, and then you add-on one of Datadogs 20 services, which charges per host, suddenly your cloud bill has grown exponentially compared to probably the thing that you were after. And a similar thing happens—actually, my favorite Datadog cost recommendation is, when you have multiple endpoints, and you have sort of multiple query parameters for those endpoints, you end up in this cardinality situation where suddenly Datadog is tracking, again, like, exponentially increasing number of data points, which it's then charging to you on a usage-based model. And so, Datadog is great partners with AWS and I think it's no surprise because the two of them actually sort of go hand-in-hand in terms of the way that they… I don't want to say take ad—Corey: Extract revenue?Everett: Yeah, extract revenue. That's a good term. And, you know, you might say a similar thing about Snowflake, possibly, and the way that they do things. Like oh, the, you know, warehouse has to be on for one minute, minimum, no matter how long the query runs, and various architectural decisions that these folks make that if you were building a cost-optimized version of the service, you would probably go in the other direction.Corey: One thing that I'm also seeing, too, is that I can look at the AWS bill—and just billing data alone—and then say, “Okay, you're using Datadog, aren't you?” Like, “How did you know that?” Like, well, first, most people are secondly, CloudWatch is your number two largest service spend right now. And it's the downstream effect of hammering all the endpoints with all of the systems. And is that data you're actually using? Probably not, in some cases. It's, everyone turns on all the Datadog integrations the first time and then goes back and resets and never does it again.Everett: Yeah, I think we have this set of advice that we give Datadog folks and a lot of it is just, like, turn down the ingestion volume on your logs. Most likely, logs from 30 days ago that are correlated with some new services that you spun up—like you just talked about—are potentially not relevant anymore, for the kind of day-to-day cadence that you want to get into with your cloud spending. So yeah, I mean, I imagine when you're talking to customers, they're bringing up sort of like this interesting distinction where you may end up in a meeting room with the actual engineering team looking at the actual YAML configuration of the Datadog script, just to get a sense of like, well, what are the buttons I can press here? And so, that's… yeah, I mean, that's one reason cloud costs are a pretty interesting world is, on the surface level, you may end up buying some RIs or savings plans, but then when you really get into saving money, you end up actually changing the knobs on the services that you're talking about.Corey: That's always a fun thing when we talk to people in our sales process. It's been sord—“Are you just going to come in and tell us to buy savings plans or reserved instances?” Because the answer to that used to be, “No, that's ridiculous. That's not what we do.” But then we get into environments and find they haven't bought any of those things in 18 months.Everett: [laugh].Corey: —and it's well… okay, that's step two. Step one is what are you using you shouldn't be? Like, basically measure first then cut as opposed to going the other direction and then having to back your way into stuff. Doesn't go well.Everett: Yeah. One of the things that you were discussing last year that I thought was pretty interesting was the gp3 volumes that are now available for RDS and how those volumes, while they offer a nice discount and a nice bump in price-to-performance on EC2, actually don't offer any of that on RDS except for specific workloads. And so, I think that's the kind of thing where, as you're working with folks, as Vantage is working with people, the discussion ends up in these sort of nuanced niche areas, and that's why I think, like, these reports, hopefully, are helping people get a sense of, like, well, what's normal in my architecture or where am I sort of out of bounds? Oh, the fact that I'm spending most of my bill on NAT gateways and bandwidth egress? Well, that's not normal. That would be something that would be not typical of what your normal AWS user is doing.Corey: Right. There's always a question of, “Am I normal?” is one of the first things people love to ask. And it comes in different forms. But it's benchmarking. It's, okay, how much should it cost us to service a thousand monthly active users? It's like, there's no good way to say that across the board for everyone.Everett: Yeah. I like the model of getting into the actual unit costs. I have this sort of vision in my head of, you know, if I'm Uber and I'm reporting metrics to the public stock market, I'm actually reporting a cost to serve a rider, a cost to deliver an Uber Eats meal, in terms of my cloud spend. And that sort of data is just ridiculously hard to get to today. I think it's what we're working towards with Vantage and I think it's something that with these Cloud Cost Reports, we're hoping to get into over time, where we're actually helping companies think about well, okay, within my cloud spend, it's not just what I'm spending on these different services, there's also an idea of how much of my cost to deliver my service should be realized by my cloud spending.Corey: And then people have the uncomfortable realization that wait, my bill is less a function of number of customers I have but more the number of engineers I've hired. What's going on with that?Everett: [laugh]. Yeah, it is interesting to me just how many people end up being involved in this problem at the company. But to your earlier point, the cloud spending discussion has really ramped up over the past year. And I think, hopefully, we are going to be able to converge on a place where we are realizing the promise of the cloud, if you will, which is that it's actually cheaper. And I think what these reports show so far is, like, we've still got a long ways to go for that.Corey: One thing that I think is opportune about the timing of this recording is that as of last week, Amazon wound up announcing their earnings. And Andy Jassy has started getting on the earnings calls, which is how you know it's bad because the CEO of Amazon never deigned to show up on those things before. And he said that a lot of AWS employees are focused and spending their time on helping customers lower their AWS bills. And I'm listening to this going, “Oh, they must be talking to different customers than the ones that I'm talking to.” Are you seeing a lot of Amazonian involvement in reducing AWS bills? Because I'm not and I'm wondering where these people are hiding.Everett: So, we do see one thing, which is reps pushing savings plans on customers, which in general, is great. It's kind of good for everybody, it locks people into longer-term spend on Amazon, it gets them a lower rate, savings plans have some interesting functionality where they can be automatically applied to the area where they offer the most discount. And so, those things are all positive. I will say with Vantage, we're a cloud cost optimization company, of course, and so when folks talk to us, they often already have talked to their AWS rep. And the classic scenario is, that the rep passes over a large spreadsheet of options and ways to reduce costs, but for the company, that spreadsheet may end up being quite a ways away from the point where they actually realize cost savings.And ultimately, the people that are working on cloud cost optimization for Amazon are account reps who are comped by how much cloud spending their accounts are using on Amazon. And so, at the end of the day, some of the, I would say, most hard-hitting optimizations that you work on that we work on, end up hitting areas where they do actually reduce the bill which ends up being not in the account manager's favor. And so, it's a real chicken-and-egg game, except for savings plans is one area where I think everybody can kind of work together.Corey: I have found that… in fairness, there is some defense for Amazon in this but their cost-cutting approach has been rightsizing instances, buy some savings plans, and we are completely out of ideas. Wait, can you switch to Graviton and/or move to serverless? And I used to make fun of them for this but honestly that is some of the only advice that works across the board, irrespective in most cases, of what a customer is doing. Everything else is nuanced and it depends.That's why in some cases, I find that I'm advising customers to spend more money on certain things. Like, the reason that I don't charge percentage of savings in part is because otherwise I'm incentivized to say things like, “Backups? What are you, some kind of coward? Get rid of them.” And that doesn't seem like it's going to be in the customer's interest every time. And as soon as you start down that path, it starts getting a little weird.But people have asked me, what if my customers reach out to their account teams instead of talking to us? And it's, we do bespoke consulting engagements; I do not believe that we have ever had a client who did not first reach out to their account team. If the account teams were capable of doing this at the level that worked for customers, I would have to be doing something else with my business. It is not something that we are seeing hit customers in a way that is effective, and certainly not at scale. You said—as you were right on this—that there's an element here of account managers doing this stuff, there's an [unintelligible 00:15:54] incentive issue in part, but it's also, quality is extraordinarily uneven when it comes to these things because it is its own niche and a lot of people focus in different areas in different ways.Everett: Yeah. And to the areas that you brought up in terms of general advice that's given, we actually have some data on this in this report. In particular Graviton, this is something we've been tracking the whole time we've been doing these reports, which is the past three quarters and we actually are seeing Graviton adoption start to increase more rapidly than it was before. And so, for this last quarter Q1, we're seeing 5% of our costs that we're measuring on EC2 coming from Graviton, which is up from, I want to say 2% the previous quarter, and, like, less than 1% the quarter before. The previous quarter, we also reported that Lambda costs are now majority on ARM among the Vantage customer base.And that one makes some sense to me just because in most cases with Lambda, it's a flip of a switch. And then to your archival point on backups, this is something that we report in this one is that intelligent tiering, which we saw, like, really make an impact for folks towards the end of last year, the numbers for that were flat quarter over quarter. And so, what I mean by that is, we reported that I think, like, two-thirds of our S3 costs are still in the standard storage tier, which is the most expensive tier. And folks have enabled S3 intelligent tiering, which moves your data to progressively cheaper tiers, but we haven't seen that increase this quarter. So, it's the same number as it was last quarter.And I think speaks to what you're talking about with a ceiling on some cost optimization techniques, where it's like, you're not just going to get rid of all your backups; you're not just going to get rid of your, you know, Amazon WorkSpaces archived desktop snapshots that you need for some HIPAA compliance reason. Those things have an upper limit and so that's where, when the AWS rep comes in, it's like, as they go through the list of top spending categories, the recommendations they can give start to provide diminishing returns.Corey: I also think this is sort of a law of large numbers issue. When you start seeing a drop off in the growth rate of large cloud providers, like, there's a problem, in that there are only so many exabyte scale workloads that can be moved inside of a given quarter into the cloud. You're not going to see the same unbounded infinite growth that you would expect mathematically. And people lose their minds when they start to see those things pointed out, but the blame that oh, that's caused by cost optimization efforts, with respect, bullshit it is. I have seen customers devote significant efforts to reducing their AWS bills and it takes massive amounts of work and even then they don't always succeed in getting there.It gets better, but they still wind up a year later, having spent more on a month-by-month basis than they did when they started. Sure they understand it better and it's organic growth that's driving it and they've solved the low hanging fruit problem, but there is a challenge in acting as a boundary for what is, in effect, an unbounded growth problem.Everett: Yeah. And speaking to growth, I thought Microsoft had the most interesting take on where things could happen next quarter, and that, of course, is AI. And so, they attributed, I think it was, 1% of their guidance regarding 26 or 27% growth for Q2 Cloud revenue and it attributed 1% of that to AI. And I think Amazon is really trying to be in the room for those discussions when a large enterprise is talking about AI workloads because it's one of the few remaining cloud workloads that if it's not in the cloud already, is generating potentially massive amounts of growth for these guys.And so, I'm not really sure if I believe the 1% number. I think Microsoft may be having some fun with the fact that, of course, OpenAI is paying them for acting as a cloud provider for ChatGPT and further API, but I do think that AWS, although they were maybe a little slow to the game, they did, to their credit, launch a number of AI services that I'm excited to see if that contributes to the cost that we're measuring next quarter. We did measure, for the first time, a sudden increase on those new [Inf1 00:20:17] EC2 instances, which are optimized for machine learning. And I think if AWS can have success moving customers to those the way they have with Graviton, then that's going to be a very healthy area of growth for them.Corey: I'll also say that it's pretty clear to me that Amazon does not know what it's doing in its world of machine-learning-powered services. I use Azure for the [unintelligible 00:20:44] clients I built originally for Twitter, then for Mastodon—I'm sure Bluesky is coming—but the problem that I'm seeing there is across the board, start to finish, that there is no cohesive story from the AWS side of here's a picture tell me what's in it and if it's words, describe it to me. That's a single API call when we go to Azure. And the more that Amazon talks about something, I find, the less effective they're being in that space. And they will not stop talking about machine learning. Yes, they have instances that are powered by GPUs; that's awesome. But they're an infrastructure provider and moving up the stack is not in their DNA. But that's where all the interest and excitement and discussion is going to be increasingly in the AI space. Good luck.Everett: I think it might be something similar to what you've talked about before with all the options to run containers on AWS. I think they today have a bit of a grab bag of services and they may actually be looking forward to the fact that they're these truly foundational models which let you do a number of tasks, and so they may not need to rely so much on you know, Amazon Polly and Amazon Rekognition and sort of these task-specific services, which to date, I'm not really sure of the takeoff rates on those. We have this cloud costs leaderboard and I don't think you would find them in the top 50 of AWS services. But we'll see what happens with that.AWS I think, ends up being surprisingly good at sticking with it. I think our view is that they probably have the most customer spend on Kubernetes of any major cloud, even though you might say Google at first had the lead on Kubernetes and maybe should have done more with GKE. But to date, I would kind of agree with your take on AI services and I think Azure is… it's Azure's to lose for the moment.Corey: I would agree. I think the future of the cloud is largely Azure's to lose and it has been for a while, just because they get user experience, they get how to talk to enterprises. I just… I wish they would get security a little bit more effectively, and if failing that, communicating with their customers about security more effectively. But it's hard for a leopard to change its spots. Microsoft though has demonstrated an ability to change their nature multiple times, in ways that I would have bet were impossible. So, I just want to see them do it again. It's about time.Everett: Yeah, it's been interesting building on Azure for the past year or so. I wrote a post recently about, kind of, accessing billing data across the different providers and it's interesting in that every cloud provider is unique in the way that it simply provides an external endpoint for downloading your billing data, but Azure is probably one of the easiest integrations; it's just a REST API. However, behind that REST API are, like, years and years of different ways to pay Microsoft: are you on a pay-as-you-go plan, are you on an Azure enterprise plan? So, there's all this sort of organizational complexity hidden behind Azure and I think sometimes it rears its ugly head in a way that stringing together services on Amazon may not, even if that's still a bear in and of itself, if you will.Corey: Any other surprises that you found in the Cloud Cost Report? I mean, looking through it, it seems directionally aligned with what I see in my environments with customers. Like for example, you're not going to see Kubernetes showing up as a line item on any of these things just because—Everett: Yeah.Corey: That is indistinguishable from a billing perspective when we're looking at EC2 spend versus control plane spend. I don't tend to [find 00:24:04] too much that's shocking me. My numbers are of course, different percentage-wise, but surprise, surprise, different companies doing different things doing different percentages, I'm sure only AWS knows for sure.Everett: Yeah, I think the biggest surprise was just the—and, this could very well just be kind of measurement method, but I really expected to see AI services driving more costs, whether it was GPU instances, or AI-specific services—which we actually didn't report on at all, just because they weren't material—or just any indication that AI was a real driver of cloud spending. But I think what you see instead is sort of the same old folks at the top, and if you look at the breakdown of services across providers, that's, you know, compute, database, storage, bandwidth, monitoring. And if you look at our percentage of AI costs as a percentage of EC2 costs, it's relatively flat, quarter over quarter. So, I would have thought that would have shown up in some way in our data and we really didn't see it.Corey: It feels like there's a law of large numbers things. Everyone's talking about it. It's very hype right now—Everett: Yeah.Corey: But it's also—you talk to these companies, like, “Okay, we have four exabytes of data that we're storing and we have a couple 100,000 instances at any given point in time, so yeah, we're going to start spending $100,000 a month on our AI adventures and experiments.” It's like, that's just noise and froth in the bill, comparatively.Everett: Exactly, yeah. And so, that's why I think Microsoft's thought about AI driving a lot of growth in the coming quarters is, we'll see how that plays out, basically. The one other thing I would point to is—and this is probably not surprising, maybe, for you having been in the infrastructure world and seeing a lot of this, but for me, just seeing the length of time it takes companies to upgrade their instance cycles. We're clocking in at almost three years since the C6 series instances have been released and for just now seeing C6 and R6 start to edge above 10% of our compute usage. I actually wonder if that's just the stranglehold that Intel has on cloud computing workloads because it was only last year around re:Invent that the C6in and the Intel version of the C6 series instances had been released. So, I do think in general, there's supposed to be a price-to-performance benefit of upgrading your instances, and so sometimes it surprises me to see how long it takes companies to get around to doing that.Corey: Generation 6 to 7 is also 6% more expensive in my sampling.Everett: Right. That's right. I think Amazon has some work to do to actually make that price-to-performance argument, sort of the way that we were discussing with gp2 versus gp3 volumes. But yeah, I mean, other than that, I think, in general, my view is that we're past the worst of it, if you will, for cloud spending. Q4 was sort of a real letdown, I think, in terms of the data we had and the earnings that these cloud providers had and I think Q1 is actually everyone looking forward to perhaps what we call out at the beginning of the report, which is a return to normal spend patterns across the cloud.Corey: I think that it's going to be an interesting case. One thing that I'm seeing that might very well explain some of the reluctance to upgrade EC2 instances has been that a lot of those EC2 instances are databases. And once those things are up and running and working, people are hesitant to do too much with them. One of the [unintelligible 00:27:29] roads that I've seen of their savings plan approach is that you can migrate EC2 spend to Fargate to Lambda—and that's great—but not RDS. You're effectively leaving a giant pile of money on the table if you've made a three-year purchase commitment on these things. So, all right, we're not going to be in any rush to migrate to those things, which I think is AWS getting in its own way.Everett: That's exactly right. When we encounter customers that have a large amount of database spend, the most cost-effective option is almost always basically bare-metal EC2 even with the overhead of managing the backup-restore scalability of those things. So, in some ways, that's a good thing because it means that you can then take advantage of the, kind of, heavy committed use options on EC2, but of course, in other ways, it's a bit of a letdown because, in the ideal case, RDS would scale with the level of workloads and the economics would make more sense, but it seems that is really not the case.Corey: I really want to thank you for taking the time to come on the show and talk to me. I'll include a link in the [show notes 00:28:37] to the Cost Report. One thing I appreciate is the fact that it doesn't have one of those gates in front of it of, your email address, and what country you're in, and how can our salespeople best bother you. It's just, here's a link to the PDF. The end. So, thanks for that; it's appreciated. Where else can people go to find you?Everett: So, I'm on Twitter talking about cloud infrastructure and AI. I'm at@retttx, that's R-E-T-T-T-X. And then of course, Vantage also did quick hot-takes on this report with a series of graphs and explainers in a Twitter thread and that's @JoinVantage.Corey: And we will, of course, put links to that in the [show notes 00:29:15]. Thank you so much for your time. I appreciate it.Everett: Thanks, Corey. Great to chat.Corey: Everett Berry, growth in open-source at Vantage. 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, insulting comment that will increase its vitriol generation over generation, by approximately 6%.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
In this episode, Theo Davies and Stephanie Wong speak to Sartaj Singh, Head of Technology at GoJek, who shares inside knowledge on GoJek's explosive growth, from being a ride hailing app, to a multi-platform one that is a now a major eCommerce player in Indonesia, especially in last mile delivery. Sartaj shares GoJek's focus on three pillars, customer incentive, driver rewards and pricing, to ensure consistency in service delivery quality. He also discusses how he looks to improve platformization with his team through innovation, by putting people over processes, and helping engineers address challenges in order to stay agile and scalable. From sitting at the side of the street to solve production issues, to managing and growing a team of over 1,000 in just a few years, listen in as Sartaj shares interesting personal excerpts on GoJek's journey in shifting from a startup “hustler” mindset, to a more corporate way of working, and everything that it entails. Sartaj Singh Sartaj Singh is the Head of Engineering Platforms at Gojek. Sartaj is one of the few engineers who has been with GOJEK since the early days. As a literary enthusiast, he never thought that he would end up working in tech. Sartaj is responsible for driving growth, standardizing and improving Indonesia's multi-service platform. Theo Davies Theo is Head of Cloud Sales Excellence & Productivity at Google Cloud and host of “That Digital Show APAC”. He is a record breaking salesperson, sales leader, coach and speaker with a 20+ year career beginning in sales. Theo is also the President of the Google Public Speaking Academy. Cool things of the week 5 GKE features to help you optimize your clusters blog Interview Gojek site Gojek: Using Machine Learning for forecasting and dynamic pricing blog Introducing Firehose: An open source tool from Gojek blog Meet Optimus, Gojek's open-source cloud data transformation tool blog Gojek: Helping drivers reach their pickup points up to 20% more quickly with Google Maps Platform blog What's something cool you're working on? Theo is trying out Snapchat and is excited about Snap partnering with Google Cloud
Emily Fox is a security engineer @Apple Cloud Services, a CNCF Technical Oversight Committee member and co-chair for a bunch of CNCF events including recently the Cloud Native Security Conference in Seattle. We had a chance to talk to Emily about the first edition of the CNSC 2023, her involvement with the CNCF community. Her role as a security engineer and some career discussions. 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 KubeEdge v1.13.0 released on January 18, 2023, achieves SLSA 3 compliance SLSA 3 compliance KubeVela brings software delivery control plane capabilities to CNCF Incubator GKE Updates: Balanced compute classes are now offered in GKE Autopilot GKE Autopilot now supports exposing randomly assigned host ports for pods GKE has started offering ephemeral storage with local SSDs Added support for Windows Server 2022 nodes AWS announced the availability of AKS anywhere on Snowball Edge Devices Sysdig released their 6th annual Cloud Native Security and Usage Report. Rebooting the Cloud Native Hamburg community group KubeCon EU Amsterdam Schedule Katacoda Kubernetes tutorials shutdown LFX Internships for WASMEdge Kubernetes Community Days (KCDs): Upcoming CFP deadlines: KCD Italy CFP closes February 20 2023 (in-person) KCD Czech + Slovak CFP closes March 1, 2023 (in-person) KCD Bangaluru CFP closes March 20, 2023 (in-person) KCD Zurich CFP closes March 31, 2023 (in-person) KCD Colombia CFP closes March 31, 2023 (in-person) Check out upcoming KCDs that might be in your region: Sponsorship opportunities are available Donation Prospectus available for review KCD Israel 2023, Mar 23, 2023 KCD LA, Mar 9, 2023 KCD Pakistan (Islamabad), February 20, 2023 KCD Netherlands (Amsterdam), February 23-24, 2023 KCD France (Paris), March 7, 2023 KCD Los Angeles, March 9-10, 2023 KCD Ukraine Virtual Fundraiser, March 16, 2023 Links from the interview Emily Fox: Twitter Linkedin Cloud Native Security Con Youtube Playlist How to Secure Your Supply Chain at Scale - Hemil Kadakia & Yonghe Zhao, Yahoo eBPF CIA Triad Waterfall development Cloudcareers.dev podcast Rory McCune on twitter Software Supply Chain Security Emily Fox on SBOM Emily Fox on SDLC Shift Left Security: Best Practices for Getting Started Episode 196 with Benjamin Elder CNSC 2023 seattle guests David Wolf Eric Knauer Liz Rice Mitch Connors Josh Knarr Nick Young Taylor Dolezal Frederick Kautz on SPIFFE/SPIRE Chris Aniszczyk's Blog The Falco Project Cilium Tetragon Pixie Aviatrix Keylime Google Anthos Beyond Cluster-Admin: Getting Started with Kubernetes Users and Permissions - Tiffany Jernigan Standardization & Security - A Perfect Match - Ravi Devineni & Vinny Carpenter, Northwestern Mutual CSI Container: Can You DFIR It? - Alberto Pellitteri & Stefano Chierici, Sysdig Links from the post-interview chat Cloud Native Security Con Eu 2023 CNCF TOC
On this episode of The Cloud Pod, the team wraps up 2022 so far, comparing predictions made with the events so far while projecting into 2023 as the year comes to a close. They discuss the S3 security changes coming from Amazon, the new control plane connectivity options with GCP, and Microsoft's achievement, finally topping a list within the cloud space. A big thanks to this week's sponsor, Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. This week's highlights
About KelseyKelsey Hightower is the Principal Developer Advocate at Google, the co-chair of KubeCon, the world's premier Kubernetes conference, and an open source enthusiast. He's also the co-author of Kubernetes Up & Running: Dive into the Future of Infrastructure.Links: Twitter: @kelseyhightower Company site: Google.com Book: Kubernetes Up & Running: Dive into the Future of Infrastructure TranscriptAnnouncer: Hello and welcome to Screaming in the Cloud, with your host Cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of Cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is brought to us by our friends at Pinecone. They believe that all anyone really wants is to be understood, and that includes your users. AI models combined with the Pinecone vector database let your applications understand and act on what your users want… without making them spell it out. Make your search application find results by meaning instead of just keywords, your personalization system make picks based on relevance instead of just tags, and your security applications match threats by resemblance instead of just regular expressions. Pinecone provides the cloud infrastructure that makes this easy, fast, and scalable. Thanks to my friends at Pinecone for sponsoring this episode. Visit Pinecone.io to understand more.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. I'm joined this week by Kelsey Hightower, who claims to be a principal developer advocate at Google, but based upon various keynotes I've seen him in, he basically gets on stage and plays video games like Tetris in front of large audiences. So I assume he is somehow involved with e-sports. Kelsey, welcome to the show.Kelsey: You've outed me. Most people didn't know that I am a full-time e-sports Tetris champion at home. And the technology thing is just a side gig.Corey: Exactly. It's one of those things you do just to keep the lights on, like you're waiting to get discovered, but in the meantime, you're waiting table. Same type of thing. Some people wait tables you more or less a sling Kubernetes, for lack of a better term.Kelsey: Yes.Corey: So let's dive right into this. You've been a strong proponent for a long time of Kubernetes and all of its intricacies and all the power that it unlocks and I've been pretty much the exact opposite of that, as far as saying it tends to be over complicated, that it's hype-driven and a whole bunch of other, shall we say criticisms that are sometimes bounded in reality and sometimes just because I think it'll be funny when I put them on Twitter. Where do you stand on the state of Kubernetes in 2020?Kelsey: So, I want to make sure it's clear what I do. Because when I started talking about Kubernetes, I was not working at Google. I was actually working at CoreOS where we had a competitor Kubernetes called Fleet. And Kubernetes coming out kind of put this like fork in our roadmap, like where do we go from here? What people saw me doing with Kubernetes was basically learning in public. Like I was really excited about the technology because it's attempting to solve a very complex thing. I think most people will agree building a distributed system is what cloud providers typically do, right? With VMs and hypervisors. Those are very big, complex distributed systems. And before Kubernetes came out, the closest I'd gotten to a distributed system before working at CoreOS was just reading the various white papers on the subject and hearing stories about how Google has systems like Borg tools, like Mesa was being used by some of the largest hyperscalers in the world, but I was never going to have the chance to ever touch one of those unless I would go work at one of those companies.So when Kubernetes came out and the fact that it was open source and I could read the code to understand how it was implemented, to understand how schedulers actually work and then bonus points for being able to contribute to it. Those early years, what you saw me doing was just being so excited about systems that I attended to build on my own, becoming this new thing just like Linux came up. So I kind of agree with you that a lot of people look at it as a more of a hype thing. They're looking at it regardless of their own needs, regardless of understanding how it works and what problems is trying to solve that. My stance on it, it's a really, really cool tool for the level that it operates in, and in order for it to be successful, people can't know that it's there.Corey: And I think that might be where part of my disconnect from Kubernetes comes into play. I have a background in ops, more or less, the grumpy Unix sysadmin because it's not like there's a second kind of Unix sysadmin you're ever going to encounter. Where everything in development works in theory, but in practice things pan out a little differently. I always joke that ops is the difference between theory and practice. In theory, devs can do everything and there's no ops needed. In practice, well it's been a burgeoning career for a while. The challenge with this is Kubernetes at times exposes certain levels of abstraction that, sorry certain levels of detail that generally people would not want to have to think about or deal with, while papering over other things with other layers of abstraction on top of it. That obscure, valuable troubleshooting information from a running something in an operational context. It absolutely is a fascinating piece of technology, but it feels today like it is overly complicated for the use a lot of people are attempting to put it to. Is that a fair criticism from where you sit?Kelsey: So I think the reason why it's a fair criticism is because there are people attempting to run their own Kubernetes cluster, right? So when we think about the cloud, unless you're in OpenStack land, but for the people who look at the cloud and you say, "Wow, this is much easier." There's an API for creating virtual machines and I don't see the distributed state store that's keeping all of that together. I don't see the farm of hypervisors. So we don't necessarily think about the inherent complexity into a system like that, because we just get to use it. So on one end, if you're just a user of a Kubernetes cluster, maybe using something fully managed or you have an ops team that's taking care of everything, your interface of the system becomes this Kubernetes configuration language where you say, "Give me a load balancer, give me three copies of this container running." And if we do it well, then you'd think it's a fairly easy system to deal with because you say, "kubectl, apply," and things seem to start running.Just like in the cloud where you say, "AWS create this VM, or G cloud compute instance, create." You just submit API calls and things happen. I think the fact that Kubernetes is very transparent to most people is, now you can see the complexity, right? Imagine everyone driving with the hood off the car. You'd be looking at a lot of moving things, but we have hoods on cars to hide the complexity and all we expose is the steering wheel and the pedals. That car is super complex but we don't see it. So therefore we don't attribute as complexity to the driving experience.Corey: This to some extent feels it's on the same axis as serverless, with just a different level of abstraction piled onto it. And while I am a large proponent of serverless, I think it's fantastic for a lot of Greenfield projects. The constraints inherent to the model mean that it is almost completely non-tenable for a tremendous number of existing workloads. Some developers like to call it legacy, but when I hear the term legacy I hear, "it makes actual money." So just treating it as, "Oh, it's a science experiment we can throw into a new environment, spend a bunch of time rewriting it for minimal gains," is just not going to happen as companies undergo digital transformations, if you'll pardon the term.Kelsey: Yeah, so I think you're right. So let's take Amazon's Lambda for example, it's a very opinionated high-level platform that assumes you're going to build apps a certain way. And if that's you, look, go for it. Now, one or two levels below that there is this distributed system. Kubernetes decided to play in that space because everyone that's building other platforms needs a place to start. The analogy I like to think of is like in the mobile space, iOS and Android deal with the complexities of managing multiple applications on a mobile device, security aspects, app stores, that kind of thing. And then you as a developer, you build your thing on top of those platforms and APIs and frameworks. Now, it's debatable, someone would say, "Why do we even need an open-source implementation of such a complex system? Why not just everyone moved to the cloud?" And then everyone that's not in a cloud on-premise gets left behind.But typically that's not how open source typically works, right? The reason why we have Linux, the precursor to the cloud is because someone looked at the big proprietary Unix systems and decided to re-implement them in a way that anyone could run those systems. So when you look at Kubernetes, you have to look at it from that lens. It's the ability to democratize these platform layers in a way that other people can innovate on top. That doesn't necessarily mean that everyone needs to start with Kubernetes, just like not everyone needs to start with the Linux server, but it's there for you to build the next thing on top of, if that's the route you want to go.Corey: It's been almost a year now since I made an original tweet about this, that in five years, no one will care about Kubernetes. So now I guess I have four years running on that clock and that attracted a bit of, shall we say controversy. There were people who thought that I meant that it was going to be a flash in the pan and it would dry up and blow away. But my impression of it is that in, well four years now, it will have become more or less system D for the data center, in that there's a bunch of complexity under the hood. It does a bunch of things. No-one sensible wants to spend all their time mucking around with it in most companies. But it's not something that people have to think about in an ongoing basis the way it feels like we do today.Kelsey: Yeah, I mean to me, I kind of see this as the natural evolution, right? It's new, it gets a lot of attention and kind of the assumption you make in that statement is there's something better that should be able to arise, giving that checkpoint. If this is what people think is hot, within five years surely we should see something else that can be deserving of that attention, right? Docker comes out and almost four or five years later you have Kubernetes. So it's obvious that there should be a progression here that steals some of the attention away from Kubernetes, but I think where it's so new, right? It's only five years in, Linux is like over 20 years old now at this point, and it's still top of mind for a lot of people, right? Microsoft is still porting a lot of Windows only things into Linux, so we still discuss the differences between Windows and Linux.The idea that the cloud, for the most part, is driven by Linux virtual machines, that I think the majority of workloads run on virtual machines still to this day, so it's still front and center, especially if you're a system administrator managing BDMs, right? You're dealing with tools that target Linux, you know the Cisco interface and you're thinking about how to secure it and lock it down. Kubernetes is just at the very first part of that life cycle where it's new. We're all interested in even what it is and how it works, and now we're starting to move into that next phase, which is the distro phase. Like in Linux, you had Red Hat, Slackware, Ubuntu, special purpose distros.Some will consider Android a special purpose distribution of Linux for mobile devices. And now that we're in this distro phase, that's going to go on for another 5 to 10 years where people start to align themselves around, maybe it's OpenShift, maybe it's GKE, maybe it's Fargate for EKS. These are now distributions built on top of Kubernetes that start to add a little bit more opinionation about how Kubernetes should be pushed together. And then we'll enter another phase where you'll build a platform on top of Kubernetes, but it won't be worth mentioning that Kubernetes is underneath because people will be more interested on the thing above.Corey: I think we're already seeing that now, in terms of people no longer really care that much what operating system they're running, let alone with distribution of that operating system. The things that you have to care about slip below the surface of awareness and we've seen this for a long time now. Originally to install a web server, it wound up taking a few days and an intimate knowledge of GCC compiler flags, then RPM or D package and then yum on top of that, then ensure installed, once we had configuration management that was halfway decent.Then Docker run, whatever it is. And today feels like it's with serverless technologies being what they are, it's effectively a push a file to S3 or it's equivalent somewhere else and you're done. The things that people have to be aware of and the barrier to entry continually lowers. The downside to that of course, is that things that people specialize in today and effectively make very lucrative careers out of are going to be not front and center in 5 to 10 years the way that they are today. And that's always been the way of technology. It's a treadmill to some extent.Kelsey: And on the flip side of that, look at all of the new jobs that are centered around these cloud-native technologies, right? So you know, we're just going to make up some numbers here, imagine if there were only 10,000 jobs around just Linux system administration. Now when you look at this whole Kubernetes landscape where people are saying we can actually do a better job with metrics and monitoring. Observability is now a thing culturally that people assume you should have, because you're dealing with these distributed systems. The ability to start thinking about multi-regional deployments when I think that would've been infeasible with the previous tools or you'd have to build all those tools yourself. So I think now we're starting to see a lot more opportunities, where instead of 10,000 people, maybe you need 20,000 people because now you have the tools necessary to tackle bigger projects where you didn't see that before.Corey: That's what's going to be really neat to see. But the challenge is always to people who are steeped in existing technologies. What does this mean for them? I mean I spent a lot of time early in my career fighting against cloud because I thought that it was taking away a cornerstone of my identity. I was a large scale Unix administrator, specifically focusing on email. Well, it turns out that there aren't nearly as many companies that need to have that particular skill set in house as it did 10 years ago. And what we're seeing now is this sort of forced evolution of people's skillsets or they hunker down on a particular area of technology or particular application to try and make a bet that they can ride that out until retirement. It's challenging, but at some point it seems that some folks like to stop learning, and I don't fully pretend to understand that. I'm sure I will someday where, "No, at this point technology come far enough. We're just going to stop here, and anything after this is garbage." I hope not, but I can see a world in which that happens.Kelsey: Yeah, and I also think one thing that we don't talk a lot about in the Kubernetes community, is that Kubernetes makes hyper-specialization worth doing because now you start to have a clear separation from concerns. Now the OS can be hyperfocused on security system calls and not necessarily packaging every programming language under the sun into a single distribution. So we can kind of move part of that layer out of the core OS and start to just think about the OS being a security boundary where we try to lock things down. And for some people that play at that layer, they have a lot of work ahead of them in locking down these system calls, improving the idea of containerization, whether that's something like Firecracker or some of the work that you see VMware doing, that's going to be a whole class of hyper-specialization. And the reason why they're going to be able to focus now is because we're starting to move into a world, whether that's serverless or the Kubernetes API.We're saying we should deploy applications that don't target machines. I mean just that step alone is going to allow for so much specialization at the various layers because even on the networking front, which arguably has been a specialization up until this point, can truly specialize because now the IP assignments, how networking fits together, has also abstracted a way one more step where you're not asking for interfaces or binding to a specific port or playing with port mappings. You can now let the platform do that. So I think for some of the people who may be not as interested as moving up the stack, they need to be aware that the number of people we need being hyper-specialized at Linux administration will definitely shrink. And a lot of that work will move up the stack, whether that's Kubernetes or managing a serverless deployment and all the configuration that goes with that. But if you are a Linux, like that is your bread and butter, I think there's going to be an opportunity to go super deep, but you may have to expand into things like security and not just things like configuration management.Corey: Let's call it the unfulfilled promise of Kubernetes. On paper, I love what it hints at being possible. Namely, if I build something that runs well on top of Kubernetes than we truly have a write once, run anywhere type of environment. Stop me if you've heard that one before, 50,000 times in our industry... or history. But in practice, as has happened before, it seems like it tends to fall down for one reason or another. Now, Amazon is famous because for many reasons, but the one that I like to pick on them for is, you can't say the word multi-cloud at their events. Right. That'll change people's perspective, good job. The people tend to see multi-cloud are a couple of different lenses.I've been rather anti multi-cloud from the perspective of the idea that you're setting out day one to build an application with the idea that it can be run on top of any cloud provider, or even on-premises if that's what you want to do, is generally not the way to proceed. You wind up having to make certain trade-offs along the way, you have to rebuild anything that isn't consistent between those providers, and it slows you down. Kubernetes on the other hand hints at if it works and fulfills this promise, you can suddenly abstract an awful lot beyond that and just write generic applications that can run anywhere. Where do you stand on the whole multi-cloud topic?Kelsey: So I think we have to make sure we talk about the different layers that are kind of ready for this thing. So for example, like multi-cloud networking, we just call that networking, right? What's the IP address over there? I can just hit it. So we don't make a big deal about multi-cloud networking. Now there's an area where people say, how do I configure the various cloud providers? And I think the healthy way to think about this is, in your own data centers, right, so we know a lot of people have investments on-premises. Now, if you were to take the mindset that you only need one provider, then you would try to buy everything from HP, right? You would buy HP store's devices, you buy HP racks, power. Maybe HP doesn't sell air conditioners. So you're going to have to buy an air conditioner from a vendor who specializes in making air conditioners, hopefully for a data center and not your house.So now you've entered this world where one vendor does it make every single piece that you need. Now in the data center, we don't say, "Oh, I am multi-vendor in my data center." Typically, you just buy the switches that you need, you buy the power racks that you need, you buy the ethernet cables that you need, and they have common interfaces that allow them to connect together and they typically have different configuration languages and methods for configuring those components. The cloud on the other hand also represents the same kind of opportunity. There are some people who really love DynamoDB and S3, but then they may prefer something like BigQuery to analyze the data that they're uploading into S3. Now, if this was a data center, you would just buy all three of those things and put them in the same rack and call it good.But the cloud presents this other challenge. How do you authenticate to those systems? And then there's usually this additional networking costs, egress or ingress charges that make it prohibitive to say, "I want to use two different products from two different vendors." And I think that's-Corey: ...winds up causing serious problems.Kelsey: Yes, so that data gravity, the associated cost becomes a little bit more in your face. Whereas, in a data center you kind of feel that the cost has already been paid. I already have a network switch with enough bandwidth, I have an extra port on my switch to plug this thing in and they're all standard interfaces. Why not? So I think the multi-cloud gets lost in the chew problem, which is the barrier to entry of leveraging things across two different providers because of networking and configuration practices.Corey: That's often the challenge, I think, that people get bogged down in. On an earlier episode of this show we had Mitchell Hashimoto on, and his entire theory around using Terraform to wind up configuring various bits of infrastructure, was not the idea of workload portability because that feels like the windmill we all keep tilting at and failing to hit. But instead the idea of workflow portability, where different things can wind up being interacted with in the same way. So if this one division is on one cloud provider, the others are on something else, then you at least can have some points of consistency in how you interact with those things. And in the event that you do need to move, you don't have to effectively redo all of your CICD process, all of your tooling, et cetera. And I thought that there was something compelling about that argument.Kelsey: And that's actually what Kubernetes does for a lot of people. For Kubernetes, if you think about it, when we start to talk about workflow consistency, if you want to deploy an application, queue CTL, apply, some config, you want the application to have a load balancer in front of it. Regardless of the cloud provider, because Kubernetes has an extension point we call the cloud provider. And that's where Amazon, Azure, Google Cloud, we do all the heavy lifting of mapping the high-level ingress object that specifies, "I want a load balancer, maybe a few options," to the actual implementation detail. So maybe you don't have to use four or five different tools and that's where that kind of workload portability comes from. Like if you think about Linux, right? It has a set of system calls, for the most part, even if you're using a different distro at this point, Red Hat or Amazon Linux or Google's container optimized Linux.If I build a Go binary on my laptop, I can SCP it to any of those Linux machines and it's going to probably run. So you could call that multi-cloud, but that doesn't make a lot of sense because it's just because of the way Linux works. Kubernetes does something very similar because it sits right on top of Linux, so you get the portability just from the previous example and then you get the other portability and workload, like you just stated, where I'm calling kubectl apply, and I'm using the same workflow to get resources spun up on the various cloud providers. Even if that configuration isn't one-to-one identical.Corey: This episode is sponsored in part by our friends at Uptycs, because they believe that many of you are looking to bolster your security posture with CNAPP and XDR solutions. They offer both cloud and endpoint security in a single UI and data model. Listeners can get Uptycs for up to 1,000 assets through the end of 2023 (that is next year) for $1. But this offer is only available for a limited time on UptycsSecretMenu.com. That's U-P-T-Y-C-S Secret Menu dot com.Corey: One thing I'm curious about is you wind up walking through the world and seeing companies adopting Kubernetes in different ways. How are you finding the adoption of Kubernetes is looking like inside of big E enterprise style companies? I don't have as much insight into those environments as I probably should. That's sort of a focus area for the next year for me. But in startups, it seems that it's either someone goes in and rolls it out and suddenly it's fantastic, or they avoid it entirely and do something serverless. In large enterprises, I see a lot of Kubernetes and a lot of Kubernetes stories coming out of it, but what isn't usually told is, what's the tipping point where they say, "Yeah, let's try this." Or, "Here's the problem we're trying to solve for. Let's chase it."Kelsey: What I see is enterprises buy everything. If you're big enough and you have a big enough IT budget, most enterprises have a POC of everything that's for sale, period. There's some team in some pocket, maybe they came through via acquisition. Maybe they live in a different state. Maybe it's just a new project that came out. And what you tend to see, at least from my experiences, if I walk into a typical enterprise, they may tell me something like, "Hey, we have a POC, a Pivotal Cloud Foundry, OpenShift, and we want some of that new thing that we just saw from you guys. How do we get a POC going?" So there's always this appetite to evaluate what's for sale, right? So, that's one case. There's another case where, when you start to think about an enterprise there's a big range of skillsets. Sometimes I'll go to some companies like, "Oh, my insurance is through that company, and there's ex-Googlers that work there." They used to work on things like Borg, or something else, and they kind of know how these systems work.And they have a slightly better edge at evaluating whether Kubernetes is any good for the problem at hand. And you'll see them bring it in. Now that same company, I could drive over to the other campus, maybe it's five miles away and that team doesn't even know what Kubernetes is. And for them, they're going to be chugging along with what they're currently doing. So then the challenge becomes if Kubernetes is a great fit, how wide of a fit it isn't? How many teams at that company should be using it? So what I'm currently seeing as there are some enterprises that have found a way to make Kubernetes the place where they do a lot of new work, because that makes sense. A lot of enterprises to my surprise though, are actually stepping back and saying, "You know what? We've been stitching together our own platform for the last five years. We had the Netflix stack, we got some Spring Boot, we got Console, we got Vault, we got Docker. And now this whole thing is getting a little more fragile because we're doing all of this glue code."Kubernetes, We've been trying to build our own Kubernetes and now that we know what it is and we know what it isn't, we know that we can probably get rid of this kind of bespoke stack ourselves and just because of the ecosystem, right? If I go to HashiCorp's website, I would probably find the word Kubernetes as much as I find the word Nomad on their site because they've made things like Console and Vault become first-class offerings inside of the world of Kubernetes. So I think it's that momentum that you see across even People Oracle, Juniper, Palo Alto Networks, they're all have seem to have a Kubernetes story. And this is why you start to see the enterprise able to adopt it because it's so much in their face and it's where the ecosystem is going.Corey: It feels like a lot of the excitement and the promise and even the same problems that Kubernetes is aimed at today, could have just as easily been talked about half a decade ago in the context of OpenStack. And for better or worse, OpenStack is nowhere near where it once was. It would felt like it had such promise and such potential and when it didn't pan out, that left a lot of people feeling relatively sad, burnt out, depressed, et cetera. And I'm seeing a lot of parallels today, at least between what was said about OpenStack and what was said about Kubernetes. How do you see those two diverging?Kelsey: I will tell you the big difference that I saw, personally. Just for my personal journey outside of Google, just having that option. And I remember I was working at a company and we were like, "We're going to roll our own OpenStack. We're going to buy a free BSD box and make it a file server. We're going all open sources," like do whatever you want to do. And that was just having so many issues in terms of first-class integrations, education, people with the skills to even do that. And I was like, "You know what, let's just cut the check for VMware." We want virtualization. VMware, for the cost and when it does, it's good enough. Or we can just actually use a cloud provider. That space in many ways was a purely solved problem. Now, let's fast forward to Kubernetes, and also when you get OpenStack finished, you're just back where you started.You got a bunch of VMs and now you've got to go figure out how to build the real platform that people want to use because no one just wants a VM. If you think Kubernetes is low level, just having OpenStack, even OpenStack was perfect. You're still at square one for the most part. Maybe you can just say, "Now I'm paying a little less money for my stack in terms of software licensing costs," but from an extraction and automation and API standpoint, I don't think OpenStack moved the needle in that regard. Now in the Kubernetes world, it's solving a huge gap.Lots of people have virtual machine sprawl than they had Docker sprawl, and when you bring in this thing by Kubernetes, it says, "You know what? Let's reign all of that in. Let's build some first-class abstractions, assuming that the layer below us is a solved problem." You got to remember when Kubernetes came out, it wasn't trying to replace the hypervisor, it assumed it was there. It also assumed that the hypervisor had APIs for creating virtual machines and attaching disc and creating load balancers, so Kubernetes came out as a complementary technology, not one looking to replace. And I think that's why it was able to stick because it solved a problem at another layer where there was not a lot of competition.Corey: I think a more cynical take, at least one of the ones that I've heard articulated and I tend to agree with, was that OpenStack originally seemed super awesome because there were a lot of interesting people behind it, fascinating organizations, but then you wound up looking through the backers of the foundation behind it and the rest. And there were something like 500 companies behind it, an awful lot of them were these giant organizations that ... they were big e-corporate IT enterprise software vendors, and you take a look at that, I'm not going to name anyone because at that point, oh will we get letters.But at that point, you start seeing so many of the patterns being worked into it that it almost feels like it has to collapse under its own weight. I don't, for better or worse, get the sense that Kubernetes is succumbing to the same thing, despite the CNCF having an awful lot of those same backers behind it and as far as I can tell, significantly more money, they seem to have all the money to throw at these sorts of things. So I'm wondering how Kubernetes has managed to effectively sidestep I guess the open-source miasma that OpenStack didn't quite manage to avoid.Kelsey: Kubernetes gained its own identity before the foundation existed. Its purpose, if you think back from the Borg paper almost eight years prior, maybe even 10 years prior. It defined this problem really, really well. I think Mesos came out and also had a slightly different take on this problem. And you could just see at that time there was a real need, you had choices between Docker Swarm, Nomad. It seems like everybody was trying to fill in this gap because, across most verticals or industries, this was a true problem worth solving. What Kubernetes did was played in the exact same sandbox, but it kind of got put out with experience. It's not like, "Oh, let's just copy this thing that already exists, but let's just make it open."And in that case, you don't really have your own identity. It's you versus Amazon, in the case of OpenStack, it's you versus VMware. And that's just really a hard place to be in because you don't have an identity that stands alone. Kubernetes itself had an identity that stood alone. It comes from this experience of running a system like this. It comes from research and white papers. It comes after previous attempts at solving this problem. So we agree that this problem needs to be solved. We know what layer it needs to be solved at. We just didn't get it right yet, so Kubernetes didn't necessarily try to get it right.It tried to start with only the primitives necessary to focus on the problem at hand. Now to your point, the extension interface of Kubernetes is what keeps it small. Years ago I remember plenty of meetings where we all got in rooms and said, "This thing is done." It doesn't need to be a PaaS. It doesn't need to compete with serverless platforms. The core of Kubernetes, like Linux, is largely done. Here's the core objects, and we're going to make a very great extension interface. We're going to make one for the container run time level so that way people can swap that out if they really want to, and we're going to do one that makes other APIs as first-class as ones we have, and we don't need to try to boil the ocean in every Kubernetes release. Everyone else has the ability to deploy extensions just like Linux, and I think that's why we're avoiding some of this tension in the vendor world because you don't have to change the core to get something that feels like a native part of Kubernetes.Corey: What do you think is currently being the most misinterpreted or misunderstood aspect of Kubernetes in the ecosystem?Kelsey: I think the biggest thing that's misunderstood is what Kubernetes actually is. And the thing that made it click for me, especially when I was writing the tutorial Kubernetes The Hard Way. I had to sit down and ask myself, "Where do you start trying to learn what Kubernetes is?" So I start with the database, right? The configuration store isn't Postgres, it isn't MySQL, it's Etcd. Why? Because we're not trying to be this generic data stores platform. We just need to store configuration data. Great. Now, do we let all the components talk to Etcd? No. We have this API server and between the API server and the chosen data store, that's essentially what Kubernetes is. You can stop there. At that point, you have a valid Kubernetes cluster and it can understand a few things. Like I can say, using the Kubernetes command-line tool, create this configuration map that stores configuration data and I can read it back.Great. Now I can't do a lot of things that are interesting with that. Maybe I just use it as a configuration store, but then if I want to build a container platform, I can install the Kubernetes kubelet agent on a bunch of machines and have it talk to the API server looking for other objects you add in the scheduler, all the other components. So what that means is that Kubernetes most important component is its API because that's how the whole system is built. It's actually a very simple system when you think about just those two components in isolation. If you want a container management tool that you need a scheduler, controller, manager, cloud provider integrations, and now you have a container tool. But let's say you want a service mesh platform. Well in a service mesh you have a data plane that can be Nginx or Envoy and that's going to handle routing traffic. And you need a control plane. That's going to be something that takes in configuration and it uses that to configure all the things in a data plane.Well, guess what? Kubernetes is 90% there in terms of a control plane, with just those two components, the API server, and the data store. So now when you want to build control planes, if you start with the Kubernetes API, we call it the API machinery, you're going to be 95% there. And then what do you get? You get a distributed system that can handle kind of failures on the back end, thanks to Etcd. You're going to get our backs or you can have permission on top of your schemas, and there's a built-in framework, we call it custom resource definitions that allows you to articulate a schema and then your own control loops provide meaning to that schema. And once you do those two things, you can build any platform you want. And I think that's one thing that it takes a while for people to understand that part of Kubernetes, that the thing we talk about today, for the most part, is just the first system that we built on top of this.Corey: I think that's a very far-reaching story with implications that I'm not entirely sure I am able to wrap my head around. I hope to see it, I really do. I mean you mentioned about writing Learn Kubernetes the Hard Way and your tutorial, which I'll link to in the show notes. I mean my, of course, sarcastic response to that recently was to register the domain Kubernetes the Easy Way and just re-pointed to Amazon's ECS, which is in no way shape or form Kubernetes and basically has the effect of irritating absolutely everyone as is my typical pattern of behavior on Twitter. But I have been meaning to dive into Kubernetes on a deeper level and the stuff that you've written, not just the online tutorial, both the books have always been my first port of call when it comes to that. The hard part, of course, is there's just never enough hours in the day.Kelsey: And one thing that I think about too is like the web. We have the internet, there's webpages, there's web browsers. Web Browsers talk to web servers over HTTP. There's verbs, there's bodies, there's headers. And if you look at it, that's like a very big complex system. If I were to extract out the protocol pieces, this concept of HTTP verbs, get, put, post and delete, this idea that I can put stuff in a body and I can give it headers to give it other meaning and semantics. If I just take those pieces, I can bill restful API's.Hell, I can even bill graph QL and those are just different systems built on the same API machinery that we call the internet or the web today. But you have to really dig into the details and pull that part out and you can build all kind of other platforms and I think that's what Kubernetes is. It's going to probably take people a little while longer to see that piece, but it's hidden in there and that's that piece that's going to be, like you said, it's going to probably be the foundation for building more control planes. And when people build control planes, I think if you think about it, maybe Fargate for EKS represents another control plane for making a serverless platform that takes to Kubernetes API, even though the implementation isn't what you find on GitHub.Corey: That's the truth. Whenever you see something as broadly adopted as Kubernetes, there's always the question of, "Okay, there's an awful lot of blog posts." Getting started to it, learn it in 10 minutes, I mean at some point, I'm sure there are some people still convince Kubernetes is, in fact, a breakfast cereal based upon what some of the stuff the CNCF has gotten up to. I wouldn't necessarily bet against it socks today, breakfast cereal tomorrow. But it's hard to find a decent level of quality, finding the certain quality bar of a trusted source to get started with is important. Some people believe in the hero's journey, story of a narrative building.I always prefer to go with the morons journey because I'm the moron. I touch technologies, I have no idea what they do and figure it out and go careening into edge and corner cases constantly. And by the end of it I have something that vaguely sort of works and my understanding's improved. But I've gone down so many terrible paths just by picking a bad point to get started. So everyone I've talked to who's actually good at things has pointed to your work in this space as being something that is authoritative and largely correct and given some of these people, that's high praise.Kelsey: Awesome. I'm going to put that on my next performance review as evidence of my success and impact.Corey: Absolutely. Grouchy people say, "It's all right," you know, for the right people that counts. If people want to learn more about what you're up to and see what you have to say, where can they find you?Kelsey: I aggregate most of outward interactions on Twitter, so I'm @KelseyHightower and my DMs are open, so I'm happy to field any questions and I attempt to answer as many as I can.Corey: Excellent. Thank you so much for taking the time to speak with me today. I appreciate it.Kelsey: Awesome. I was happy to be here.Corey: Kelsey Hightower, Principal Developer Advocate at Google. I'm Corey Quinn. This is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple podcasts. If you've hated this podcast, please leave a five-star review on Apple podcasts and then leave a funny comment. Thanks.Announcer: This has been this week's episode of Screaming in the Cloud. You can also find more Core at screaminginthecloud.com or wherever fine snark is sold.Announcer: This has been a HumblePod production. Stay humble.
Guests Sharon Fang and Michael Sudakovitch are here this week to talk with Max Saltonstall and Daryl Ducharme about Google's Active Assist optimization portfolio and managing cloud projects efficiently. Michael, tech lead at Uber, first employed Active Assist for the company in their security department, but they have since realized how useful Active Assist is in many areas of the resource management space. Responsible architects, Michael points out, continually evaluate their resources and patch, update, or remove as necessary to ensure proper security and optimize spending. Sharon helps us understand resource management further and how Active Assist helps teams find resources that can be changed or even removed for better spending, tighter security, and smaller carbon footprint. Active Assist will even recommend the removal of entire projects that have become dormant. Michael talks in detail about Uber's use of Active Assist and how it helped them find vulnerable projects that could be removed for better security. Sharon highlights the effects of Active Assist on reducing CO2 emissions as well, as discontinued projects keep hardware running needlessly. As Michael and his team at Uber began taking advantage of all Active Assist had to offer, Google worked with him to answer questions, tailor resources, and take feedback to improve offerings. The future includes a portfolio expansion of resource life cycle management tools to identify more idol systems like GKE clusters and helping larger customers take advantage of Active Assist at scale automatically. Together, Sharon and Michael tell us stories about the partnership and interesting findings and results of Uber's carbon footprint reduction journey. Sharon Fang Sharon Fang is a Product Manager for Google Cloud's Active Assist, which aims to help users optimize their cloud operations with recommendations. Michael Sudakovitch Michael is a Tech Lead at Uber's Engineering Security organization, focusing on securing and optimizing Uber's Multi-Cloud infrastructure. Cool things of the week Solving internal search problems with Dialogflow blog Automating self-service tech support with Tensorflow blog Introducing IAM Deny, a simple way to harden your security posture at scale blog Supporting healthcare delivery with cloud-native medical imaging blog Interview Active Assist site Uber site Uber Engineering Blog site How ML-fueled recommendations help developers optimize security, price-performance, and carbon reduction blog Introducing Unattended Project Recommender: discover, reclaim, or deprecate abandoned projects under your organization blog Reduce your cloud carbon footprint with new Active Assist recommendations blog What's something cool you're working on? Max is sorting out the final blog posts of the year, planning some secret Santa holiday festivities for the team, and prepping cranberry sauces. Daryl is planning videos for the new year, including a video to help celebrate our 1 millionth subscriber on the Google Cloud Tech YouTube channel and several videos to help people get the most out of Google Cloud IAM features. Hosts Max Saltonstall and Daryl Ducharme
Kaslin Fields, Developer Advocate at Google and CNCF Ambassador, shares her talk, “Intro to Kubernetes & GKE.” She explains containers, Kubernetes, GKE, and how they work on the Google Cloud Platform. She also discusses the difference between GKE Standard and Autopilot.
Louis Bailleul is a Chief Enterprise Architect at PGS. After years of running highly-ranked super computers to process PGS' seismic data, Louis's team at PGS has lead a transition to Google Cloud. Listen in to learn about HPC in Google Cloud with GKE, and to explore using Kubernetes to do processing on vessels at sea! Do you have something cool to share? Some questions? Let us know: web: kubernetespodcast.com mail: kubernetespodcast@google.com twitter: @kubernetespod Chatter of the week Listen to the KubeCon NA 2022 recap episode News of the week Docker + Wasm Istio control plane vulnerability CVE-2022-39278 KubeFlow joins CNCF as an Incubating Project CNCF Backstage course CNCF Istio intro course Links from the interview PGS A picture of a PGS vessel PGS post from 2021 about their supercomputing rankings and transition to Google Cloud Top500 List Kubernetes Custom Resources (CRDs) Scaling Kubernetes to Thousands of CRDs Google Cloud Spot Instances Google Cloud Preemptible VM Instances Google Cloud - Manage capacity and quota KubeCon NA 2019: How the Department of Defense Moved to Kubernetes and Istio - Nicolas Chaillan Bare Metal K8s Clustering at Chick-fil-A Scale by Brian Chambers, Caleb Hurd, and Alex Crane
About ChenChen Goldberg is GM and Vice President of Engineering at Google Cloud, where she leads the Cloud Runtimes (CR) product area, helping customers deliver greater value, effortlessly. The CR portfolio includes both Serverless and Kubernetes based platforms on Google Cloud, private cloud and other public clouds. Chen is a strong advocate for customer empathy, building products and solutions that matter. Chen has been core to Google Cloud's open core vision since she joined the company six years ago. During that time, she has led her team to focus on helping development teams increase their agility and modernize workloads. Prior to joining Google, Chen wore different hats in the tech industry including leadership positions in IT organizations, SI teams and SW product development, contributing to Chen's broad enterprise perspective. She enjoys mentoring IT talent both in and outside of Google. Chen lives in Mountain View, California, with her husband and three kids. Outside of work she enjoys hiking and baking.Links Referenced: Twitter: https://twitter.com/GoldbergChen LinkedIn: https://www.linkedin.com/in/goldbergchen/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Forget everything you know about SSH and try Tailscale. Imagine if you didn't need to manage PKI or rotate SSH keys every time someone leaves. That'd be pretty sweet, wouldn't it? With Tailscale SSH, you can do exactly that. Tailscale gives each server and user device a node key to connect to its VPN, and it uses the same node key to authorize and authenticate SSH.Basically you're SSHing the same way you manage access to your app. What's the benefit here? Built-in key rotation, permissions as code, connectivity between any two devices, reduce latency, and there's a lot more, but there's a time limit here. You can also ask users to reauthenticate for that extra bit of security. Sounds expensive?Nope, I wish it were. Tailscale is completely free for personal use on up to 20 devices. To learn more, visit snark.cloud/tailscale. Again, that's snark.cloud/tailscaleCorey: Welcome to Screaming in the Cloud, I'm Corey Quinn. When I get bored and the power goes out, I find myself staring at the ceiling, figuring out how best to pick fights with people on the internet about Kubernetes. Because, well, I'm basically sad and have a growing collection of personality issues. My guest today is probably one of the best people to have those arguments with. Chen Goldberg is the General Manager of Cloud Runtimes and VP of Engineering at Google Cloud. Chen, Thank you for joining me today.Chen: Thank you so much, Corey, for having me.Corey: So, Google has been doing a lot of very interesting things in the cloud, and the more astute listener will realize that interesting is not always necessarily a compliment. But from where I sit, I am deeply vested in the idea of a future where we do not have a cloud monoculture. As I've often said, I want, “What cloud should I build something on in five to ten years?” To be a hard question to answer, and not just because everything is terrible. I think that Google Cloud is absolutely a bright light in the cloud ecosystem and has been for a while, particularly with this emphasis around developer experience. All of that said, Google Cloud is sort of a big, unknowable place, at least from the outside. What is your area of responsibility? Where do you start? Where do you stop? In other words, what can I blame you for?Chen: Oh, you can blame me for a lot of things if you want to. I [laugh] might not agree with that, but that's—Corey: We strive for accuracy in these things, though.Chen: But that's fine. Well, first of all, I've joined Google about seven years ago to lead the Kubernetes and GKE team, and ever since, continued at the same area. So evolved, of course, Kubernetes, and Google Kubernetes Engine, and leading our hybrid and multi-cloud strategy as well with technologies like Anthos. And now I'm responsible for the entire container runtime, which includes Kubernetes and the serverless solutions.Corey: A while back, I, in fairly typical sarcastic form, wound up doing a whole inadvertent start of a meme where I joked about there being 17 ways to run containers on AWS. And then as that caught on, I wound up listing out 17 services you could use to do that. A few months went past and then I published a sequel of 17 more services you can use to run Kubernetes. And while that was admittedly tongue-in-cheek, it does lead to an interesting question that's ecosystem-wide. If I look at Google Cloud, I have Cloud Run, I have GKE, I have GCE if I want to do some work myself.It feels like more and more services are supporting Docker in a variety of different ways. How should customers and/or people like me—though, I am sort of a customer as well since I do pay you folks every month—how should we think about containers and services in which to run them?Chen: First of all, I think there's a lot of credit that needs to go to Docker that made containers approachable. And so, Google has been running containers forever. Everything within Google is running on containers, even our VMs, even our cloud is running on containers, but what Docker did was creating a packaging mechanism to improve developer velocity. So, that's on its own, it's great. And one of the things, by the way, that I love about Google Cloud approach to containers and Docker that yes, you can take your Docker container and run it anywhere.And it's actually really important to ensure what we call interoperability, or low barrier to entry to a new technology. So, I can take my Docker container, I can move it from one platform to another, and so on. So, that's just to start with on a containers. Between the different solutions, so first of all, I'm all about managed services. You are right, there are many ways to run a Kubernetes. I'm taking a lot of pride—Corey: The best way is always to have someone else run it for you. Problem solved. Great, the best kind of problems are always someone else's.Chen: Yes. And I'm taking a lot of pride of what our team is doing with Kubernetes. I mean, we've been working on that for so long. And it's something that you know, we've coined that term, I think back in 2016, so there is a success disaster, but there's also what we call sustainable success. So, thinking about how to set ourselves up for success and scale. Very proud of that service.Saying that, not everybody and not all your workloads you need the flexibility that Kubernetes gives you in all the ecosystem. So, if you start with containers your first time, you should start with Cloud Run. It's the easiest way to run your containers. That's one. If you are already in love with Kubernetes, we won't take it away from you. Start with GKE. Okay [laugh]? Go all-in. Okay, we are all in loving Kubernetes as well. But what my team and I are working on is to make sure that those will work really well together. And we actually see a lot of customers do that.Corey: I'd like to go back a little bit in history to the rise of Docker. I agree with you it was transformative, but containers had been around in various forms—depending upon how you want to define it—dating back to the '70s with logical partitions on mainframes. Well, is that a container? Is it not? Well, sort of. We'll assume yes for the sake of argument.The revelation that I found from Docker was the developer experience, start to finish. Suddenly, it was a couple commands and you were just working, where previously it had taken tremendous amounts of time and energy to get containers working in that same context. And I don't even know today whether or not the right way to contextualize containers is as sort of a lite version of a VM, as a packaging format, as a number of other things that you could reasonably call it. How do you think about containers?Chen: So, I'm going to do, first of all, a small [unintelligible 00:06:31]. I actually started my career as a system mainframe engineer—Corey: Hmm.Chen: And I will share that when you know, I've learned Kubernetes, I'm like, “Huh, we already have done all of that, in orchestration, in workload management on mainframe,” just to the side. The way I think about containers is as a—two things: one, it is a packaging of an application, but the other thing which is also critical is the decoupling between your application and the OS. So, having that kind of abstraction and allowing you to portable and move it between environments. So, those are the two things that are when I think about containers. And what technologies like Kubernetes and serverless gives on top of that is that manageability and making sure that we take care of everything else that is needed for you to run your application.Corey: I've been, how do I put this, getting some grief over the past few years, in the best ways possible, around a almost off-the-cuff prediction that I made, which was that in five years, which is now a lot closer to two, basically, nobody is going to care about Kubernetes. And I could have phrased that slightly more directly because people think I was trying to say, “Oh, Kubernetes is just hype. It's going to go away. Nobody's going to worry about it anymore.” And I think that is a wildly inaccurate prediction.My argument is that people are not going to have to think about it in the same way that they are today. Today, if I go out and want to go back to my days of running production services in anger—and by ‘anger,' I of course mean in production—then it would be difficult for me to find a role that did not at least touch upon Kubernetes. But people who can work with that technology effectively are in high demand and they tend to be expensive, not to mention then thinking about all of the intricacies and complexities that Kubernetes brings to the foreground, that is what doesn't feel sustainable to me. The idea that it's going to have to collapse down into something else is, by necessity, going to have to emerge. How are you seeing that play out? And also, feel free to disagree with the prediction. I am thrilled to wind up being told that I'm wrong it's how I learn the most.Chen: I don't know if I agree with the time horizon of when that will happen, but I will actually think it's a failure on us if that won't be the truth, that the majority of people will not need to know about Kubernetes and its internals. And you know, we keep saying that, like, hey, we need to make it more, like, boring, and easy, and I've just said like, “Hey, you should use managed.” And we have lots of customers that says that they're just using GKE and it scales on their behalf and they don't need to do anything for that and it's just like magic. But from a technology perspective, there is still a way to go until we can make that disappear.And there will be two things that will push us into that direction. One is—you mentioned that is as well—the talent shortage is real. All the customers that I speak with, even if they can find those great people that are experts, they're actually more interesting things for them to work on, okay? You don't need to take, like, all the people in your organization and put them on building the infrastructure. You don't care about that. You want to build innovation and promote your business.So, that's one. The second thing is that I do expect that the technology will continue to evolve and are managed solutions will be better and better. So hopefully, with these two things happening together, people will not care that what's under the hood is Kubernetes. Or maybe not even, right? I don't know exactly how things will evolve.Corey: From where I sit, what are the early criticisms I had about Docker, which I guess translates pretty well to Kubernetes, are that they solve a few extraordinarily painful problems. In the case of Docker, it was, “Well, it works on my machine,” as a grumpy sysadmin, the way I used to be, the only real response we had to that was, “Well. Time to backup your email, Skippy, because your laptop is going into production, then.” Now, you can effectively have a high-fidelity copy of production, basically anywhere, and we've solved the problem of making your Mac laptop look like a Linux server. Great, okay, awesome.With Kubernetes, it also feels, on some level, like it solves for very large-scale Google-type of problems where you want to run things across at least a certain point of scale. It feels like even today, it suffers from having an easy Hello World-style application to deploy on top of it. Using it for WordPress, or some other form of blogging software, for example, is stupendous overkill as far as the Hello World story tends to go. Increasingly as a result, it feels like it's great for the large-scale enterprise-y applications, but the getting started story of how do I have a service I could reasonably run in production? How do I contextualize that, in the world of Kubernetes? How do you respond to that type of perspective?Chen: We'll start with maybe a short story. I started my career in the Israeli army. I was head of the department and one of the lead technology units and I was responsible for building a PAS. In essence, it was 20-plus years ago, so we didn't really call it a PAS but that's what it was. And then at some point, it was amazing, developers were very productive, we got innovation again, again. And then there was some new innovation just at the beginning of web [laugh] at some point.And it was actually—so two things I've noticed back then. One, it was really hard to evolve the platform to allow new technologies and innovation, and second thing, from a developer perspective, it was like a black box. So, the developers team that people were—the other development teams couldn't really troubleshoot environment; they were not empowered to make decisions or [unintelligible 00:12:29] in the platform. And you know, when it was just started with Kubernetes—by the way, beginning, it only supported 100 nodes, and then 1000 nodes. Okay, it was actually not for scale; it actually solved those two problems, which I'm—this is where I spend most of my time.So, the first one, we don't want magic, okay? To be clear on, like, what's happening, I want to make sure that things are consistent and I can get the right observability. So, that's one. The second thing is that we invested so much in the extensibility an environment that it's, I wouldn't say it's easy, but it's doable to evolve Kubernetes. You can change the models, you can extend it you can—there is an ecosystem.And you know, when we were building it, I remember I used to tell my team, there won't be a Kubernetes 2.0. Which is for a developer, it's [laugh] frightening. But if you think about it and you prepare for that, you're like, “Huh. Okay, what does that mean with how I build my APIs? What does that mean of how we build a system?” So, that was one. The second thing I keep telling my team, “Please don't get too attached to your code because if it will still be there in 5, 10 years, we did something wrong.”And you can see areas within Kubernetes, again, all the extensions. I'm very proud of all the interfaces that we've built, but let's take networking. This keeps to evolve all the time on the API and the surface area that allows us to introduce new technologies. I love it. So, those are the two things that have nothing to do with scale, are unique to Kubernetes, and I think are very empowering, and are critical for the success.Corey: One thing that you said that resonates most deeply with me is the idea that you don't want there to be magic, where I just hand it to this thing and it runs it as if by magic. Because, again, we've all run things in anger in production, and what happens when the magic breaks? When you're sitting around scratching your head with no idea how it starts or how it stops, that is scary. I mean, I recently wound up re-implementing Google Cloud Distinguished Engineer Kelsey Hightower's “Kubernetes the Hard Way” because he gave a terrific tutorial that I ran through in about 45 minutes on top of Google Cloud. It's like, “All right, how do I make this harder?”And the answer is to do it on AWS, re-implement it there. And my experiment there can be found at kubernetesthemuchharderway.com because I have a vanity domain problem. And it taught me he an awful lot, but one of the challenges I had as I went through that process was, at one point, the nodes were not registering with the controller.And I ran out of time that day and turned everything off—because surprise bills are kind of what I spend my time worrying about—turn it on the next morning to continue and then it just worked. And that was sort of the spidey sense tingling moment of, “Okay, something wasn't working and now it is, and I don't understand why. But I just rebooted it and it started working.” Which is terrifying in the context of a production service. It was understandable—kind of—and I think that's the sort of thing that you understand a lot better, the more you work with it in production, but a counterargument to that is—and I've talked about it on this show before—for this podcast, I wind up having sponsors from time to time, who want to give me fairly complicated links to go check them out, so I have the snark.cloud URL redirector.That's running as a production service on top of Google Cloud Run. It took me half an hour to get that thing up and running; I haven't had to think about it since, aside from a three-second latency that was driving me nuts and turned out to be a sleep hidden in the code, which I can't really fault Google Cloud Run for so much as my crappy nonsense. But it just works. It's clearly running atop Kubernetes, but I don't have to think about it. That feels like the future. It feels like it's a glimpse of a world to come, we're just starting to dip our toes into. That, at least to me, feels like a lot more of the abstractions being collapsed into something easily understandable.Chen: [unintelligible 00:16:30], I'm happy you say that. When talking with customers and we're showing, like, you know, yes, they're all in Kubernetes and talking about Cloud Run and serverless, I feel there is that confidence level that they need to overcome. And that's why it's really important for us in Google Cloud is to make sure that you can mix and match. Because sometimes, you know, a big retail customer of ours, some of their teams, it's really important for them to use a Kubernetes-based platform because they have their workloads also running on-prem and they want to serve the same playbooks, for example, right? How do I address issues, how do I troubleshoot, and so on?So, that's one set of things. But some cloud only as simple as possible. So, can I use both of them and still have a similar developer experience, and so on? So, I do think that we'll see more of that in the coming years. And as the technology evolves, then we'll have more and more, of course, serverless solutions.By the way, it doesn't end there. Like, we see also, you know, databases and machine learning, and like, there are so many more managed services that are making things easy. And that's what excites me. I mean, that's what's awesome about what we're doing in cloud. We are building platforms that enable innovation.Corey: I think that there's an awful lot of power behind unlocking innovation from a customer perspective. The idea that I can use a cloud provider to wind up doing an experiment to build something in the course of an evening, and if it works, great, I can continue to scale up without having to replace, you know, the crappy Raspberry Pi-level hardware in my spare room with serious enterprise servers in a data center somewhere. The on-ramp and the capability and the lack of long-term commitments is absolutely magical. What I'm also seeing that is contributing to that is the de facto standard that's emerged of most things these days support Docker, for better or worse. There are many open-source tools that I see where, “Oh, how do I get this up and running?”“Well, you can go over the river and through the woods and way past grandmother's house to build this from source or run this Docker file.” I feel like that is the direction the rest of the world is going. And as much fun as it is to sit on the sidelines and snark, I'm finding a lot more capability stories emerging across the board. Does that resonate with what you're seeing, given that you are inherently working at very large scale, given the [laugh] nature of where you work?Chen: I do see that. And I actually want to double down on the open standards, which I think this is also something that is happening. At the beginning, we talked about I want it to be very hard when I choose the cloud provider. But innovation doesn't only come from cloud providers; there's a lot of companies and a lot of innovation happening that are building new technologies on top of those cloud providers, and I don't think this is going to stop. Innovation is going to come from many places, and it's going to be very exciting.And by the way, things are moving super fast in our space. So, the investment in open standard is critical for our industry. So, Docker is one example. Google is in [unintelligible 00:19:46] speaking, it's investing a lot in building those open standards. So, we have Docker, we have things like of course Kubernetes, but we are also investing in open standards of security, so we are working with other partners around [unintelligible 00:19:58], defining how you can secure the software supply chain, which is also critical for innovation. So, all of those things that reduce the barrier to entry is something that I'm personally passionate about.Corey: Scaling containers and scaling Kubernetes is hard, but a whole ‘nother level of difficulty is scaling humans. You've been at Google for, as you said, seven years and you did not start as a VP there. Getting promoted from Senior Director to VP at Google is a, shall we say, heavy lift. You also mentioned that you previously started with, I believe, it was a seven-person team at one point. How have you been able to do that? Because I can see a world in which, “Oh, we just write some code and we can scale the computers pretty easily,” I've never found a way to do that for people.Chen: So yes, I started actually—well not 7, but the team was 30 people [laugh]. And you can imagine how surprised I was when I joining Google Cloud with Kubernetes and GKE and it was a pretty small team, to the beginning of those days. But the team was already actually on the edge of burning out. You know, pings on Slack, the GitHub issues, there was so many things happening 24/7.And the thing was just doing everything. Everybody were doing everything. And one of the things I've done on my second month on the team—I did an off-site, right, all managers; that's what we do; we do off-sites—and I brought the team in to talk about—the leadership team—to talk about our team values. And in the beginning, they were a little bit pissed, I would say, “Okay, Chen. What's going on? You're wasting two days of our lives to talk about those things. Why we are not doing other things?”And I was like, “You know guys, this is really important. Let's talk about what's important for us.” It was an amazing it worked. By the way, that work is still the foundation of the culture in the team. We talked about the three values that we care about and how that will look like.And the reason it's important is that when you scale teams, the key thing is actually to scale decision-making. So, how do you scale decision-making? I think there are two things there. One is what you're trying to achieve. So, people should know and understand the vision and know where we want to get to.But the second thing is, how do we work? What's important for us? How do we prioritize? How do we make trade-offs? And when you have both the what we're trying to do and the how, you build that team culture. And when you have that, I find that you're set up more for success for scaling the team.Because then the storyteller is not just the leader or the manager. The entire team is a storyteller of how things are working in this team, how do we work, what you're trying to achieve, and so on. So, that's something that had been a critical. So, that's just, you know, from methodology of how I think it's the right thing to scale teams. Specifically, with a Kubernetes, there were more issues that we needed to work on.For example, building or [recoding 00:23:05] different functions. It cannot be just engineering doing everything. So, hiring the first product managers and information engineers and marketing people, oh my God. Yes, you have to have marketing people because there are so many events. And so, that was one thing, just you know, from people and skills.And the second thing is that it was an open-source project and a product, but what I was personally doing, I was—with the team—is bringing some product engineering practices into the open-source. So, can we say, for example, that we are going to focus on user experience this next release? And we're not going to do all the rest. And I remember, my team was like worried about, like, “Hey, what about that, and what about this, and we have—” you know, they were juggling everything together. And I remember telling them, “Imagine that everything is on the floor. All the balls are on the floor. I know they're on the floor, you know they're on the floor. It's okay. Let's just make sure that every time we pick something up, it never falls again.” And that idea is a principle that then evolved to ‘No Heroics,' and it evolved to ‘Sustainable Success.' But building things towards sustainable success is a principle which has been very helpful for us.Corey: This episode is sponsored in part by our friend at Uptycs. Attackers don't think in silos, so why would you have siloed solutions protecting cloud, containers, and laptops distinctly? Meet Uptycs - the first unified solution that prioritizes risk across your modern attack surface—all from a single platform, UI, and data model. Stop by booth 3352 at AWS re:Invent in Las Vegas to see for yourself and visit uptycs.com. That's U-P-T-Y-C-S.com. My thanks to them for sponsoring my ridiculous nonsense.Corey: When I take a look back, it's very odd to me to see the current reality that is Google, where you're talking about empathy, and the No Heroics, and the rest of that is not the reputation that Google enjoyed back when a lot of this stuff got started. It was always oh, engineers should be extraordinarily bright and gifted, and therefore it felt at the time like our customers should be as well. There was almost an arrogance built into, well, if you wrote your code more like Google will, then maybe your code wouldn't be so terrible in the cloud. And somewhat cynically I thought for a while that oh Kubernetes is Google's attempt to wind up making the rest of the world write software in a way that's more Google-y. I don't think that observation has aged very well. I think it's solved a tremendous number of problems for folks.But the complexity has absolutely been high throughout most of Kubernetes life. I would argue, on some level, that it feels like it's become successful almost in spite of that, rather than because of it. But I'm curious to get your take. Why do you believe that Kubernetes has been as successful as it clearly has?Chen: [unintelligible 00:25:34] two things. One about empathy. So yes, Google engineers are brilliant and are amazing and all great. And our customers are amazing, and brilliant, as well. And going back to the point before is, everyone has their job and where they need to be successful and we, as you say, we need to make things simpler and enable innovation. And our customers are driving innovation on top of our platform.So, that's the way I think about it. And yes, it's not as simple as it can be—probably—yet, but in studying the early days of Kubernetes, we have been investing a lot in what we call empathy, and the customer empathy workshop, for example. So, I partnered with Kelsey Hightower—and you mentioned yourself trying to start a cluster. The first time we did a workshop with my entire team, so then it was like 50 people [laugh], their task was to spin off a cluster without using any scripts that we had internally.And unfortunately, not many folks succeeded in this task. And out of that came the—what you you call it—a OKR, which was our goal for that quarter, is that you are able to spin off a cluster in three commands and troubleshoot if something goes wrong. Okay, that came out of that workshop. So, I do think that there is a lot of foundation on that empathetic engineering and the open-source of the community helped our Google teams to be more empathetic and understand what are the different use cases that they are trying to solve.And that actually bring me to why I think Kubernetes is so successful. People might be surprised, but the amount of investment we're making on orchestration or placement of containers within Kubernetes is actually pretty small. And it's been very small for the last seven years. Where do we invest time? One is, as I mentioned before, is on the what we call the API machinery.So, Kubernetes has introduced a way that is really suitable for a cloud-native technologies, the idea of reconciliation loop, meaning that the way Kubernetes is—Kubernetes is, like, a powerful automation machine, which can automate, of course, workload placement, but can automate other things. Think about it as a way of the Kubernetes API machinery is observing what is the current state, comparing it to the desired state, and working towards it. Think about, like, a thermostat, which is a different automation versus the ‘if this, then that,' where you need to anticipate different events. So, this idea about the API machinery and the way that you can extend it made it possible for different teams to use that mechanism to automate other things in that space.So, that has been one very powerful mechanism of Kubernetes. And that enabled all of innovation, even if you think about things like Istio, as an example, that's how it started, by leveraging that kind of mechanism to separate storage and so on. So, there are a lot of operators, the way people are managing their databases, or stateful workloads on top of Kubernetes, they're extending this mechanism. So, that's one thing that I think is key and built that ecosystem. The second thing, I am very proud of the community of Kubernetes.Corey: Oh, it's a phenomenal community success story.Chen: It's not easy to build a community, definitely not in open-source. I feel that the idea of values, you know, that I was talking about within my team was actually a big deal for us as we were building the community: how we treat each other, how do we help people start? You know, and we were talking before, like, am I going to talk about DEI and inclusivity, and so on. One of the things that I love about Kubernetes is that it's a new technology. There is actually—[unintelligible 00:29:39] no, even today, there is no one with ten years experience in Kubernetes. And if anyone says they have that, then they are lying.Corey: Time machine. Yes.Chen: That creates an opportunity for a lot of people to become experts in this technology. And by having it in open-source and making everything available, you can actually do it from your living room sofa. That excites me, you know, the idea that you can become an expert in this new technology and you can get involved, and you'll get people that will mentor you and help you through your first PR. And there are some roles within the community that you can start, you know, dipping your toes in the water. It's exciting. So, that makes me really happy, and I know that this community has changed the trajectory of many people's careers, which I love.Corey: I think that's probably one of the most impressive things that it's done. One last question I have for you is that we've talked a fair bit about the history and how we see it progressing through the view toward the somewhat recent past. What do you see coming in the future? What does the future of Kubernetes look like to you?Chen: Continue to be more and more boring. There is the promise of hybrid and multi-cloud, for example, is only possible by technologies like Kubernetes. So, I do think that, as a technology, it will continue to be important by ensuring portability and interoperability of workloads. I see a lot of edge use cases. If you think about it, it's like just lagging a bit around, like, innovation that we've seen in the cloud, can we bring that innovation to the edge, this will require more development within Kubernetes community as well.And that's really actually excites me. I think there's a lot of things that we're going to see there. And by the way, you've seen it also in KubeCon. I mean, there were some announcements in that space. In Google Cloud, we just announced before, like, with customers like Wendy's and Rite Aid as well. So, taking advantage of this technology to allow innovation everywhere.But beyond that, my hope is that we'll continue and hide the complexity. And our challenge will be to not make it a black box. Because that will be, in my opinion, a failure pattern, doesn't help those kinds of platforms. So, that will be the challenge. Can we scope the project, ensure that we have the right observability, and from a use case perspective, I do think edge is super interesting.Corey: I would agree. There are a lot of workloads out there that are simply never going to be hosted in the cloud provider region, for a variety of reasons of varying validity, but it is the truth. I think that the focus on addressing customers where they are has been an emerging best practice for cloud providers and I'm thrilled to see Google leading the charge on that.Chen: Yeah. And you just reminded me, the other thing that we see also more and more is definitely AI and ML workloads running on Kubernetes, which is part of that, right? So, Google Cloud is investing a lot in making an AI/ML easy. And I don't know if many people know, but, like, even Vertex AI, our own platform, is running on GKE. So, that's part of seeing how do we make sure that platform is suitable for these kinds of workloads and really help customers do the heavy lifting.So, that's another set of workloads that are very relevant at the edge. And one of our customers—MLB, for example—two things are interesting there. The first one, I think a lot of people sometimes say, “Okay, I'm going to move to the cloud and I want to know everything right now, how that will evolve.” And one of the things that's been really exciting with working with MLB for the last four years is the journey and the iterations. So, they started somewhat, like, at one phase and then they saw what's possible, and then moved to the next one, and so on. So, that's one. The other thing is that, really, they have so much ML running at the stadium with Google Cloud technology, which is very exciting.Corey: I'm looking forward to seeing how this continues to evolve and progress, particularly in light of the recent correction we're seeing in the market where a lot of hype-driven ideas are being stress test, maybe not in the way we might have hoped that they would, but it'll be really interesting to see what shakes out as far as things that deliver business value and are clear wins for customers versus a lot of the speculative stories that we've been hearing for a while now. Maybe I'm totally wrong on this. And this is going to be a temporary bump in the road, and we'll see no abatement in the ongoing excitement around so many of these emerging technologies, but I'm curious to see how it plays out. But that's the beautiful part about getting to be a pundit—or whatever it is people call me these days that's at least polite enough to say on a podcast—is that when I'm right, people think I'm a visionary, and when I'm wrong, people don't generally hold that against you. It seems like futurist is the easiest job in the world because if you predict and get it wrong, no one remembers. Predict and get it right, you look like a genius.Chen: So, first of all, I'm optimistic. So usually, my predictions are positive. I will say that, you know, what we are seeing, also what I'm hearing from our customers, technology is not for the sake of technology. Actually, nobody cares [laugh]. Even today.Okay, so nothing needs to change for, like, nobody would c—even today, nobody cares about Kubernetes. They need to care, unfortunately, but what I'm hearing from our customers is, “How do we create new experiences? How we make things easy?” Talent shortage is not just with tech people. It's also with people working in the warehouse or working in the store.Can we use technology to help inventory management? There's so many amazing things. So, when there is a real business opportunity, things are so much simpler. People have the right incentives to make it work. Because one thing we didn't talk about—right, we talked about all these new technologies and we talked about scaling team and so on—a lot of time, the challenge is not the technology.A lot of time, the challenge is the process. A lot of time, the challenge is the skills, is the culture, there's so many things. But when you have something—going back to what I said before—how you unite teams, when there's something a clear goal, a clear vision that everybody's excited about, they will make it work. So, I think this is where having a purpose for the innovation is critical for any successful project.Corey: I think and I hope that you're right. I really want to thank you for spending as much time with me as you have. If people want to learn more, where's the best place for them to find you?Chen: So, first of all, on Twitter. I'm there or on LinkedIn. I will say that I'm happy to connect with folks. Generally speaking, at some point in my career, I recognized that I have a voice that can help people, and I've experienced that can also help people build their careers. I'm happy to share that and [unintelligible 00:36:54] folks both in the company and outside of it.Corey: I think that's one of the obligations on a lot of us, once we wanted to get into a certain position or careers to send the ladder back down, for lack of a better term. It's I've never appreciated the perspective, “Well, screw everyone else. I got mine.” The whole point the next generation should have it easier than we did.Chen: Yeah, definitely.Corey: Chen Goldberg, General Manager of Cloud Runtimes and VP of Engineering at Google. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry rant of a comment talking about how LPARs on mainframes are absolutely not containers, making sure it's at least far too big to fit in a reasonably-sized Docker container.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
On the show this week, Carter Morgan and Anu Srivastava talk about AI and ML data analytics with Dataiku VP of Platform Strategy, Jed Dougherty, and Head of Product Marketing, Dan Darnell. Dataiku is an AI platform targeted for business team collaboration. The low and no code environments make it easy for developers and not so tech savvy employees to work together on analytics projects. It strives for everyday AI, making these normally highly technical data processes more accessible. Our guests detail the tools Dataiku provides customers, including ML Ops features for efficient models. Dataiku's managed offering allows businesses to concentrate on the model while Dataiku takes care of things like the deployment processes behind the scenes. We hear about the partnership between Dataiku and Google Cloud and Dataiku's integration with AlloyDB. Through a real example, our guests run us through the use of these two tools together. Jed talks about why Google Cloud works so well with Dataiku, especially for businesses looking for cutting edge technology. Jed Dougherty Jed is the VP of Platform Strategy at Dataiku. In this role he acts as a strategic technical advisor to Dataiku customers and prospects. He also works tightly with Engineering and Product stakeholders in order to ensure that all technical platform requests are properly followed, scoped and implemented. Dan Darnell Dan has over 20 years of experience in the analytics industry at established software companies, hyper-growth technology companies, and small technology start-ups. As the Head of Product Marketing at Dataiku, he owns positioning, evangelism, and content creation for product offerings and education on products for customers and partners. Cool things of the week Google Cloud supercharges NLP with large language models blog Practicing the principle of least privilege with Cloud Build and Artifact Registry blog Interview Dataiku site Dataiku YouTube videos BigQuery site Kubernetes site GKE site AlloyDB for PostgreSQL site Accelerate AI Adoption: 3 Steps to Deploy Dataiku for Google Cloud Platform blog Implementing Dataiku with BigQuery docs GCP Podcast Episode 238: ASML with Arnaud Hubaux podcast GCP Podcast Episode 229: Lucidworks with Radu Miclaus podcast What's something cool you're working on? Anu is working on interesting speech use cases and Google's Speech to Text. Join in with this tutorial! Carter is working on getting organized and working on something super cool! Hosts Carter Morgan and Anu Srivastava
Forrest Brazeal joins Stephanie Wong today on the second day of Google Cloud Next ‘22. We're talking about all the exciting announcements, how the conference has changed in recent years, and what to expect in the days ahead. The excitement and energy of the first in-person Next since 2019 was one of the best parts for Forrest. With 1300 releases in just half the year, a lot has happened in BigQuery, AI, Looker, and more. Next includes announcements in many of these areas as well, as Google Cloud expands and makes Cloud easier for all types of projects and clients. Strategic partnerships and development have allowed better use of Google Cloud for the virtual work world and advancements in sustainability have helped Google users feel better about their impact on the environment. New announcements in compute include C3 VMs, the first VM in the cloud with 4th Gen Intel Xeon scalable processors with Google's custom Intel IPU. MediaCDN uses the YouTube infrastructure and the new Live Stream API optimizes streaming capabilities. Among many other announcements, Network Analyzer is now GA allowing for simplified network configuration monitoring and Google Cloud Armor has been extended to include ML-based Adaptive Protection capabilities. Software Delivery Shield and Cloud Workstations are recent offerings to help developers in each of the four areas of software supply chain management. Advancements in Cloud Build include added security benefits, and new GKE and Cloud Run logging and security alerts ensure projects remain secure through the final stages of development. The best way to ensure secure, optimized work is with well-trained developers. And in that vein, Google Cloud is introducing Innovators Plus to provide a new suite of developer benefits under a fixed cost subscription. Forrest tells us about #GoogleClout and the challenges available in the Next portal for conference-goers. Assured Workloads helps with data sovereignty in different regions, Confidential Space in Confidential Computing provides trust guarantees when companies perform joint data analysis and machine learning training, and Chronicle Security Operations are some of the exciting security announcements we saw at Next. On the show next week, we'll go in depth on data announcements at Next, but Steph gives us a quick rundown of some of the biggest ones today. She talks briefly about announcements in AI, including Vertex AI Vision and Translation Hub. Forrest wraps up by talking about predictions for the future of tech and cloud. Forrest Brazeal Forrest Brazeal is a cloud educator, author, speaker, and Pwnie Award-winning songwriter. He is the creator of the Cloud Resume Challenge initiative, which has helped thousands of non-traditional learners take their first steps into the cloud. Cool things of the week Unlock biology & medicine potential with AlphaFold on Google Cloud video Interview Google Cloud Next ‘22 site Google Cloud Innovators site What's next for digital transformation in the cloud blog New cloud regions coming to a country near you blog The next wave of Google Cloud infrastructure innovation: New C3 VM and Hyperdisk blog 20+ Cloud Networking innovations unveiled at Google Cloud Next blog Introducing Software Delivery Shield for end-to-end software supply chain security blog Developers - Build, learn, and grow your career faster with Google Cloud blog Advancing digital sovereignty on Europe's terms blog Introducing Confidential Space to help unlock the value of secure data collaboration blog Introducing Chronicle Security Operations: Detect, investigate, and respond to cyberthreats with the speed, scale, and intelligence of Google blog What's new in Google Cloud databases: More unified. More open. More intelligent. blog Building the most open data cloud ecosystem: Unifying data across multiple sources and platforms blog Introducing the next evolution of Looker, your unified business intelligence platform blog Vertex AI Vision site New AI Agents can drive business results faster: Translation Hub, Document AI, and Contact Center AI blog Open source collaborations and key partnerships to help accelerate AI innovation blog Google Cloud Launches First-of-Its-Kind Service to Simplify Mainframe Modernization for Customers in Financial Services, Retail, Healthcare and Other Industries article Project Starline expands testing through an early access program blog What's something cool you're working on? Steph is working on the developer keynote and DevFest and UKI Google Cloud Next Developer Day. Check out her Next talk “Simplify and secure your network for all workloads”. Hosts Stephanie Wong
Betty Junod, VP of Product Marketing at VMware Tanzu, kindly took up Craig’s challenge to explain the various parts of the Tanzu ecosystem, and how the traditional IT buyer and the modern cloud native really aren’t that different. Do you have something cool to share? Some questions? Let us know: web: kubernetespodcast.com mail: kubernetespodcast@google.com twitter: @kubernetespod and @craigbox Chatter of the week NASA DART mission Deep Impact Armageddon Apparent retrograde motion Planets beyond Neptune News of the week Istio sails into the CNCF SPIFFE and SPIRE graduate Episode 45, with Andrew Jessup Brigade archived Sysdig 2022 Cloud Native threat report The nice TeamTNT Episode 188, with Kateryna Ivashchenko Episode 169, with Anna Belak Chainguard introduces Wolfi workerd, from Cloudflare Introducing Palaemon Custom org policy for GKE in preview Leveraging Kubernetes for an elastic platform at Blablacar by Sebastien Doido Links from the interview VMware History Docker Solo.io VMware Tanzu introduction blog VMware acquires Heptio VMware acquires Pivotal Tanzu Mission Control Tanzu for Kubernetes Operations Tanzu Application Platform Tanzu Kubernetes Grid Bring your own host to TKG Project Pacific introduction TKG 2.0 VMware Aria Operations for Applications Tanzu Application Service Cloud Foundry Open source projects: Velero Antrea Carvel Cartographer Michigan cider Detroit-style pizza Betty Junod on Twitter
Host Stephanie Wong chats with storage pros Sean Derrington and Nishant Kohli this week to learn more about cost optimization with storage projects and exciting new launches in the Google Cloud storage space! To start, we talk about the Storage Spotlight of years past and the cool Google Cloud products that Google is unveiling this year. Optimization is a huge theme this year, with a focus not only on cost optimization but also performance and resource use as well. Enterprise readiness and storage everywhere, Sean tells us, are the most important pillars as Google continues to improve offerings. We learn about Hyperdisk and the three customizable attributes users can control and the benefits of Filestore Enterprise for GKE for large client systems. Nishant talks about Cloud Storage and how clients are using it at scale for their huge data projects. Specifically, Google Storage has been working to help clients with large-scale data storage needs to optimize costs with Autoclass. Storage Insights is another new tool launching late this year or early next year that empowers better decision-making through increased knowledge and analytics of storage usage. GKE storage is getting a revamp as well with Backup for GKE to help clients recover applications and data easily. Google Cloud for Backup and DR helps keep projects secure as well. This managed service is easy to use and integrate into all cloud projects and can be used with on prem projects and then backed up into the cloud. This is ideal for clients as they shift to cloud or hybrid systems. Companies like Redivis take advantage of some of these new data features, and Nishant talks more about how Autoclass and other tools have helped them save money and improve their business. Sean Derrington Sean is the Group Product Manager for the storage team. He is a long time storage industry PM veteran; he's worked on Veritas, Symantec, Exablox (storage startup). Nishant Kohli Nishant has a decade plus of Object Storage experience at Dell/EMC and Hitachi. He's currently Senior Product Manager on the storage team. Cool things of the week Cloud Next 2022 site Integrating ML models into production pipelines with Dataflow blog Four non-traditional paths to a cloud career (and how to navigate them) blog Interview What's New & Next: A Spotlight on Storage site Google Cloud Online Storage Products site GCP Podcast Episode 277: Storage Launches with Brian Schwarz and Sean Derrington podcast GKE site Filestore site Filestore Enterprise site Filestore Enterprise for fully managed, fault tolerant persistent storage on GKE blog Cloud Storage site Cloud Storage Autoclass docs GCP Episode 307: FinOps with Joe Daly podcast Storage Insights docs GCP Podcast Episode 318: GKE Turns 7 with Tim Hockin podcast Backup for GKE docs Backup and DR Service site Redivis site What's something cool you're working on? Stephanie is working on new video content and two Next sessions: one teaching how to simplify and secure your network for all workloads and one talking about how our infrastructure partner ecosystem helps customers. Hosts Stephanie Wong
Tim Hockin joins Kaslin Fields and Anthony Bushong to celebrate GKE's seventh birthday! Tim starts with a brief background on GKE from its beginnings in 2015 and its relationship to Borg to the visions Google developers had for the software. GKE is meant to help companies focus on what they're good at and leave the rest to Google's managed Kubernetes service. Tim talks about his acting gig in a Kubernetes documentary, including some fun facts about Kubernetes' early days and the significance of the number seven. Over time, the teams working on open source Kubernetes and GKE have worked together, with advances in the open source software influencing updates in GKE. Kubernetes 1.25 was released the day this episode was recorded, and Tim describes how much work and thought goes into building these updates. GKE offers GCP users unique ways to leverage Kubernetes tools like scaling, and Tim shares stories about the evolution of some of these tools and his experiences with networking. Talking with the Kubernetes community has helped refine GKE mult-icluster tools to help companies solve real problems, and Tim tells us more about other features and updates coming with future iterations of GKE. KubeCon is in October, so come by and learn more! Tim Hockin Tim Hockin is Principal Software Engineer working with Kubernetes at Google Cloud. Cool things of the week What's new with Google Cloud blog Power Your Business with Modern Cloud Apps: Strategies and Best Practices site Securing apps for Googlers using Anthos Service Mesh blog Interview GKE site Kubernetes site Anthos site Borg: The Predecessor to Kubernetes blog Enabling multi-cluster Gateways docs Cloud Load Balancing site Multi-cluster Services docs Keynote: From One to Many, the Road to Multicluster- Kaslin Fields, Developer Advocate, Google Cloud video GCP Podcast Episode 272: GKE Turns Six with Anthony Bushong, Gari Singh, and Kaslin Fields podcast What's something cool you're working on? Kaslin is working on NEXT and KubeCon stuff. Anthony is working on GKE Essentials and getting ready to go on leave. Hosts Kaslin Fields and Anthony Bushong
We're learning all about Arm servers on Google Cloud Platform this week. Hosts Brian Dorsey and Stephanie Wong welcome fellow Googlers Jon Masters and Emma Haruka Iwao to talk about the newest VMs on GCP. To start, our guests dive in to Arm, explaining what it is and how it's grown over the years. Nowadays, Arm-based chips dominate the mobile market and this volume has allowed them to build both advanced chips for supercomputers and beneficial partnerships. Emma explains how having the Arm architecture available in the cloud helps keep projects efficient and walks us through example setups of an Arm projects, illustrating the ease of setup in Google Cloud. Jon and Emma talk about the T2A VMs running Arm workloads at Google, including their balance of performance and cost. Emma and Jon bust some myths about Arm, emphasizing how performant it is despite its humble beginnings. Jon Masters Jon Masters is a compute architect focused on Arm server architecture, platform standards, and ecosystem with almost a dozen years of experience working on Arm. Emma Haruka Iwao Emma Haruka Iwao is a DevRel engineer focused on Compute products and a computer architecture enthusiast. Cool things of the week Introducing Batch, a new managed service for scheduling batch jobs at any scale blog Examples of Batch for Transcoding site Using Google Kubernetes Engine's GPU sharing to search for neutrinos blog Interview Arm site Arm Documentation docs Arm VMs on Computer docs Expanding the Tau VM family with Arm-based processors blog Run your Arm workloads on Google Kubernetes Engine with Tau T2A VMs blog Compute Engine site GKE site What's something cool you're working on? Brian is switching his focus from VMs to developer tooling. Hosts Stephanie Wong and Brian Dorsey
We are BACK! after a hiatus of vacations, illness, and family gatherings, but while we may have been absent we are at no shortage of words to say and hope you enjoy our conversation about Kubernetes and the variety of flavors cloud service providers have to offer. From EKS through GKE and AKS we cover security concerns and challenges we've seen in the last few months. We talk about why teams choose to implement one of the other and how you might think about locking down your own Kubernetes instances. Through that we try to keep the humor alive and our listeners engaged!
Your hosts Max Saltonstall and Carter Morgan talk with guests Cody Ault and Jo-Anne Bourne of Veeam. Veeam is revolutionizing the data space by minimizing data loss impacts and project downtime with easy backups and user-friendly disaster recovery solutions. As a software company, Veeam is able to stay flexible with its solutions, helping customers keep any project safe. Cody explains what is meant by disaster recovery and how different systems might require different levels of fail-safe protection. Jo-Anne talks about the financial cost of downtime and how Veeam can help save money by planning for and preventing downtime. Veeam backup and replication is the main offering that can be customized depending on workloads, Cody tells us. He gives examples of how this works for different types of projects. Businesses can easily make plans for recovery and data backups then implement them with the help of Veeam. Cody talks about cloud migration and how Veeam can streamline this process with its replication services, and Jo-Anne emphasizes the importance of these recovery processes for data in the cloud. The journey from fledgling Veeam to their current suite of offerings was an interesting one, and Cody talks about this evolution, starting with the simple VM backups of version 5. As companies have brought new recovery challenges, Veeam has grown to provide these services. Their partnership with Google has grown as well, as they continue to leverage Google offerings and support Google Cloud customers. We hear examples of Veeam customers and how they use the software, and Cody tells us a little about the future of Veeam. Cody Ault Cody has been at Veeam for over 11 years in various roles and departments including Technical Lead for US Support team, Advisory Architect for Presales Solutions Architect and Staff Solutions Architect for Product Management Alliances. He has acted as the performance, databases, security, and monitoring specialist for North America for the Presales team and has helped develop the Veeam Design Methodology and Architecture Documentation template. Cody is currently working with the Alliances team focusing on Google Cloud, Kubernetes and Red Hat. Jo-Anne Bourne Jo-Anne is a Partner Marketing Strategist who works with global companies to support them in positioning company products with their customer base. She is effective in developing strategic partnerships with International Resellers, CCaaS partners, Systems Integrators, OEM partners and ISV partnerships like Amazon, Microsoft, Avaya, Cisco, Five9, BT to develop strategies to enable sales teams to generate significant revenue and in turn, build profitability for the company. Jo-Anne is a brand steward successful in using analytics to create results-driven campaigns that increase brand awareness, generate sales leads, improve customer engagement and strengthen partner relationships. Cool things of the week Announcing general availability of reCAPTCHA Enterprise password leak detection blog Cloud Podcasts site Bio-pharma organizations can now leverage the groundbreaking protein folding system, AlphaFold, with Vertex AI blog Interview Veeam site Veeam for Google Cloud site VeeamHub site Google Cloud VMware Engine site Cloud SQL site Kasten site Kubernetes site GKE site What's something cool you're working on? Carter is working on the new Cloud Podcasts website. Max is working on research papers about how we built and deployed Google's Zero Trust system for employees, BeyondCorp. Kelci is working on creating a series of blog posts highlighting the benefits of having access to public data sets embedded within BigQuery. Hosts Carter Morgan and Max Saltonstall
On The Cloud Pod this week, the team talks tactics for infiltrating the new Google Cloud center in Ohio. Plus: AWS goes sci-fi with the new Graviton3 processors, the new GKE cost estimator calculates the value of your soul, and Microsoft builds the metaverse. A big thanks to this week's sponsor, Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. This week's highlights
Stephanie Wong and Lorin Price welcome guests Zach Seils and Manasa Chalasani to talk about networking and the newly released Network Analyzer. Google Cloud's Network Intelligence Center is described as a one-stop shop that simplifies network monitoring, troubleshooting, workload expansion, security, and more. Manasa tells us about the four modules of Network Intelligence Center and how they work together. As part of Network Intelligence Center, the new Network Analyzer monitors and proactively runs tests and detects issues on the network automatically, taking the guesswork out of network troubleshooting. Network Analyzer checks the entire network ecosystem, finding any connectivity issues and extrapolating them to other similar situations as well. Zach tells us more about the specific features of Analyzer, like its ability to check for overlapping or shadowed routes and validating network configurations in relation to any managed services being used. Zach walks us through the set up of Network Analyzer and how to navigate results. Manasa expands on the development of Network Analyzer, including how customer feedback really shaped the project, and we hear about challenges along the way. Through examples, Zach describes different types of Analyzer customers and how they're using the product. More analyzers will be available soon, and the team is open to suggestions for future projects. Zach Seils Zach Seils is a Networking Specialist with Google Cloud, where he works with customers to accelerate their adoption of cloud networking. Manasa Chalasani Manasa is a Product Manager on the Google Cloud Networking team with a focus on network observability. Cool things of the week The new Google Cloud region in Columbus, Ohio is open blog Assembling and managing distributed applications using Google Cloud Networking solutions blog Interview Network Intelligence Center site Network Analyzer Documentation docs Introducing Network Analyzer: One stop shop to detect service and network issues blog CloudSQL site GKE site Cloud Monitoring site Contact the Network Analyzer team email GCP Podcast Episode 270: Traditional vs. Service Networking with Ryan Przybyl podcast What's something cool you're working on? Lorin is working on a new video series called Concepts of Networking on the Networking End to End Playlist Hosts Stephanie Wong and Lorin Price
Kaslin Fields and Mark Mirchandani learn how GKE manages their releases and how customers can take advantage of the GKE release channels for smooth transitions. Guests Abdelfettah Sghiouar and Kobi Magnezi of the Google Cloud GKE team are here to explain. With releases every four months or so, Kobi tells us that Kubernetes requires two pieces to be managed with each release: the control plane and the nodes. Both are managed for the customer in GKE. The new addition of release channels allows flexibility with release updating so customers can adjust to their specific project needs. Each channel offers a different updating mix and speed, and clients choose the channel that's right for their project. The idea for release channels isn't a new one, Kobi explains. In fact, Google's frequent project releases, while keeping things secure and running well, also can be customized by choosing from an assortment of channels in other Google offerings like Chrome. Our guests talk us through the process of releasing through channels and how each release marinates in the Rapid channel to be sure the version is supported and secure before being pushed to customers through other channels. We hear how release channels differ from no-channel releases, the benefits of specialized channels, and recommendations for customers as far as which channels to use with different development environments. Abdel describes real-world use cases for the Rapid, Regular, and Stable channels, the Surge Upgrade feature, and how GKE notifications with Pub/Sub helps in the updating process. Kobi talks about maintenance and exclusion windows to help customers further customize when and how their projects will update. Kobi and Abdel wrap up with a discussion of the future of GKE release channels. Kobi Magnezi Kobi is the Product Manager for GKE at Google Cloud. Abdelfettah Sghiouar Abdel is a Cloud Dev Advocate with a focus on Cloud native, GKE, and Service Mesh technologies. Cool things of the week GKE Essentials videos KubeCon EU 2023 site KubeCon Call for Proposals site Kubernetes 1.24: Stargazer site GCP Podcast Episode 292: Pulumi and Kubernetes Releases with Kat Cosgrove podcast Optimize and scale your startup on Google Cloud: Introducing the Build Series blog Interview Kubernetes site GKE site Autoscaling with GKE: Overview and pods video GKE release schedule dcos Release channels docs Upgrade-scope maintenance windows docs Configure cluster notifications for third-party services docs Cluster notifications docs Pub/Sub site Agones site What's something cool you're working on? Kaslin is working on KubeCon and new episodes of GKE Essentials. Hosts Mark Mirchandani and Kaslin Fields
Docker CEO Scott Johnston joins us to talk about the announcements from this week’s DockerCon, the transition from an enterprise to a developer tools company, and the Internet’s favourite whale. Do you have something cool to share? Some questions? Let us know: web: kubernetespodcast.com mail: kubernetespodcast@google.com twitter: @kubernetespod Chatter of the week Podes and antipodes Side note: Kubernetes needs the concept of an Antipod. BRB, writing a KEP Google Cloud Podcasts News of the week DockerCon 2022 Docker Extensions Docker Desktop for Linux Late breaking news: Docker acquires Nestybox Spot VMs now on GCE and GKE; spot pods now on GKE Autopilot Fully managed Linkerd with Buoyant Cloud Sign up for CDcon and save 40% by using the code CdCon22AMEET40 AWS adds Kubernetes resource view Deploying Kubernetes clusters in absurd languages by Lee Briggs Links from the interview Docker DockerCon ‘22 DockerCon ‘14, the announcement of Kubernetes Return or Revenge? Scott’s history Four degrees from Stanford, including an MSMSE Sun and Netscape Java Servlets and J2EE Moore’s Law and Metcalfe’s Law Standard on the Internet Tom Lyon Loudcloud/Opsware and a16z Puppet Scott joins Docker in 2014 The monorepo The Soul of a New Machine Docker Swarm Messages from the future and the Google crystal ball Open Cotainers Initiative Docker Desktop for Apple Silicon Macs virtiofs for Mac $2.1 billion valuation Moby Project Moby Ice Cube The Dockershim saga, as reported throughout the episodes: Don’t panic about Docker Dockershim deprecation FAQ Mirantis will support the Dockershim But seriously, don’t worry about the Dockershim Dockershim is, like, proper gone The puns and joke section Docker is krilled to see you Billy T James Beached Az. Can’t eat chups! Docker Extensions CNCF Landscape or Magic Eye? Docker Desktop for Linux Multi-arch on Docker Hub Docker roadmap Scott Johnston on Twitter
Hosts Anthony Bushong and Kaslin Fields welcome Bowei Du and Abdelfettah Sghiouar to talk about the Gateway Controller, a tool that helps developers use the Gateway API in GKE. Bowei starts the show with a thorough explanation of how and why the Gateway Controller was developed. Compared to tools like Ingress, Gateway Controller allows engineers to implement more expressive solutions. While providing developers with portability has been an important part of Gateway Controller, it also gives developers freedom to use non-portable features in a structured, consistent environment and helps manage tenancy across different teams. Bowei and Abdel describe the difference between Ingress and Service and how these tools fit in with Gateway Controller. Abdel walks us through how a company would use the Gateway Controller for optimal tenancy management across name spaces and how this is an improvement over Ingress and Service. He gives examples of how companies are using this new tool. We hear more about the GKE Gateway Controller and how its fully-managed deployments and integration with other Google APIs make it so easy to use. Bowei tells us how Gateway helps with the unification of mesh and non mesh environments through the standardization of noun describers in both instances. A handy edge to mesh tutorial is available to help developers. Abdelfettah Sghiouar Abdel is a Cloud Dev Advocate with a focus on Cloud native, GKE, and Service Mesh technologies. Bowei Du Bowei is tech lead on Gateway Controller and a specialist in distributed systems and networking. Cool things of the week Strengthening your DevOps muscle site Interview Kubernetes site GKE site GKE Gateway API docs Kubernetes Gateway API site Ingress docs Service docs From edge to mesh: Exposing service mesh applications through GKE Ingress docs Google Cloud Armor site Kubernetes Slack site Slack channel: #sig-network-gateway-api GKE Networking Recipes GitHub repo site The evolution of Kubernetes networking with the GKE Gateway controller blog What's something cool you're working on? Kaslin is working on KubeCon EU. Anthony is working on software supply chain security with Cloud Build. Kaslin and Anthony are working together on the GKE Essentials Series Hosts Anthony Bushong and Kaslin Fields
This week, Stephanie Wong and Anthony Bushong introduce a special podcast of the Gtalk at Airbus speaker series where prestigious Googlers have been invited to talk with Airbus. In this episode, Vint Cerf, who is widely regarded as one of the fathers of the Internet, talks with Rhys Phillips of Airbus and fellow Googler Rafael Lami Dozo. Vint tells us about his journey to Google, including his interest in science which stemmed from a chemistry set he received as a child. After high school, he got a job writing data analyzation software on the Apollo project. His graduate work at UCLA led him to the ARPANet project where he developed host protocols, and eventually to his work on the original Internet with Bob Kahn. Vint tells us about the security surrounding this project and the importance of internet security still today. The open architecture of the internet then and now excites Vint because it allows new, interesting projects to contribute without barriers. Vint is also passionate about accessibility. At Google, he and his team continue to make systems more accessible by listening to clients and adapting software to make it usable. He sees an opportunity to train developers to optimize software to work with common accessibility tools like screen readers to ensure better usability. Later, Vint tells us about the Interplanetary Internet, describing how this system is being built to provide fast, effective Internet to every part of the planet. Along with groups like the Internet Engineering Task Force, this new Internet is being deployed and tested now to ensure it works as expected. He talks about his work with NASA and other space agencies to grow the Interplanetary Internet. Digital obsolescence is another type of accessibility that concerns Vint. Over time, the loads of data we store and their various storage devices could become unreadable. Software needed to use or see this media could no longer be supported as well, making the data inaccessible. Vint hopes we will begin practicing ways to perpetuate the existence of this data through copying and making software more backward compatible. He addresses the issues with this, including funding. Vint Cerf While at UCLA, Vint Cerf worked on ARPANet - the very beginnings of what we know as the internet today and is now, fittingly, Chief Internet Evangelist & VP at Google. He is an American Internet pioneer and is recognized as one of “the fathers of the Internet”, sharing this title with TCP/IP co-developer Bob Kahn. Rhys Phillips Rhys Phillips is Change and Adoption Leader, Digital Workplace at Airbus. Rafael Lami Dozo Rafael Lami Dozo is Customer Success Manager, Google Cloud Workspace for Airbus. Cool things of the week Celebrating Pi Day with Cloud Functions blog Apollo Scales GraphQL Platform using GKE blog Interview Vinton G. Cerf Profile site ARPANet on Wikipedia site To Boldly Go Where No Internet Protocol Has Gone Before article Building the backbone of an interplanetary internet video IETF site CCSDS site IPNSIG site The Internet Society site NASA site What's something cool you're working on? Stephanie is working on new Discovering Data Centers videos. Anthony is working on content for building scalable GKE clusters. Hosts Stephanie Wong and Anthony Bushong
About LizLiz Rice is Chief Open Source Officer with cloud native networking and security specialists Isovalent, creators of the Cilium eBPF-based networking project. She is chair of the CNCF's Technical Oversight Committee, and was Co-Chair of KubeCon + CloudNativeCon in 2018. She is also the author of Container Security, published by O'Reilly.She has a wealth of software development, team, and product management experience from working on network protocols and distributed systems, and in digital technology sectors such as VOD, music, and VoIP. When not writing code, or talking about it, Liz loves riding bikes in places with better weather than her native London, and competing in virtual races on Zwift.Links: Isovalent: https://isovalent.com/ Container Security: https://www.amazon.com/Container-Security-Fundamental-Containerized-Applications/dp/1492056707/ Twitter: https://twitter.com/lizrice GitHub: https://github.com/lizrice Cilium and eBPF Slack: http://slack.cilium.io/ CNCF Slack: https://cloud-native.slack.com/join/shared_invite/zt-11yzivnzq-hs12vUAYFZmnqE3r7ILz9A 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: Today's episode is brought to you in part by our friends at MinIO the high-performance Kubernetes native object store that's built for the multi-cloud, creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you're defining those as, which depends probably on where you work. It's getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere, and that's exactly what MinIO offers. With superb read speeds in excess of 360 gigs and 100 megabyte binary that doesn't eat all the data you've gotten on the system, it's exactly what you've been looking for. Check it out today at min.io/download, and see for yourself. That's min.io/download, and be sure to tell them that I sent you.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the interesting things about hanging out in the cloud ecosystem as long as I have and as, I guess, closely tied to Amazon as I have been, is that you learned that you never quite are able to pronounce things the way that people pronounce them internally. In-house pronunciations are always a thing. My guest today is Liz Rice, the Chief Open Source Officer at Isovalent, and they're responsible for, among other things, the Cilium open-source project, which is around eBPF, which I can only assume is internally pronounced as ‘Ehbehpf'. Liz, thank you for joining me today and suffering my pronunciation slings and arrows.Liz: I have never heard ‘Ehbehpf' before, but I may have to adopt it. That's great.Corey: You also are currently—in a term that is winding down if I'm not misunderstanding—you were the co-chair of KubeCon and CloudNativeCon at the CNCF, and you are also currently on the technical oversight committee for the foundation.Liz: Yeah, yeah. I'm currently the chair, in fact, of the technical oversight committee.Corey: And now that Amazon has joined, I assumed that they had taken their horrible pronunciation habits, like calling AMIs ‘Ah-mies' and whatnot, and started spreading them throughout the ecosystem with wild abandon.Liz: Are we going to have to start calling CNCF ‘Ka'Nff' or something?Corey: Exactly. They're very frugal, by which I mean they never buy a vowel. So yeah, it tends to be an ongoing challenge. Joking and all the rest aside, let's start, I guess, at the macro view. The CNCF does an awful lot of stuff, where if you look at the CNCF landscape, for example, like, I think some of my jokes on the internet go a bit too far, but you look at this thing and last time I checked, there were something like four or 500 different players in various spaces.And it's a very useful diagram, don't get me wrong by any stretch of the imagination, but it also is one of those things that is so staggeringly vast that I've got a level with you on this one, given my old, ancient sysadmin roots, “The hell with it. I'm going to run some VMs in a three-tiered architecture just like grandma and grandpa used to do,” and call it good. Not really how the industry is evolved, but it's overwhelming.Liz: But that might be the right solution for your use case so, you know, don't knock it if it works.Corey: Oh, yeah. If it's a terrible architecture and it works, is it really that terrible of an architecture? One wonders.Liz: Yeah, yeah. I mean, I'm definitely not one of those people who thinks, you know, every solution has the same—you know, is solved by the same hammer, you know, all problems are not the same nail. So, I am a big fan of a lot of the CNCF projects, but that doesn't mean to say I think those are the only ways to deploy software. You know, there are plenty of things like Lambda are a really great example of something that is super useful and very applicable for lots of applications and for lots of development teams. Not necessarily the right solution for everything. And for other people, they need all the bells and whistles that something like Kubernetes gives them. You know, horses for courses.Corey: It's very easy for me to make fun of just about any company or service or product, but the thing that always makes me set that aside and get down to brass tacks has been, “Okay, great. You can build whatever you want. You can tell whatever glorious marketing narrative you wish to craft, but let's talk to a real customer because once we do that, then if you're solving a problem that someone is having in the wild, okay, now it's no longer just this theoretical exercise and PowerPoint. Now, let's actually figure out how things work when the rubber meets the road.”So, let's start, I guess, with… I'll leave it to you. Isovalent are the creators of the Cilium eBPF-based networking project.Liz: Yeah.Corey: And eBPF is the part of that I think I'm the most familiar with having heard the term. Would you rather start on the company side or on the eBPF side?Liz: Oh, I don't mind. Let's—why don't we start with eBPF? Yeah.Corey: Cool. So easy, ridiculous question. I know that it's extremely important because Brendan Gregg periodically gets on stage and tells amazing stories about this; the last time he did stuff like that, I went stumbling down into the rabbit hole of DTrace, and I have never fully regretted doing that, nor completely forgiven him. What is eBPF?Liz: So, it stands for extended Berkeley Packet Filter, and we can pretty much just throw away those words because it's not terribly helpful. What eBPF allows you to do is to run custom programs inside the kernel. So, we can trigger these programs to run, maybe because a network packet arrived, or because a particular function within the kernel has been called, or a tracepoint has been hit. There are tons of places you can attach these programs to, or events you can attach programs to.And when that event happens, you can run your custom code. And that can change the behavior of the kernel, which is, you know, great power and great responsibility, but incredibly powerful. So Brendan, for example, has done a ton of really great pioneering work showing how you can attach these eBPF programs to events, use that to collect metrics, and lo and behold, you have amazing visibility into what's happening in your system. And he's built tons of different tools for observing everything from, I don't know, memory use to file opens to—there's just endless, dozens and dozens of tools that Brendan, I think, was probably the first to build. And now this sort of new generations of eBPF-based tooling that are kind of taking that legacy, turning them into maybe more, going to say user-friendly interfaces, you know, with GUIs, and hooking them up to metrics platforms, and in the case of Cilium, using it for networking and hooking it into Kubernetes identities, and making the information about network flows meaningful in the context of Kubernetes, where things like IP addresses are ephemeral and not very useful for very long; I mean, they just change at any moment.Corey: I guess I'm trying to figure out what part of the stack this winds up applying to because you talk about, at least to my mind, it sounds like a few different levels all at once: You talk about running code inside of the kernel, which is really close to the hardware—it's oh, great. It's adventures in assembly is almost what I'm hearing here—but then you also talk about using this with GUIs, for example, and operating on individual packets to run custom programs. When you talk about running custom programs, are we talking things that are a bit closer to, “Oh, modify this one field of that packet and then call it good,” or are you talking, “Now, we launch Microsoft Word.”Liz: Much more the former category. So yeah, let's inspect this packet and maybe change it a bit, or send it to a different—you know, maybe it was going to go to one interface, but we're going to send it to a different interface; maybe we're going to modify that packet; maybe we're going to throw the packet on the floor because we don't—there's really great security use cases for inspecting packets and saying, “This is a bad packet, I do not want to see this packet, I'm just going to discard it.” And there's some, what they call ‘Packet of Death' vulnerabilities that have been mitigated in that way. And the real beauty of it is you just load these programs dynamically. So, you can change the kernel or on the fly and affect that behavior, just immediately have an effect.If there are processes already running, they get instrumented immediately. So, maybe you run a BPF program to spot when a file is opened. New processes, existing processes, containerized processes, it doesn't matter; they'll all be detected by your program if it's observing file open events.Corey: Is this primarily used from a security perspective? Is it used for—what are the common use cases for something like this?Liz: There's three main buckets, I would say: Networking, observability, and security. And in Cilium, we're kind of involved in some aspects of all those three things, and there are plenty of other projects that are also focusing on one or other of those aspects.Corey: This is where when, I guess, the challenge I run into the whole CNCF landscape is, it's like, I think the danger is when I started down this path that I'm on now, I realized that, “Oh, I have to learn what all the different AWS services do.” This was widely regarded as a mistake. They are not Pokémon; I do not need to catch them all. The CNCF landscape applies very similarly in that respect. What is the real-world problem space for which eBPF and/or things like Cilium that leverage eBPF—because eBPF does sound fairly low-level—that turn this into something that solves a problem people have? In other words, what is the problem that Cilium should be the go-to answer for when someone says, “I have this thing that hurts.”Liz: So, at one level, Cilium is a networking solution. So, it's Kubernetes CNI. You plug it in to provide connectivity between your applications that are running in pods. Those pods have to talk to each other somehow and Cilium will connect those pods together for you in a very efficient way. One of the really interesting things about eBPF and networking is we can bypass some of the networking stack.So, if we are running in containers, we're running our applications in containers in pods, and those pods usually will have their own networking namespace. And that means they've got their own networking stack. So, a packet that arrives on your machine has to go through the networking stack on that host machine, go across a virtual interface into your pod, and then go through the networking stack in that pod. And that's kind of inefficient. But with eBPF, we can look at the packet the moment it's come into the kernel—in fact in some cases, if you have the right networking interfaces, you can do it while it's still on the network interface card—so you look at that packet and say, “Well, I know what pod that's destined for, I can just send it straight there.” I don't have to go through the whole networking stack in the kernel because I already know exactly where it's going. And that has some real performance improvements.Corey: That makes sense. In my explorations—we'll call it—with Kubernetes, it feels like the universe—at least at the time I went looking into it—was, “Step One, here's how to wind up launching Kubernetes to run a blog.” Which is a bit like using a chainsaw to wind up cutting a sandwich. Okay, massively overpowered but I get the basic idea, like, “Okay, what's project Step Two?” It's like, “Oh, great. Go build Google.”Liz: [laugh].Corey: Okay, great. It feels like there's some intermediary steps that have been sort of glossed over here. And at the small-scale that I kicked the tires on, things like networking performance never even entered the equation; it was more about get the thing up and running. But yeah, at scale, when you start seeing huge numbers of containers being orchestrated across a wide variety of hosts that has serious repercussions and explains an awful lot. Is this the sort of thing that gets leveraged by cloud providers themselves, is it something that gets built in mostly on-prem environments, or is it something that rides in, almost, user-land for most of these use cases that customers coming to bringing to those environments? I'm sorry, users, not customers. I'm too used to the Amazonian phrasing of everyone as a customer. No, no, they are users in an open-source project.Liz: [laugh]. Yeah, so if you're using GKE, the GKE Dataplane V2 is using Cilium. Alibaba Cloud uses Cilium. AWS is using Cilium for EKS Anywhere. So, these are really, I think, great signals that it's super scalable.And it's also not just about the connectivity, but also about being able to see your network flows and debug them. Because, like you say, that day one, your blog is up and running, and day two, you've got some DNS issue that you need to debug, and how are you going to do that? And because Cilium is working with Kubernetes, so it knows about the individual pods, and it's aware of the IP addresses for those pods, and it can map those to, you know, what's the pod, what service is that pod involved with. And we have a component of Cilium called Hubble that gives you the flows, the network flows, between services. So, you know, we've probably all seen diagrams showing Service A talking to Service B, Service C, some external connectivity, and Hubble can show you those flows between services and the outside world, regardless of how the IP addresses may be changing underneath you, and aggregating network flows into those services that make sense to a human who's looking at a Kubernetes deployment.Corey: A running gag that I've had is that one of the drawbacks and appeals of Kubernetes, all at once, is that it lets you cosplay as a cloud provider, even if you don't happen to work for one of them. And there's a bit of truth to it, but let's be serious here, despite what a lot of the cloud providers would wish us to believe via a bunch of marketing, there's a tremendous number of data center environments out there, hybrid environments, and companies that are in those environments are not somehow laggards, or left behind technologically, or struggling to digitally transform. Believe it or not—I know it's not a common narrative—but large companies generally don't employ people who lack critical thinking skills and strategic insight. There's usually a reason that things are the way that they are and when you don't understand that my default approach is that, oh context that gets missing, so I want to preface this with the idea there is nothing wrong in those environments. But in a purely cloud-native environment—which means that I'm very proud about having no single points of failure as I have everything routing to a single credit card that pays the cloud providers—great. What is the story for Cilium if I'm using, effectively, the managed Kubernetes options that Name Any Cloud Provider will provide for me these days? Is it at that point no longer for me or is it something that instead expresses itself in ways I'm not seeing, yet?Liz: Yeah, so I think, as an open-source project—and it is the only CNI that's at incubation level or beyond, so you know, it's CNCF-supported networking solution; you can use it out of the box, you can use it for your tiny blog application if you've decided to run that on Kubernetes, you can do so—things start to get much more interesting at scale. I mean, that… continuum between you know, there are people purely on managed services, there are people who are purely in the cloud, hybrid cloud is a real thing, and there are plenty of businesses who have good reasons to have some things in their own data centers, something's in the public cloud, things distributed around the world, so they need connectivity between those. And Cilium will solve a lot of those problems for you in the open-source, but also, if you're telco scale and you have things like BGP networks between your data centers, then that's where the paid versions of Cilium, the enterprise versions of Cilium, can help you out. And, as Isovalent, that's our business model to have, like—we fully support or we contribute a lot of resources into the open-source Cilium, and we want that to be the best networking solution for anybody, but if you are an enterprise who wants those extra bells and whistles, and the kind of scale that, you know, a telco, or a massive retailer, or a large media organization, or name your vertical, then we have solutions for that as well. And I think it was one of the really interesting things about the eBPF side of it is that, you know, we're not bound to just Kubernetes, you know? We run in the kernel, and it just so happens that we have that Kubernetes interface for allocating IP addresses to endpoints that happened to be pods. But—Corey: So, back to my crappy pile of VMs—because the hell with all this newfangled container nonsense—I can still benefit from something like Cilium?Liz: Exactly, yeah. And there's plenty of people using it for just load-balancing, which, why not have an eBPF-based high-performance load balancer?Corey: Hang on, that's taking me a second to work my way through. What is the programming language for eBPF? It is something custom?Liz: Right. So, when you load your BPF program into the kernel, it's in the form of eBPF bytecode. There are people who write an eBPF bytecode by hand; I am not one of those people.Corey: There are people who used to be able to write Sendmail configs without running through the M four preprocessor, and I don't understand those people either.Liz: [laugh]. So, our choices are—well, it has to be a language that can be compiled into that bytecode, and at the moment, there are two options: C, and more recently, Rust. So, the C code, I'm much more familiar with writing BPF code in C, it's slightly limited. So, because these BPF programs have to be safe to run, they go through a verification process which checks that you're not going to crash the kernel, that you're not going to end up in some hardware loop, and basically make your machine completely unresponsive, we also have to know that BPF programs, you know, they'll only access memory that they're supposed to and that they can't mess up other processes. So, there's this BPF verification step that checks for example that you always check that a pointer isn't nil before you dereference it.And if you try and use a pointer in your C code, it might compile perfectly, but when you come to load it into the kernel, it gets rejected because you forgot to check that it was non-null before.Corey: You try and run it, the whole thing segfaults, you see the word ‘fault' there and well, I guess blameless just went out the window there.Liz: [laugh]. Well, this is the thing: You cannot segfault in the kernel, you know, or at least that's a bad [day 00:19:11]. [laugh].Corey: You say that, but I'm very bad with computers, let's be clear here. There's always a way to misuse things horribly enough.Liz: It's a challenge. It's pretty easy to segfault if you're writing a kernel module. But maybe we should put that out as a challenge for the listener, to try to write something that crashes the kernel from within an eBPF because there's a lot of very smart people.Corey: Right now the blood just drained from anyone who's listening, in the kernel space or the InfoSec space, I imagine.Liz: Exactly. Some of my colleagues at Isovalent are thinking, “Oh, no. What's she brought on here?” [laugh].Corey: What have you done? Please correct me if I'm misunderstanding this. So, eBPF is a very low-level tool that requires certain amounts of braining in order [laugh] to use appropriately. That can be a heavy lift for a lot of us who don't live in those spaces. Cilium distills this down into something that is all a lot more usable and understandable for folks, and then beyond that, you wind up with Isovalent, that winds up effectively productizing and packaging this into something that becomes a lot more closer to turnkey. Is that directionally accurate?Liz: Yes, I would say that's true. And there are also some other intermediate steps, like the CLI tools that Brendan Gregg did, where you can—I mean, a CLI is still fairly low-level, but it's not as low-level as writing the eBPF code yourself. And you can be quite in-dep—you know, if you know what things you want to observe in the kernel, you don't necessarily have to know how to write the eBPF code to do it, but if you've got these fairly low-level tools to do it. You're absolutely right that very few people will need to write their own… BPF code to run in the kernel.Corey: Let's move below the surface level of awareness; the same way that most of us don't need to know how to compile our own kernel in this day and age.Liz: Exactly.Corey: A few people very much do, but because of their hard work, the rest of us do not.Liz: Exactly. And for most of us, we just take the kernel for granted. You know, most people writing applications, it doesn't really matter if—they're just using abstractions that do things like open files for them, or create network connections, or write messages to the screen, you don't need to know exactly how that's accomplished through the kernel. Unless you want to get into the details of how to observe it with eBPF or something like that.Corey: I'm much happier not knowing some of the details. I did a deep dive once into Linux system kernel internals, based on an incredibly well-written but also obnoxiously slash suspiciously thick O'Reilly book, Linux Systems Internalsand it was one of those, like, halfway through, “Can I please be excused? My brain is full.” It's one of those things that I don't use most of it on a day-to-day basis, but it's solidified by understanding of what the computer is actually doing in a way that I will always be grateful for.Liz: Mmm, and there are tens of millions of lines of code in the Linux kernel, so anyone who can internalize any of that is basically a superhero. [laugh].Corey: I have nothing but respect for people who can pull that off.Corey: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.In your day job, quote-unquote—which is sort of a weird thing to say, given that you are working at an open-source company; in fact, you are the Chief Open Source Officer, so what you're doing in the community, what you're exploring on the open-source project side of things, it is all interrelated. I tend to have trouble myself figuring out where my job starts and stops most weeks; I'm sympathetic to it. What inspired you folks to launch a company that is, “Ah, we're going to be in the open-source space?” Especially during a time when there's been a lot of pushback, in some respects, about the evolution of open-source and the rise of large cloud providers, where is open-source a viable strategy or a tactic to get to an outcome that is pleasing for all parties?Liz: Mmm. So, I wasn't there at the beginning, for the Isovalent journey, and Cilium has been around for five or six years, now, at this point. I very strongly believe in open-source as an effective way of developing technology—good technology—and getting really good feedback and, kind of, optimizing the speed at which you can innovate. But I think it's very important that businesses don't think—if you're giving away your code, you cannot also sell your code; you have to have some other thing that adds value. Maybe that's some extra code, like in the Isovalent example, the enterprise-related enhancements that we have that aren't part of the open-source distribution.There's plenty of other ways that people can add value to open-source. They can do training, they can do managed services, there's all sorts of different—support was the classic example. But I think it's extremely important that businesses don't just expect that I can write a bunch of open-source code, and somehow magically, through building up a whole load of users, I will find a way to monetize that.Corey: A bunch of nerds will build my product for me on nights and weekends. Yeah, that's a bit of an outmoded way of thinking about these things.Liz: Yeah exactly. And I think it's not like everybody has perfect ability to predict the future and you might start a business—Corey: And I have a lot of sympathy for companies who originally started with the idea of, “Well, we are the project leads. We know this code the best, therefore we are the best people in the world to run this as a service.” The rise of the hyperscale cloud providers has called that into significant question. And I feel for them because it's difficult to completely pivot your business model when you're already a publicly-traded company. That's a very fraught and challenging thing to do. It means that you're left with a bunch of options, none of them great.Cilium as a project is not that old, neither is Isovalent, but it's new enough in the iterative process, that you were able to avoid that particular pitfall. Instead, you're looking at some level of making this understandable and useful to humans, almost the point where it disappears from their level of awareness that they need to think about. There's huge value in something like that. Do you think that there is a future in which projects and companies built upon projects that follow this model are similarly going to be having challenges with hyperscale cloud providers, or other emergent threats to the ecosystem—sorry, ‘threat' is an unfair and unkind word here—but changes to the ecosystem, as we see the world evolving in ways that most of us did not foresee?Liz: Yeah, we've certainly seen some examples in the last year or two, I guess, of companies that maybe didn't anticipate, and who necessarily has a crystal ball to anticipate how cloud providers might use their software? And I think in some cases, the cloud providers has not always been the most generous or most community-minded in their approach to how they've done that. But I think for a company, like Isovalent, our strong point is talent. It would be extremely rare to find the level of expertise in, you know, what is a pretty specialized area. You know, the people at Isovalent who are working on Cilium are also working on eBPF itself, and that level of expertise is, I think, pretty unrivaled.So, we're in such a new space with eBPF, we've only in the last year or so, got to the point where pretty much everyone is running a kernel that's new enough to use eBPF. Startups do have a kind of agility that I think gives them an advantage, which I hope we'll be able to capitalize on. I think sometimes when businesses get upset about their code being used, they probably could have anticipated it. You know, if it's open-source, people will use your software, and you have to think of that.Corey: “What do you mean you're using the thing we gave away for free and you're not paying us to use it?”Liz: Yeah.Corey: “Uh, did you hear what you just said?” Some of this was predictable, let's be fair.Liz: Yeah, and I think you really have to, as a responsible business, think about, well, what does happen if they use all the open-source code? You know, is that a problem? And as far as we're concerned, everybody using Cilium is a fantastic… thing. We fully welcome everyone using Cilium as their data plane because the vast majority of them would use that open-source code, and that would be great, but there will be people who need that extra features and the expertise that I think we're in a unique position to provide. So, I joined Isovalent just about a year ago, and I did that because I believe in the technology, I believe in the company, I believe in, you know, the foundations that it has in open-source.It's a very much an open-source first organization, which I love, and that resonates with me and how I think we can be successful. So, you know, I don't have that crystal ball. I hope I'm right, we'll find out. We should do this again, you know, a couple of years and see how that's panning out. [laugh].Corey: I'll book out the date now.Liz: [laugh].Corey: Looking back at our conversation just now, you talked about open-source, and business strategy and how that's going to be evolving. We talked about the company, we talked about an incredibly in-depth, technical product that honestly goes significantly beyond my current level of technical awareness. And at no point in any of those aspects of the conversation did you talk about it in a way that I did not understand, nor did you come off in any way as condescending. In fact, you wrote an O'Reilly book on Container Security that's written very much the same way. How did you learn to do that? Because it is, frankly, an incredibly rare skill.Liz: Oh, thank you. Yeah, I think I have never been a fan of jargon. I've never liked it when people use a complicated acronym, or really early days in my career, there was a bit of a running joke about how everything was TLAs. And you think, well, I understand why we use an acronym to shorten things, but I don't think we need to assume that everybody knows what everything stands for. Why can't we explain things in simple language? Why can't we just use ordinary terms?And I found that really resonates. You know, if I'm doing a presentation or if I'm writing something, using straightforward language and explaining things, making sure that people understand the, kind of, fundamentals that I'm going to build my explanation on. I just think that has a—it results in people understanding, and that's my whole point. I'm not trying to explain something to—you know, my goal is that they understand it, not that they've been blown away by some kind of magic. I want them to go away going, “Ah, now I understand how this bit fits with that bit,” or, “How this works.” You know?Corey: The reason I bring it up is that it's an incredibly undervalued skill because when people see it, they don't often recognize it for what it is. Because when people don't have that skill—which is common—people just write it off as oh, that person's a bad communicator. Which I think is a little unfair. Being able to explain complex things simply is one of the most valuable yet undervalued skills that I've found in this entire space.Liz: Yeah, I think people sometimes have this sort of wrong idea that vocabulary and complicated terms are somehow inherently smarter. And if you use complicated words, you sound smarter. And I just don't think that's accessible, and I don't think it's true. And sometimes I find myself listening to someone, and they're using complicated terms or analogies that are really obscure, and I'm thinking, but could you explain that to me in words of one syllable? I don't think you could. I think you're… hiding—not you [laugh]. You know, people—Corey: Yeah. No, no, that's fair. I'll take the accusation as [unintelligible 00:31:24] as I can get it.Liz: [laugh]. But I think people hide behind complex words because they don't really understand them sometimes. And yeah, I would rather people understood what I'm saying.Corey: To me—I've done it through conference talks, but the way I generally learn things is by building something with them. But the way I really learn to understand something is I give a conference talk on it because, okay, great. I can now explain Git—which was one of my early technical talks—to folks who built Git. Great. Now, how about I explain it to someone who is not immersed in the space whatsoever? And if I can make it that accessible, great, then I've succeeded. It's a lot harder than it looks.Liz: Yeah, exactly. And one of the reasons why I enjoy building a talk is because I know I've got a pretty good understanding of this, but by the time I've got this talk nailed, I will know this. I might have forgotten it in six months time, you know, but [laugh] while I'm giving that talk, I will have a really good understanding of that because the way I want to put together a talk, I don't want to put anything in a talk that I don't feel I could explain. And that means I have to understand how it works.Corey: It's funny, this whole don't give talks about things you don't understand seems like there's really a nouveau concept, but here we are, we're [working on it 00:32:40].Liz: I mean, I have committed to doing talks that I don't fully understand, knowing that—you know, with the confidence that I can find out between now and the [crosstalk 00:32:48]—Corey: I believe that's called a forcing function.Liz: Yes. [laugh].Corey: It's one of those very high-risk stories, like, “Either I'm going to learn this in the next three months, or else I am going to have some serious egg on my face.”Liz: Yeah, exactly, definitely a forcing function. [laugh].Corey: I really want to thank you for taking so much time to speak with me today. If people want to learn more, where can they find you?Liz: So, I am online pretty much everywhere as lizrice, and I am on Twitter. I'm on GitHub. And if you want to come and hang out, I am on the Cilium and eBPF Slack, and also the CNCF Slack. Yeah. So, come say hello.Corey: There. We will put links to all of that in the [show notes 00:33:28]. Thank you so much for your time. I appreciate it.Liz: Pleasure.Corey: Liz Rice, Chief Open Source Officer at Isovalent. 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 containing an eBPF program that on every packet fires off a Lambda function. Yes, it will be extortionately expensive; almost half as much money as a Managed NAT Gateway.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
![Engenharia de Dados [Cast]](https://ivyfm.s3.amazonaws.com/i320/1212346.jpg)
Os produtos de Big Data open-source são os mais utilizados pelas médias e grandes empresas para operacionalizar processos de análise de dados em grande escala para todas as áreas e departamentos de uma empresa.Porém, depender de um provedor de nuvem para essa tarefa pode te trazer alguns problemas a longo prazo, principalmente pelo "lock-in" e custos elevados dos produtos de modalidade PaaS e SaaS de fato, a maioria das empresas compreende porque produtos open-source são os mais utilizados do mundo.A terceira geração de Big Data nasce para endereçar esses problemas, agora é possível criar uma infraestrutura "self-healing" e de baixo custo para operacionalizar os produtos mais utilizados de Big Data do mundo. As provedoras de nuvem oferecem Kubernetes gerenciados (AKS, GKE e EKS) para que você possa focar no que é mais importante para o negócio e ao mesmo tempo permanecer e colaborar no mesmo tipo de ambiente. Luan Moreno = https://www.linkedin.com/in/luanmoreno/
© 2020-2025 Ivy Podcast Discovery LLC
