DevOps Paradox

#343: Here's the thing about your company's APIs -- they were built for your own engineers to use inside your own software. Nobody designed them to be the front door. But that's exactly what's happening. Matt DeBergalis, CEO of Apollo GraphQL, makes a pretty compelling case that AI agents are turning internal APIs into the actual interface between companies and customers. Not the website. The APIs themselves. And most of them aren't ready for that. At all. Think about what happens when you point a model at a typical REST API. GitHub's API returns hundreds of fields for a single repository object. Fine when another service is calling it. But a model? All those extra fields are context you're paying for, and they make the model hallucinate. Matt says you need something between the model and all those backend services -- an orchestration layer that takes one request and handles the mess underneath. That's where GraphQL comes in. He draws a parallel that'll land immediately if you've been in this space a while. APIs right now are pets -- handwritten, named, carefully managed. But AI-generated code is about to produce way more microservices, which means way more APIs. They're going to become cattle. And just like containers needed Kubernetes, APIs are going to need declarative infrastructure to manage them at scale. The conversation takes an interesting turn when Darin pushes back on the idea that developers are becoming architects. His take: we're becoming product managers. Matt says both. Viktor throws in code reviewers. Matt's own story backs it up -- he codes more as CEO than he did as CTO, because AI handles the parts he never had time to learn. He doesn't know modern React. Doesn't need to. One more thing that should make any tech company uncomfortable: if AI agents are how customers find you now, what happens to your docs-page-driven acquisition funnel? Apollo's already made the shift -- their first audience for documentation is the models, not the humans. Matt's contact information: LinkedIn: https://www.linkedin.com/in/debergalis/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#342: Most companies have plenty of documentation. The problem is almost none of it is findable, current, or true. Between what's documented, what's actually true, and what people actually do, there are gaps wide enough to kill any AI initiative before it starts. Viktor makes a distinction that reframes the whole problem: there are two types of documentation. Why something was done -- that's eternal. How something works -- that's outdated the moment someone changes a config and forgets to update the wiki. The information about that change probably exists somewhere -- in a Zoom recording, a Slack thread, somebody's head -- but it's not where anyone would think to look for it. The running system itself is the most accurate documentation any company has. Your Kubernetes cluster tells you how many pods are running right now. Git tells you how many you wished you had. Those aren't the same thing, and pretending Git is the source of truth is a comfortable lie most teams tell themselves daily. RAG won't save this. Not the way most people imagine it -- point an agent at your docs and let it answer questions. That fails for the same reason Google's old enterprise search appliance failed. What could work is a continuous process that watches every information source, extracts what matters, and updates a central location intelligently. We have the pieces for this. Nobody's built it yet. The practical path forward: audit what you have before building anything new. Instrument your documentation the way you instrument applications -- find out what people search for and can't find. Design for retrieval, not storage. Build feedback loops. And stop treating documentation as a project with an end date. The companies that treat this as a strategic advantage instead of a chore are the ones that will actually make AI work for them. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#341: Nobody's arguing about whether you need feature flags in 2026. That debate ended years ago. But the code flowing through those flags? That's a different story. AI is writing more of it than ever, review times are climbing, and delivery throughput has actually declined. Trevor Stuart, co-founder of Split.io and now running Feature Management & Experimentation at Harness, calls it the six-lane highway ending in a two-lane bridge. The bottleneck didn't disappear. It moved. Coding got faster, but everything downstream -- reviews, security scans, delivery pipelines -- stayed the same width. Viktor points out this is the exact same pattern from the early agile days: his team shipped every two weeks, but testing still took six months. Different era, same structural problem. Feature flags are part of the fix, but not the way most people use them. Teams are now stuffing prompts, token limits, and temperature settings inside feature flag configurations and running A/B tests on AI agents in production. That's a long way from changing button colors on a marketing page, which is where experimentation started 15 years ago. The culture problem is harder than the tooling problem. Trevor has watched teams run one experiment, see it fail, and quit experimenting entirely. The fear of admitting failure kills more experimentation programs than bad data ever will. Meanwhile, the companies getting real results -- a fast food chain generating millions from kiosk experiments, a global bank driving hundreds of millions in customer acquisition -- are the ones treating experimentation as a permanent operating model, not a one-off project. The conversation also covers Trevor's path from co-founding Split to running it inside Harness post-acquisition. He stayed -- which doesn't happen as often as you'd think. Harness runs what he calls a 'startup within a startup' model, and he breaks down what that actually looks like from the inside, what was hardest to let go of, and why finding your 'why' matters more than any exit. Trevor's contact information: LinkedIn: https://www.linkedin.com/in/trevorbstuart/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#340: The smartest ops people are often the most likely to resist new technology -- and they're not wrong. If you don't change anything, nothing breaks, and nobody blames you. That's a completely rational choice. It's also the one that guarantees you fall behind. Bare metal to VMs, VMs to cloud, cloud to Kubernetes -- every time, the teams that played it safe ended up scrambling to catch up two years later. The safe bet isn't safe. It just feels that way. It gets worse when you look at where the tools come from. Kubernetes? Built by developers. Terraform? Developers. Containers? Developers. The tools ops teams depend on were made by a different tribe. So the pushback isn't really about whether the tech is ready or whether the risk is too high. It's about identity. 'Not my people' is a harder objection to overcome than 'not ready yet,' because no amount of documentation or proof-of-concepts answers it. And about proof -- everyone wants it before they'll move. But the proof already exists. It's the tool someone on your team has been running in shadow IT for a year without any official support. If it survived that long on its own, that's stronger evidence than any pilot program. That's your roadmap. And the way in is small chunks, not grand plans. Move one service. Learn something. Adjust. Repeat. AI in ops follows the exact same pattern. A tool that gets you 50% of the way there for free means you can focus your expertise on the other 50%. That's a win. But the people waiting for AI to be perfect before they'll touch it? They're making the same mistake as the teams that waited for perfect proof before migrating to the cloud. Different decade, same trap. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#339: DNS has been around since the 1980s. Nobody's writing blog posts about how it changed their life. But every single thing on the internet depends on it -- including all those AI tools everyone's excited about. Anthony Eden has been in the DNS business since the late nineties, when he was CTO of one of the first seven domain registrars after the .com deregulation. In 2010 he started DNSimple, and he did it without a dime of venture capital. Sixteen years later, his 20-person team runs a global DNS infrastructure with 14 edge nodes and 9 origin servers spread across multiple continents. The conversation covers the mistakes companies make with their domains -- running production DNS on a registrar that was never built for it, sharing logins with no access control, zero documentation on why records exist. Anthony breaks down how DNS actually works at scale (unicast vs anycast, the onion layers of resolvers), why your email deliverability problems are probably a DNS problem, and what the www vs no-www debate looks like in 2026. On AI tools, Anthony's take is practical. They're giving his engineers more time to think about problems instead of typing out solutions. But he's not buying the vibe coding hype -- when you run critical internet infrastructure, everyone on the team needs to understand the systems they're building. And for AI startups hoping to cash out? Most will fail. The twist you put on somebody else's model won't be a moat. It'll just become a feature for something bigger. Anthony's contact information: X: https://x.com/aeden Bluesky: https://bsky.app/profile/anthonyeden.bsky.social LinkedIn: https://www.linkedin.com/in/aeden/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#338: Every company adding AI coding tools runs into the same wall. Developers produce more code, but features don't ship any faster. The bottleneck just slides downstream -- to QA, to security, to legal, to whoever comes next in the pipeline. And the team that got faster? They don't even realize the people upstream could be feeding them more work. Viktor's take: the fastest possible setup is one person carrying a feature from idea to production. Not one person doing everything alone -- a system designed so nobody waits. Tests run in CI. Deployments happen through Argo CD. Security scanning is automated. There's a real difference between wiring up a light switch and hiring a butler to flip it for you. None of this is new. The same thing happened with punch cards, client-server, cloud, Kubernetes. One group adopts the new thing, everyone else says it doesn't apply to them, and the market eventually forces their hand. Meanwhile, every team in every company says they'd love to change if only the rest of the organization would get on board. Every team says this. So who's actually blocked? YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#337: Time series databases have become essential infrastructure for the physical AI revolution. As automation extends into manufacturing, autonomous vehicles, and robotics, the demand for high-resolution, low-latency data has shifted from milliseconds to nanoseconds. The difference between a general-purpose database and a specialized time series solution is the difference between a minivan and an F1 car - both will get around the track, but only one is built for the demands of real-time operational workloads. The open source business model continues to evolve in unexpected ways. While companies like Elastic and Redis have seen hyperscalers fork their projects, a new partnership paradigm is emerging. Amazon Web Services now pays to license InfluxDB and offers it as a managed service, signaling a shift toward collaboration rather than competition. This approach benefits everyone: vendors maintain development velocity, cloud providers get workloads on their platforms, and customers receive better-supported products. Evan Kaplan, CEO of InfluxData, joins Darin and Viktor to discuss the trajectory from observability metrics to physical world instrumentation, why deterministic models matter more than probabilistic ones when your robot might run over your cat, and what it takes to build a sustainable open source company over a decade-plus journey. Evan's contact information: X: https://x.com/evankaplan LinkedIn: https://www.linkedin.com/in/kaplanevan/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#336: The workplace is on the verge of a transformation as significant as the Industrial Revolution. Just as Bring Your Own Device policies emerged after the iPhone disrupted corporate mobile standards, we are now entering an era where employees may arrive with their own AI teams in tow. The question is no longer whether AI will change hiring and employment - it is how quickly companies will adapt before being left behind by competitors who embrace this shift. Current AI productivity gains remain largely individual rather than organizational. Writing code twice as fast means nothing if the deployment pipeline stays the same speed. But within five to ten years, entire industries face disruption - from primary care physicians to transportation to knowledge work. Companies clinging to restrictive AI policies today risk driving away top talent who have already integrated these tools into their workflows. The intellectual property implications alone - who owns an AI stack trained on company processes when an employee leaves - will require entirely new frameworks for employment law. Darin and Viktor explore these scenarios through the lens of a hypothetical job interview where a candidate brings their own team of AI agents. The conversation surfaces uncomfortable questions about compensation models, corporate governance, and whether we are witnessing the emergence of a new kind of talent that blends human expertise with digital capabilities. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#335: Observability tools have exploded in recent years, but most come with a familiar tradeoff: either pay steep cloud vendor markups or spend weeks building custom dashboards from scratch. Coroot takes a different path as a self-hosted, open source observability platform that prioritizes simplicity over flexibility. Using eBPF technology, Coroot automatically instruments applications without requiring code changes or complex configuration, delivering what co-founder Peter Zaitsev calls opinionated observability—a philosophy of less is more that aims to reduce cognitive overload rather than drowning users in endless metrics and dashboards. The conversation explores how Coroot differentiates itself in a crowded market with over a hundred observability vendors. Rather than competing head-to-head with cloud giants like Datadog and Dynatrace, Coroot focuses on developers who need answers fast without building elaborate monitoring systems. The platform combines systematic root cause analysis with AI-powered recommendations, using deterministic methods to trace how errors propagate through microservices before handing off to LLMs for actionable fix suggestions. Darin and Viktor dig into Coroot's business model with Peter, examining why the company chose Apache 2.0 licensing instead of more restrictive options, and how staying bootstrapped with minimal angel funding allows them to play the long game without pressure to chase every hype cycle. Peter's contact information: X: https://x.com/PeterZaitsev Bluesky: https://bsky.app/profile/peterzaitsev.bsky.social LinkedIn: https://www.linkedin.com/in/peterzaitsev/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#334: The debate over whether AI saves developers time misses a fundamental truth: coding was never the hardest part of software development. Writing code is mechanical work - the real challenges have always been understanding problems, designing solutions, communicating with stakeholders, and navigating organizational complexity. AI is now forcing a reckoning with this reality, pushing developers at every level to reconsider what skills actually matter. The traditional separation between architects who design and developers who implement is breaking down. AI enables a return to something like pair programming, where the person thinking through problems can now work alongside a fast executor without the old bottleneck of slow human typing. This shift means developers need stronger communication skills - the ability to explain technical decisions to non-technical stakeholders and translate business requirements into technical direction. For juniors, the opportunity is unprecedented: you can upskill faster than ever in the history of software, but only if you balance building things with actually understanding how they work. Darin and Viktor explore what this means for developers at every career stage, from juniors who should focus on fundamentals and end-to-end understanding, to seniors who are becoming more like editors and supervisors of AI-generated work. The developers who will thrive are those who combine real experience with a willingness to embrace change - and that combination has always been the winning formula. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#333: Pete Hunt, CEO of Dagster and early React team member, explores the evolution from Facebook's early React development through trust and safety infrastructure at Twitter, to building modern data orchestration tools. The conversation reveals how similar infrastructure problems plague every industry - whether you're launching rockets or managing porta-potties, the core challenges remain consistent: late data, quality issues, and mysterious errors that require both automated solutions and human oversight. The discussion dives into the technical realities of scaling systems, from the microservices complexity trap to the current AI adoption wave. Hunt shares candid insights about leadership challenges, including how well-intentioned technology recommendations can backfire, and why most data projects fail despite sophisticated multi-agent orchestration. The conversation touches on career advancement pressures that drive unnecessary complexity and the importance of focusing on actual user adoption rather than technical sophistication. This episode features Pete Hunt in conversation with hosts Darin and Viktor, covering everything from regular expression nightmares to the future of data infrastructure and the lessons learned from building products that people actually use. Pete's contact information: X: https://x.com/floydophone LinkedIn: https://www.linkedin.com/in/pwhunt/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#332: AI adoption in enterprise software development is accelerating, but operations teams are lagging behind. While application developers embrace AI tools at a rapid pace, those on the ops side remain skeptical—citing concerns about determinism, control, and a general resistance to change. This mirrors previous technology waves like containers, cloud, and Kubernetes, where certain groups initially pushed back before eventually adapting. The prediction for 2026: AI will not see widespread adoption in operations despite its growing presence elsewhere in the software lifecycle. The bigger challenge facing organizations is not just adopting AI but transforming entire processes to take advantage of it. Improving just one piece of the software delivery pipeline—like development speed—only creates bottlenecks elsewhere. Companies cannot hand developers AI tools while keeping everything else the same and expect transformational results. The future points toward a world where experts bring their own AI agents to companies: personal toolsets trained on their experience and best practices that integrate with organizational systems. Perhaps the most provocative insight centers on the value of writing code itself. The argument: writing code is the easiest and least valuable part of software development. The real cognitive load comes from thinking through requirements, architecture, and design. Developers who simply translate instructions to code without deeper engagement may find themselves in real danger as AI continues to advance. Darin and Viktor explore these predictions and more as they look ahead to what 2026 might bring for DevOps, platform engineering, and the evolving role of developers. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#331: At the end of 2024, predictions were made about what 2025 would bring to the tech industry. A year later, on New Year's Eve, it's time to look back and see what actually happened. The prediction episode from January 1st covered four major topics: rug pulls from companies switching to business source licenses, the rise of WebAssembly adoption, a wave of company acquisitions, and AI becoming embedded in existing tools. Some predictions hit the mark while others missed entirely, but what emerged was something nobody fully anticipated. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#330: In this short episode, Darin and Viktor reflect on the holiday season. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#329: Vibe coding - the practice of casually prompting AI to generate code solutions - has become increasingly popular, but its limitations become apparent when applications need to scale beyond personal use. While AI-assisted development can be powerful for proof of concepts and small internal tools, the transition from vibe-coded solutions to production-ready applications often requires experienced engineers to rebuild from scratch. The conversation explores three distinct levels of software development: personal tooling, internal applications, and public-facing systems. Each level demands different approaches, with vibe coding being most suitable for the first category but potentially problematic as complexity increases. The analogy of cooking illustrates this well - anyone can make a simple meal, but feeding hundreds of people requires professional expertise and proper infrastructure. Technical debt in the AI era presents new challenges and opportunities. Traditional software engineering principles like DRY (Don't Repeat Yourself) and clean code practices may matter less when AI can quickly refactor and improve code. The future likely involves hybrid teams where business experts work alongside experienced engineers, with AI agents handling implementation details. Darin and Viktor examine how pair programming is evolving from developer-to-developer collaboration to human-to-AI partnerships, fundamentally changing how software gets built and maintained. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#328: The build versus buy decision isn't as binary as most companies think. Every technology choice involves elements of both - you might use Linux (buy) but still configure and customize it extensively (build). The real question isn't whether to build or buy, but finding the right balance between the two approaches based on your company's resources, size, and unique requirements. Companies often fall into the trap of thinking their processes are so unique that existing solutions won't work, leading to unnecessary custom development. This "not invented here" syndrome is particularly common in large enterprises that mistake their size for complexity. In reality, most businesses face challenges that have already been solved by others. The key is recognizing when you truly need a custom solution versus when you can adapt existing tools. The decision becomes more nuanced when considering factors like maintenance costs, compliance requirements, and long-term sustainability. Building internally requires ongoing resources for updates, security patches, and knowledge retention within your team. Meanwhile, buying from vendors shifts much of this burden but introduces dependencies and integration challenges. The conversation features insights from Alex Gusev from Uploadcare, along with perspectives from hosts Darin and Viktor on navigating these complex technology decisions. Alex's contact information: X: https://x.com/alxgsv LinkedIn: https://www.linkedin.com/in/alxgsv/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#327: When AI tools suggest putting glue on pizza, it's a harmless laugh. But when autonomous AI agents start managing your infrastructure, the stakes become much higher. The reality is that current AI technology isn't ready for unsupervised deployment in critical systems, and treating it like it is could lead to catastrophic failures. The challenge isn't just about AI capabilities—it's about management and oversight. Most developers aren't trained as managers, yet they're being asked to supervise AI agents that need constant guidance and correction. Just like hiring a new employee, AI agents require company-specific knowledge, proper guardrails, and ongoing supervision to be effective. The same principles that apply to managing human workers—code reviews, testing, and performance evaluations—need to be adapted for AI management. As the ecosystem around AI continues to evolve rapidly, new challenges emerge. From sleeper agents that activate on specific dates to the need for completely new approaches to technical SEO for LLMs, the landscape is changing faster than most organizations can adapt. Darin and Viktor explore these challenges and discuss practical approaches for keeping AI systems from going rogue while maintaining the productivity benefits they can provide. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#326: Microservices architecture has evolved far beyond simple distributed systems, but most development teams are still rebuilding the same foundational patterns over and over again. Mark Fussell, co-founder of Dapr and Diagrid, explains how his team at Microsoft identified this repetitive reinvention problem and created a solution that abstracts away the complexity of service discovery, messaging, state management, and security while providing true cloud portability. Dapr emerged from Microsoft's Azure incubations team with a clear mission: stop forcing developers to rebuild distributed systems patterns from scratch. The runtime provides standardized APIs for common microservices needs while allowing teams to swap underlying infrastructure components without changing application code. Whether using Kafka, RabbitMQ, Redis, or cloud-native messaging services, developers write against consistent APIs while platform teams maintain control over infrastructure choices. The conversation covers Dapr's journey from Microsoft internal project to CNCF graduated status, the technical decisions behind its multi-language approach, and how it integrates with existing frameworks like Spring Boot and .NET. Mark also discusses Diagrid's platform play around durable workflows and the emerging role of Dapr in AI agent development. Darin and Viktor explore the practical adoption challenges, the balance between developer productivity and platform engineering concerns, and why experienced developers tend to embrace abstraction layers more readily than those building their first distributed systems. Mark's contact information: X: https://x.com/mfussell LinkedIn: https://www.linkedin.com/in/mfussell/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#325: KubeCon NA 2025 wrapped in Atlanta with unseasonably cold weather and some significant shifts in the cloud native ecosystem. The conference showed fewer vendors backing CNCF projects on the show floor, with key concerns emerging around maintainer burnout—exemplified by NGINX Ingress being deprecated despite running on 40% of Kubernetes clusters worldwide. The event revealed a maturing ecosystem where AI moved from buzzword to operational reality, with focus shifting toward conformance standards, security policies, and enterprise readiness rather than the hype cycle of previous years. The discussions revealed a consolidation pattern where larger corporations like AWS, Microsoft, and Google are increasingly the only ones who can sustain open source project maintenance. Startups and smaller companies face difficult choices: maintain existing revenue streams, pivot entirely to AI, or attempt both and fail at both. Meanwhile, AI adoption in the ops space remains behind other sectors, with developers emerging as the primary buyers for AI tooling—a shift that's reshaping go-to-market strategies across vendors. Platform engineering continues as a parallel major theme, focusing on operationalizing infrastructure at scale. Whitney's contact information: X: https://x.com/wiggitywhitney LinkedIn: https://www.linkedin.com/in/whitneylee/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#324: Kubernetes has reached a mature state where boring releases signal stability rather than stagnation. While the platform continues evolving with features like in-place resource updates in version 1.33, the real challenge lies in optimizing AI workloads that demand significantly more resources than traditional applications. The discussion reveals how auto-scaling capabilities become crucial for managing these resource-intensive workloads, with vertical and horizontal scaling finally working together through new features that allow pod resizing without restarts. The conversation explores the ongoing tension between cloud costs and data center investments, particularly as companies navigate uncertain AI requirements. While cloud providers offer flexibility for experimentation, the hidden costs of skilled personnel and infrastructure management often make cloud solutions more economical than initially apparent. The debate extends to startup strategies, where outsourcing infrastructure complexity allows teams to focus on core business value rather than operational overhead. Omer Hamerman joins Darin and Viktor to examine the common misconceptions about resource allocation, arguing that developers fundamentally cannot predict CPU and memory requirements accurately. This limitation makes automated right-sizing and intelligent scaling essential for modern Kubernetes deployments, especially as AI workloads continue pushing infrastructure boundaries. Omer's contact information: LinkedIn: https://www.linkedin.com/in/omer-hamerman/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/