Alfred Schmid
Steadforce GmbH - Head of Platform Engineering
Munich, Germany
Actions
In 1985, I had my first contact with a C64. Since then, I've been interested in solving problems with computers. Starting with tiny BASIC programs, I switched over to coding demos in assembler for fun. Now I'm implementing streaming solutions on Kubernetes clusters using the Kafka protocol and integrating them into internal developer platforms (IDPs). I have always been interested in the technologies necessary to solve current problems. I like to discover new things and would like to use them to keep customers ahead of the curve.
40+ years programming experience
12+ years containerization (Docker)
9+ years Kubernetes
8+ years Apache Kafka & the Kafka protocol (not just Confluent's product)
7+ years platform engineering
Area of Expertise
Topics
Promote environments the GitOps way by using Helm hydration (rendered manifests)
Modern container platforms which are managed by GitOps solutions like Argo CD require strategies to promote settings and configurations for various applications and components on different stages like development, integration and production.
Using Helm simplifies parameterized deployment of commonly used applications (e.g. from the CNCF landscape), but it's often hard to grasp what is really deployed. Seemingly simple Chart updates could lead to breaking changes, missing components or incompatible configurations.
It could be a challenge to get insights what is changed by automated Helm umbrella chart updates done by Renovate. With hydration the platform engineer gets insights of the manifest changes supported by the version control system.
We want to share our own experiences with different promotion approaches like the Argo CD Source Hydrator, gitops-promoter or hydrations done with GitHub Actions workflows and give ideas which solution could be suitable for different platform requirements.
Key insights you'll discover:
- Get an understanding for the Helm hydration (rendered manifests) pattern
- Understand promotion patterns
- Get insights on rendered Kubernetes manifests
- Gain confidence for future Helm chart updates
- Learn how to implement a GitHub Actions hydration workflow
- Benefit from drift-free promotion process
- Robust gating system
Schedule Heavy and Long-Living Workloads in Highly Scalable Kubernetes Clusters
Event-driven architectures love short, snappy consumers — but what happens when a single job takes six hours, must never run twice, and is picky about its runtime version?
We faced exactly this: a monolithic MATLAB execution platform that couldn't scale, couldn't run versions in parallel, and took the whole system down whenever one calculation ran out of memory. We rebuilt it as an event-driven system on Kubernetes, using Kafka as the scheduling backbone for heavy, long-living compute jobs.
In this talk, we walk through the production architecture and the hard-won lessons behind it:
- How to trigger hours-long jobs through a single Kafka topic without blocking the consumer group — and why partition count becomes your scaling contract
- A requeue-with-TTL pattern that lets runners decline work they can't handle (wrong version, already busy, shutting down) and routes exhausted records to a dead-letter topic
- Exactly-once execution semantics that guarantee every job — whether it runs for seconds or hours — is executed once and only once
- Graceful shutdown: making long-running jobs respect Kubernetes SIGTERM instead of fighting it
- Decoupling payloads from events with object storage, and streaming job state, logs, and control commands over dedicated topics
You'll leave with a concrete, battle-tested blueprint for using Kafka to orchestrate workloads that are far heavier and longer-lived than the typical streaming use case — applicable to ML training, simulations, batch analytics, or any compute that refuses to fit in a 30-second consumer callback.
**Track fit:** Scalability & reliability / Production case studies (Kafka)
Replace Your Custom Kubernetes Controller with Kyverno Policies
To manage Kubernetes environments, custom controllers are often essential for enforcing policies, automating tasks, and ensuring compliance. While these controllers provide flexibility, they demand considerable development effort, ongoing maintenance and a profound understanding of Kubernetes. This is where Kyverno comes into play - a proprietary policy management tool for Kubernetes that simplifies the enforcement of cluster-wide rules through declarative policies, thereby eliminating the need for custom controller code from scratch.
In our talk, we will demonstrate how custom Kubernetes controllers can be replaced by Kyverno policies. We will address the challenges associated with maintaining custom controllers, highlight the advantages of Kyverno's declarative approach, and present real-world scenarios where Kyverno effectively manages tasks such as resource validation, mutation and generation. Examples will illustrate how Kyverno reduces operational overhead, accelerates implementation and enhances maintainability without sacrificing flexibility.
The presentation will provide insights into migrating from custom-written controllers to Kyverno, leveraging the capabilities of Kyverno on building a developer platform using Kubernetes.
OpenMCP – Enhancing the Development of a Kubernetes-Based Developer Platform
OpenMCP provides Crossplane to turn Kubernetes into a full control plane, enabling declarative infrastructure and service management through native Kubernetes APIs. This talk shows how OpenMCP simplifies the development and operation of developer platforms - without complex tools like Terraform or CloudFormation.
Using real-world examples, we demonstrate how infrastructure can be deployed across cloud and on-premises environments in a consistent, scalable, and developer-friendly way.
We show how OpenMCP enables developer self-service, ensures governance and compliance through policy-driven management (e.g. Kyverno), and promotes a clear separation between platform and application teams.
It's ideal for DevOps teams, platform engineers, and Kubernetes enthusiasts looking to build efficient, secure, and scalable platforms with Crossplane.
Build a simple Helm hydration (rendered manifests) CI/CD pipeline
Modern container platforms which are managed by GitOps solutions like Argo CD require strategies to promote settings and configurations for various applications and components on different stages like development, integration and production.
Using Helm simplifies parameterized deployment of commonly used applications (e.g. from the CNCF landscape), but it's often hard to grasp what is really deployed. Seemingly simple Chart updates could lead to breaking changes, missing components or incompatible configurations.
It could be a challenge to get insights what is changed by automated Helm umbrella chart updates done by Renovate. With hydration the platform engineer gets insights of the manifest changes supported by the version control system.
We want to share our own experiences with different promotion approaches like the Argo CD Source Hydrator, gitops-promoter or hydrations done with GitHub Actions workflows and give ideas which solution could be suitable for different platform requirements.
Key insights you'll discover:
- Get an understanding for the Helm hydration (rendered manifests) pattern
- Understand promotion patterns
- Get insights on rendered Kubernetes manifests
- Gain confidence for future Helm chart updates
- Learn how to implement a GitHub Actions hydration workflow
- Benefit from drift-free promotion process
- Robust gating system
Cloud Native Summit 2026 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top