Was war am Swiss Cloud Native Day 2025 am inspirierendsten und welche Relevanz haben sichere und skalierbare Plattformen in der Praxis?

MFR: Mich hat vor allem die unglaubliche Bandbreite an Themen rund um Cloud Native beeindruckt. Von Methoden zum Proben von Ausfallszenarien, über Freizeit-Kubernetes-Cluster-Bauer:innen, bis hin zu automatisierten Compliance-Prüfungen.

Sichere und skalierbare Plattformen gewinnen weiter an Bedeutung. Sie entlasten die Entwickler:innen, übernehmen viele operative Aufgaben und sorgen dafür, dass Workloads auch bei einer steigender Anzahl Nutzer:innen oder saisonalen Schwankungen zuverlässig laufen.

JBE: Besonders spannend fand ich die Diskussionen über neue Runtimes. Die Zukunft wird vermutlich nicht mehr exklusiv auf Container setzen, sondern unterschiedliche Runtimes für verschiedene Workloads nutzen, wie zum Beispiel Wasm für Functions oder Firecracker VMs für isolierte Workloads.

Das macht Plattformen skalierbarer, erhöht aber auch die Komplexität. Ausserdem entwickelt sich Kubernetes klar als de-facto-Plattform für KI-Workloads, was für die flexible Nutzung von GPUs sehr relevant ist.

SKA: Für mich war der Beitrag zur Swiss Cloud Native Farm am inspirierendsten. Es zeigt, wie viel Innovationskraft in kleinen Projekten stecken kann, selbst für sehr alte Probleme. Auch die Sessions zur Utilization-Optimierung (z. B. beim CERN) und leaneren Deployments wie Wasm waren spannend.

Gerade im Kontext von exponentiell wachsender Rechenleistung durch KI sollten wir uns überlegen, wie wir Energie, Kosten und Emissionen minimieren können und die Load so gering wie möglich halten.

WVI: Besonders inspirierend fand ich, wie sich die Komplexität einer unternehmensweiten CI/CD-Plattform für eine grosse Zahl von Teams erfolgreich beherrschen lässt. SAP zeigt, wie kuratierte Templates einen zentralen One-Stop-Shop für die Teams bieten und gleichzeitig die Wartung für Pipeline-Maintainer deutlich vereinfachen.

Kubernetes Custom Resources ermöglichen die flexible Abbildung unternehmensspezifischer Ressourcen, auch ohne bestehende Provider. Zusammen mit Custom Operators lassen sich der gewünschte (Desired) und der aktuelle (Actual) Zustand steuern, Fehler automatisch beheben und Rollbacks sicher durchführen. Durch eine Verschachtelung von Ressourcen und Operatoren ist das System erweiterbar, ohne dass es zu einem Wildwuchs an Templates kommt.

Insgesamt war das für mich ein praxisnaher Gegenpol und eine sinnvolle Ergänzung zu bereits etablierten Setups – vor allem, wenn höhere Domänenlogik und echter Self-service gefragt sind.

Hast du auch einen spannenden Use Case? Let's talk!

Michael Fritsche

Jakob Beckmann

Selim Kälin

Wolfgang Vigl