Sessions of 2026

Have you ever been frustrated during a maintenance window because a developer deployed a PodDisruptionBudget alongside a single-replica Deployment? Have you debugged application issues for hours, only to find that a latest image tag caused a hidden change in your environment? While Kubernetes offers great scalability and velocity, it introduces significant operational challenges. Fortunately, these can be tackled with robust Admission Control policies. We will explore different Dynamic Admission Controllers, specifically Kyverno and OPA Gatekeeper, to see how they handle these common pitfalls. Additionally, we will compare these established tools with the recently stabilized ValidatingAdmissionPolicy in Kubernetes 1.30. This session will help you understand whether to rely on external controllers or embrace the new native features to secure your infrastructure.

95% of GenAI projects fail to deliver measurable business returns (MIT Media Lab, 2025). Not because the models don't work—they demo beautifully. They fail because we skip the fundamentals: clear requirements, stakeholder alignment, and product thinking. This talk challenges the "build a model first" mindset. We'll explore why requirements engineering and understanding business value are more critical for AI projects, not less. You'll learn practical techniques to identify real value and collaborate effectively with stakeholders—defining success before writing a single line of code. With this foundation, we examine when PoCs are actually needed and how to bridge the dangerous gap between PoC and MVP. But we don't stop there: What does a real product strategy look like? How do we move from one-off experiments to a systemic, transformational approach? This talk will help you think about getting value out of solutions—where AI is a powerful tool to achieve outcomes, not the business value itself.

Managed Kubernetes doesn’t eliminate complexity, it shifts it out of sight. In this talk, we look behind the curtain of Managed Kubernetes to show the architectural building blocks that enable Managed Service Providers (MSPs) to deliver production-ready clusters for customer workloads. We will walk through different patterns for control plane hosting and node lifecycle management, comparing practical approaches from open source projects like Gardener, Kamaji, and Cluster API. The session closes with a live Gardener demonstration, illustrating how the "Kubernetes on Kubernetes" model can support high-density multi-tenancy, control plane isolation, and resilient lifecycle automation.

According to Gartner, 95% of enterprise AI initiatives fail - not because of the technology, but because organizations lack the cultural, operational and contextual foundation to make AI work in production. This session shows what it takes to be part of the 5% that succeed - real, deployed, hands-on. No buzz words, no myths, no false promises. We’ll explore the shift from scripted automation to context-aware, agentic delegation, where systems understand environments, dependencies, and intent. By embedding context into neural networks and context graphs, we move from maintaining scripts to delegating outcomes - enabling deterministic, auditable, and resilient automation across any infrastructure, including air-gapped systems. Using real examples from platform engineering and enterprise operations, we’ll demonstrate how context-aware automation might reshape open source adaption and the entire cloud-native ecosystem. Don’t be fooled: success takes more than just tech - it requires a mindset-shift, governance, and a culture ready to rethink everything that they've learned. Forget your current "now" and take something home that helps you with your decision making - especially if you're desperate about bringing your automation-KPI up.

AI agents are making decisions, calling tools, and trusting data, all without human review. But with autonomy comes a new and largely misunderstood attack surface. In this demo‑driven talk, we’ll show how agentic AI systems can be hijacked without code exploits. Using nothing but text, tools, and trust. Through live demos, we explore three real‑world classes of vulnerabilities from the OWASP Top 10 for AI: - Indirect Prompt Injection, where untrusted content silently manipulates agent decisions - Tool / MCP Poisoning, where malicious tool descriptions hijack agent behavior and leak full context - RAG Poisoning, where internal knowledge causes persistent data exfiltration No slides. No theory. Just Demo, Demo, Demo! With practical DevSecOps lessons on why classic security controls fall short once AI agents start acting on your behalf.

“AI agent” has become an overloaded term, applied to everything from glorified cron jobs to brittle prompt chains. In this talk, we challenge the hype and ask a simple question: what actually qualifies as an AI agent? We’ll break down common misconceptions, examine real-world implementations, and contrast agent-like systems with workflows, automations, and orchestration pipelines that are often mislabeled. Through concrete examples, we’ll explore autonomy, planning, memory, feedback loops, and failure modes, and show where most systems quietly fall short. The goal is not to define yet another framework, but to give practitioners a clear mental model to reason about agents, avoid architectural self-deception, and build systems that deserve the name.

Modern cloud-native development demands deployment pipelines that empower developers to ship with confidence while maintaining rigorous governance across environments. This session presents a comprehensive, production-proven deployment architecture that transforms multi-stage Kubernetes releases from operational burden into seamless automation. At the core of our approach lies a GitOps-driven pipeline integrating Release-Please for automated semantic versioning, GitHub Actions with reusable workflows for CI/CD orchestration, and ArgoCD's multi-source capabilities for declarative Kubernetes deployments. Each release generates cryptographically signed container images and Helm charts, complete with SLSA attestations, ensuring supply chain integrity from commit to production. The architecture addresses a critical challenge in enterprise environments: decoupling application versioning from infrastructure configuration. By leveraging ArgoCD's multi-source applications, teams independently manage Helm chart versions and stage-specific value files, enabling granular control over what deploys where and when. Renovate automates dependency discovery across all layers, including container images, Helm charts, and configuration manifests, creating pull requests that serve as auditable promotion gates between development, staging, and production environments. We demonstrate practical use cases including automated image updates with configurable auto-merge policies, timestamp-tagged configuration releases for deterministic deployments, and coordinated multi-artifact rollouts. The result: a scalable, standardized deployment framework that reduces cognitive overhead for development teams while providing platform teams with the governance and traceability required for enterprise Kubernetes operations.

Ever watched your pipeline silently eat up CPU and memory, without any obvious errors? That’s the silent killer of OpenTelemetry: performance overhead. Excessive instrumentation, unoptimized exporters, and high-cardinality data can lead to resource spikes, latency, and unexpected costs. We’ll break down the sources of OpenTelemetry overhead, show how to measure and visualize its impact, and walk through practical techniques for reducing it. From sampling strategies to batching, from smarter exporters to backend tuning, the audience will learn in a live demo how to keep the benefits of OTel without burning your infrastructure budget. By the end, attendees will have actionable strategies to optimize their own observability pipelines for both performance and cost.

You are in a meeting. Someone checks their Generative AI of choice mid-discussion and announces: "The AI says we just need to do X." Everyone nods and moves on. Congratulations, you have just solved the wrong problem. Nothing is broken. Everything is faster, and yet something is wrong. Generative AI has amplified our worst problem-solving habit: jumping to solutions before understanding the problem. It is System 1 thinking on steroids, magnified by the Dunning-Kruger effect: confident, fast, and increasingly wrong. We are racing toward solutions faster than ever, but they are brittle, disconnected, and often miss the point entirely. This talk will teach you that one question changes everything: "What problem are we actually solving?" It sounds simple. It is not. You will learn how to recognize when speed is hiding misunderstanding, how to distinguish symptoms from root causes, map consequences before committing, and slow down long enough to understand what you are actually solving for. This is not just theory; it is a practice you can apply in your next team meeting. The best AI prompts, the smartest automation, and the fastest deployments are worthless if we are solving the wrong problem. It is time to stop optimizing for speed and start optimizing for understanding.

For two decades, hyperscalers have claimed that using modern cloud services requires moving all your data into their datacenters, subjecting it to foreign jurisdictions like the US CLOUD Act. This talk challenges that assumption. We show how cloud-native technologies enable managed cloud services to be delivered where the data already lives: on-premises, in a private cloud, or with trusted public providers. Using Kubernetes and CNCF projects such as Crossplane, Prometheus, and Grafana, we present a platform model where databases, queues, caches, and DevOps tools are delivered as self-service managed services without data relocation or provider lock-in. Data sovereignty, we argue, is not a contract; it’s an architectural decision.

This talk is not about Gen AI, even though it involves some. It is about mindset, curiosity, and asking questions. A lot of questions. With 5 senior engineers in the team and a backlog full for the next 6 months, the excitement about our latest hire was divided. The fact that they were straight from an apprenticeship and had no coding experience did not help. We were sure that we wanted them in the team, just did not want the work that comes with tutoring an aspiring engineer. Little did we know that our junior in 2 sprints time will pick up the story points of a senior engineer. Yes, also some deleted databases along the way, but that is part of the game.

Many organizations reach for specialized streaming systems like Apache Kafka for high-throughput event processing. But is it always the best choice? What if you choose PostgreSQL instead. This talk chronicles six years of battle-tested lessons learned while scaling PostgreSQL from a simple queue to a system processing 100,000 events per second, and delivering total 6.7T events. Learn about the specific configuration values, query patterns, and architectural decisions that enabled PostgreSQL to compete with and often outperform dedicated messaging systems, while providing the operational simplicity and transactional guarantees that only PostgreSQL can offer.

We set out to build an autonomous AI software engineering team. Describe what you want, machines build and ship it. Agents take natural language tasks, write production code, push to GitHub, deploy to cloud. No human intervention. But orchestrating AI agents is hard. They're bursty, ephemeral, unpredictable. Idle for hours, then dozens spin up at once. A task takes five minutes, then the agent should vanish. You can't pre-provision for demand you can't forecast. We reached for the standard playbook. Kubernetes Deployments. HPA for scaling. PostgreSQL task queues. Polling loops. Then we looked up from the laptop. The thermal printer was printing a label. Inkjet printers have cartridges that dry out when idle. Thermal printers have no ink. Just heat and paper. No waste when not printing. We had built an "inkjet architecture" for a "thermal workload". Always-on Deployments polling for work. Paying for pods that were waiting. Ink drying in the cartridge. We rebuilt on thermal principles using Knative Eventing. CloudEvents flow through a Broker. Agent pods spawn as Kubernetes Jobs when events arrive, then terminate. One task, one Job. Zero tasks, zero pods. Services emit events, Triggers route them, nobody knows about anybody else. NGINX at the edge. Redis for state. Knative as the nervous system. Claude Code writes the software. The demo: submit a task, watch the event flow, see the AI write code, push to GitHub, deploy to cloud. Then the thermal printer prints a receipt. Physical proof that software wrote software. The machine that taught us how to architect now validates what we've built.

Since 2022, Kubernetes has supported checkpointing and restoring individual containers. While that initial work demonstrated the capability, it also revealed a demand for a clearer roadmap and a more open design process regarding future developments. We are now taking the next big step: bringing these capabilities to Pods. As Pods are the atomic unit of Kubernetes, this shift is essential for handling attached resources correctly. To make this happen, we created the Kubernetes Checkpoint Restore Working Group. We want to build this feature in the open, bringing the community together to ensure the solution works for everyone.

In container vulnerability management, detection isn’t the hard part anymore - it’s triage: deciding what’s real, what actually applies to this container image, and what to do next without grinding engineering to a halt. In this talk, I’ll walk through a production workflow that turns “CVE scan noise” into evidence-backed decisions using an AI agent with retrieval. For each CVE, the system enriches vulnerability context via a lookup service, retrieves the image SBOM, compresses it into a minimal component manifest, and asks the agent to classify the finding into a small set of actionable outcomes aligned with an “affected/not affected/under investigation” model. I’ll also share the guardrails that made it dependable (strict output contracts, validation and repair prompts, and routing logic) along with lessons learned about false positives, dependency constraints, and making SBOM data usable for LLMs.

The linux kernel through eBPF offers to unify the disparate fields security and observability through shared data structures. We show how a K8s Security Operations Center, organically composed of established eBPF projects can see signals that the individuals cannot. We explain how we achieve both a comprehensive baseline and use independent signals to dial up/down coverage as suspicious indicators surface. The mutual independence of signals from across processes, file system, and network activity achieves a high signal-to-noise, enabling manageable data volumes and facilitating selective forensic storage. You will see two shorts demos: (A) of a root-kit which is hard to detect for sys-call based security tools in their default configurations, however almost trivial to detect with our adaptive setup. (B) of an agentic AI attack that mimicks a cobalt-strike C2 server You ll also learn how our SOC architecture is node-local and can be airgapped. This means no data leaves the cluster and you remain sovereign and in control of your data.

Every org enforcing Terraform standards eventually hits the same wall: policy tools can flag issues, but they cannot fix module code. The result is a graveyard of forked modules that drift from upstream and turn upgrades into a full-time job. This talk introduces policy transformation: automatically rewriting Terraform modules at download time so teams get compliant code without maintaining forks. I will demo eight real transformation rules across four categories: lifecycle management (prevent_destroy, ignore tag drift, protect KMS keys), block removal (strip provisioners), attribute restriction (deny GPU or specialty instances), and content sanitization (safe regex cleanups). You will see the before-and-after HCL, plus the safety model that makes this production-ready: deterministic outputs, collision detection, preview diffs, and a four-level risk classification. You will leave with a practical decision framework for validate vs transform, a DIY toolkit using pre-commit, hclwrite, custom tflint rules, and plan validation, and a simple migration path from module forks to rule-based enforcement. No vendor account required to apply the patterns from this talk.

The Cyber Resilience Act (CRA) will be arriving in the European Union in 2027, and with it a lot of new obligations. What we already consider good practices in our software industry today will be required by law tomorrow. In this talk, we will take a look at what's inside the CRA, who will be affected by it, and what new requirements we will have to fulfil. After that, we will take a look at tooling to generate Software Bills of Materials (SBOMs) for our .NET and JavaScript projects, as well as how to visualise and integrate them into existing CI workflows. Last but not least, we will take a look at how to handle the required vulnerability management with (semi-)automated dependency updates by utilising tools like Dependabot or Renovate and how to reduce dependencies with distroless images.

In this session, I’ll walk you through how I use AI to speed up the whole process of bringing external vendor Terraform into an enterprise landing zone. Instead of waiting days or weeks for manual reviews, I built an AI‑assisted pre‑check system that automatically scans the code, applies our governance rules, and highlights risks before anything gets deployed. The idea is simple: vendors move faster, we keep control, and everyone avoids the back‑and‑forth headaches. I’ll show how the rule engine works, how AI plugs into the workflow, and how this approach helps teams deliver new solutions much quicker, without compromising security or compliance.

AI agents are becoming first-class actors in DevOps platforms. They open pull requests, trigger CI/CD pipelines, scale Kubernetes workloads, and respond to incidents and, all of this increasingly without a human in the loop. Yet most organizations still authorize these agents with static API keys, personal access tokens, and broadly scoped CI secrets. This creates a dangerous gap. Tokens prove identity, but they don't answer the question that actually matters: *Should this agent perform this action, for this user, on this resource, in this environment, right now?* In this talk, I'll break down why token-based authorization fails for agentic DevOps (over-privileged bots, context-blind decisions, and zero auditability) and introduce a practical architecture that closes the gap: an **Agent Gateway** backed by **OpenFGA**, an open-source Relationship-Based Access Control (ReBAC) engine. You'll see a **live demo running inside Kubernetes** that walks through real scenarios: - **GitOps governance:** Contributors can open PRs; only maintainers can merge to main. - **Deployment promotion:** Staging deploys move fast; production requires explicit human approval. - **Agent trust boundaries:** Approved bots act; unknown bots are denied —> no implicit trust. Every action flows through the gateway: **AI Agent → Agent Gateway → OpenFGA → downstream system**. Authorization decisions are relationship-based, computed at runtime, and fully auditable. You'll walk away with a concrete, reusable pattern (authorization model, trust tuples, gateway design) that you can adopt in your own platform. No vendor lock-in. No custom policy DSL. Just declarative relationships and an open-source engine that treats authorization as a control plane, not an afterthought.

We like to say Kubernetes platforms fail because they’re “too complex”. But complexity isn’t the problem. Platforms fail because they’re obese. They’re bloated with an excess of features, tools, abstractions, and opinions that far exceed an organization’s operational capacity and cognitive load—especially in enterprises, regulated environments, and talent-constrained teams. The cloud-native ecosystem doesn’t help. It hands out sweets constantly: one more controller, one more abstraction, one more “best practice.” Each addition seems harmless in isolation. Saying yes is easy. Saying no is career-limiting: since no-one wants to admit their own reality doesn't match the industry narrative. The Pluralistic Ignorance is real, yo. The ecosystem rewards addition, not subtraction. Often, “simplification” efforts often do the opposite—layering abstractions on top of abstractions until the platform is heavier, slower, and harder to operate and change than before. Eventually, the platform collides with reality: finite talent, finite attention, finite time. Cognitive load exceeds capacity. Operational friction grows. Engineering quality cracks. Business outcomes stall. ROI quietly evaporates. This isn’t a tooling failure. It’s a constraint failure. So how do you fix an obese platform? The same way you fix obesity: by creating a calorie deficit, rigorous exercise and discipline. In the platform world, that means recognizing constraints and designing for and staying within those limits, across technology, processes, organizational culture, budget, engineering skills, team cognitive load and more. Dare to play the hard 'less is more' subtraction game, not the easy game of addition: treat dealing with constraints, subtraction, prioritization and trade-offs as first-class engineering skills—not as signs of lack of ambition.

Here's what platform engineers won't say out loud: very few can answer the question "Was it worth it?". This talk tries to help you answer that. Everyone knows that to call the win you first need to measure success; the hard part: knowing what to measure. This is where people start shopping: DORA, SPACE, DevEx, MONK/MOCK, Scorecards, OKRs and more. So many frameworks, yet 30% of organizations still don't measure anything at all (I guess they didn't know what to pick), while others pick one or two and hope they work. After building multiple platforms with tools such as Kubernetes Operators, Terraform, Crossplane, pipelines and good old Java, let me tell you what we measured and what really mattered. In every journey, the real challenge wasn't picking a framework: it was figuring out what success actually meant, and then measuring it without losing sight of what we were aiming for. Let's walk through these frameworks so that you can bring home a "slightly" opinionated approach on how to measure platform initiatives at Day 0 (still building), Day 1 (we got there), and Day 2 (it worked - now scale it, please).

Stateful workloads, especially databases, have always been framed as problematic on Kubernetes. In this talk, we want to clear up this misconception by showing that Kubernetes is highly extendable and is in fact used to host ClickHouse, an OLAP column-oriented database, at scale for our DBaaS offering. We discuss a variety of mechanisms and extensions built on top of existing Kubernetes logic that helps us run, update and scale databases for our customers with zero downtime. Throughout this talk, we discuss what we call MultiSTS (the usage of multiple StatefulSets) and MBB (Make-Before-Break) and how those concepts helped us overcome challenges with stock Kubernetes primitives, particularly for our requirement to always provide full capacity to our customers. In this case study, attendees will gain insights into the challenges and solutions posed by running a successful hosted database service on Kubernetes. They will take away the toolset to extend Kubernetes for database workloads.

Hybrid nodes on Amazon EKS give you a fully managed cloud control plane while letting you run workloads on your own on-premises hardware. At ORF.at we run exactly this setup in production, EKS connected with On-Prem and Cilium running in VXLAN. This session puts the spotlight on the one problem that actually kills the whole architecture: admission webhooks become completely unreachable for the control plane the second you enable Cilium VXLAN. Crossplane brings dozens of webhooks. Kyverno multiplies it. We show the failures, explain why it happens, and demonstrate the routing layer that makes the hybrid cluster stable in real production. Furthermore, we are going to compare the Hybrid Node architecture with other options and why we decided to go this way.

Whether you are a Platform Engineer, an SRE, or simply running system administration tasks, you need to continuously monitor applications running in a Kubernetes cluster or view the position of the sun and moon for your next lab project. You start with some available tools that provide the necessary information about your application. However, you hit a wall when you need to extend their scope for better integration and availability. In this talk, you will learn how to extend your CNCF-native tool capabilities with a wide collection of Grafana Open Source community-driven plugins. By the end of this talk, you will have a clear understanding of the plugin ecosystem and will be able to integrate these plugins into your CNCF projects, leveraging enhanced capabilities to visualize your data for monitoring and observability. Join us to learn more about community, plugins, integrations, and start your cloud native journey with minimal overhead.

Enterprises are deploying autonomous AI agents across operations, finance, healthcare, and customer workflows. The compliance teams governing those same enterprises are working from frameworks — GDPR, SOC 2, HIPAA, NIST AI RMF, EU AI Act, PCI-DSS — that were written before agents existed. The frameworks haven't been silent on agents. They've been misread. This talk unpacks what each major compliance framework actually requires when an AI agent acts on behalf of a user or system — and translates those requirements into concrete technical decisions for the teams building agents with LangChain, PydanticAI, CrewAI, AutoGen, LlamaIndex, LiteLLM, and the OpenAI Agents SDK. Two audiences leave with something actionable: business stakeholders with a governance roadmap, developers with a compliance-aware architecture checklist.

As organizations build increasingly complex, data-driven applications, the reliance on hyperscaler cloud platforms (like AWS, GCP, and Azure) has skyrocketed. While proprietary managed services lower the barrier to entry, they introduce a critical strategic risk: severe vendor lock-in. This dependency limits long-term flexibility, escalates costs, and ultimately compromises data sovereignty by tying critical data and machine learning pipelines to a single provider's ecosystem. But can a fully standardized, open-source stack truly match the enterprise-grade performance and reliability of these proprietary giants? To answer this, we need a stress test. In this talk, I will explore an empirically validated, cloud-native blueprint that challenges the necessity of managed cloud services. Using a highly demanding, high-throughput system as our proving ground (Predictive Maintenance for Industrial Use-Cases) — requiring massive data ingestion, sub-millisecond stream processing, and complex ML inference — I will demonstrate how to architect a completely vendor-agnostic data pipeline from the edge to the cloud.

Austria's NIS2 transposition has pulled thousands of new organizations into binding cybersecurity obligations — with personal liability for management and a 24-hour incident reporting deadline. Meeting these requirements with a fragmented cloud stack is nearly impossible. This session shows what a modern unified cloud security approach actually delivers against the NIS2 control catalogue.

A broken route should fail where it is introduced, not later when the ingress controller finally tries to load it. Kubernetes can validate object structure, but it cannot know whether a custom routing rule is actually valid for a specific controller. At Zalando we hit this with Skipper, our open-source HTTP router and Kubernetes ingress controller: manifests could pass CI/CD while a typo in a predicate, invalid filter parameters, or an unparsable backend only surfaced later in the routing layer. At our scale, 250+ clusters, 15k+ ingresses, ~200k routes and 500k-2M RPS, this became real production risk. This talk shows how we moved that feedback to `kubectl apply` by reusing Skipper’s own route-processing logic inside a validating admission webhook. Instead of building a separate validator that would drift from runtime behavior, the webhook uses the same filter registry, predicate specs and backend checks as Skipper itself. Blog Post https://engineering.zalando.com/posts/2026/04/skipper-validating-admission-webhook.html