Cloud Native Computing Switzerland Meetup Mai 2026 Recap

Am 21. Mai 2026 hat sich die Cloud Native Computing Switzerland Meetup Community wieder im VSHNtower in Zürich getroffen – für einen Nachmittag mit technischen Vorträgen, Diskussionen und Austausch in der Community.

Mit inzwischen über 3.000 Mitgliedern in der Meetup-Gruppe bringt die CNC Switzerland Community nach wie vor Platform Engineers, DevOps-Leute, Architekt:innen und Open-Source-Begeisterte aus dem Schweizer Cloud-Native-Umfeld zusammen.

Die Mai-Ausgabe brachte vier Vorträge auf die Bühne: von Kubernetes-nativer Deployment-Orchestrierung über Rust im Cluster bis hin zu Open-Source-Governance im KI-Zeitalter und Cluster Autoscaling jenseits der grossen Cloud-Anbieter.

Begrüssung und News aus der Community

Das Meetup startete wie immer mit einer kurzen Begrüssung durch die Organisatoren und ein paar Updates aus der Community. Die Grundsätze des CNC Switzerland Meetups bleiben dabei unverändert:

• Alle Talks sind technisch und mit Open-Source-Fokus
• Keine Produkt- oder Verkaufspitches
• Talks werden auf Englisch gehalten
• Speaker:innen aus unterrepräsentierten Gruppen sind ausdrücklich willkommen

So bleibt das Meetup ein echtes Community-Event für Technikerinnen und Techniker und keine Marketingbühne.

Kuberik: Sichere Deployments für Kubernetes – ohne Handarbeit

Luka Rumora

Luka Rumora eröffnete das Programm mit einem Blick darauf, woran Continuous Delivery auf Kubernetes in der Praxis bis heute scheitert. Die meisten Teams, so seine Beobachtung, stecken in einer von zwei Welten fest: GitOps-Setups, die mit dem Anwenden von Manifests aufhören – oder fragile CI-Pipelines aus Bash-Skripten und Workarounds. Echtes End-to-End-Delivery sieht anders aus.

Die Bausteine einer guten Deployment-Pipeline kennt man: Canaries, Health Checks, Smoke Tests, Promotion-Schritte, Rollback. Was fehlt, ist eine native und wiederverwendbare Art, das alles in Kubernetes zu kombinieren. Werkzeuge wie Argo Rollouts, Flagger oder Kargo lösen jeweils einen Ausschnitt – aber nie die ganze Pipeline.

Genau hier setzt Kuberik an. Es orchestriert den ganzen Weg vom Release bis in die Produktion – erkennen, gaten, ausrollen, verifizieren, promoten – über pluggable Kubernetes-Ressourcen, die sich in bestehende GitOps-Setups einfügen statt sie zu ersetzen.

Der Vortrag zeigte, was ein Kubernetes-nativer CD-Ansatz konkret bringt:

• step-basierte Pipelines werden durch wiederverwendbare Ressourcen ersetzt
• Canaries, Verifikation und Rollback laufen über ein gemeinsames Modell
• die Integration mit bestehendem GitOps-Tooling bleibt erhalten

Kubernetes ohne Operator: Ein Minecraft-Panel mit Rust und kube-rs

Hadi Cherkaoui – CM Informatik AG

Hadi Cherkaoui, 17 Jahre alt und Lernender Plattformentwickler EFZ bei der CM Informatik AG, brachte eine erfrischend unbequeme These mit: Das Operator-Pattern, auf dem viele im Raum ihren Arbeitsalltag aufbauen, ist nicht immer die richtige Wahl.

Das Projekt Anvil ist ein Kubernetes-natives Server-Panel für Minecraft, geschrieben in Rust. Pro Server entstehen StatefulSet, PVC und Service – direkt per kube-rs-Aufruf, ohne CRD und ohne Controller. Den State hält die Kubernetes-API selbst, jede Benutzeraktion ist ein direkter API-Call.

Mindestens so spannend wie die Umsetzung war die Argumentation dahinter: Ein Controller lohnt sich dort, wo es autonomen State zu reconcilen gibt. Wo das nicht der Fall ist, wird er zur unnötigen Ceremony. Anvil zeigt, wie die imperative Alternative aussehen kann – betrieben auf einem k0s-Cluster im Homelab.

Was man aus dem Talk mitnehmen konnte:

• Nicht jede Kubernetes-native Anwendung braucht einen Controller.
• Direkte API-Calls sind ein völlig legitimes Pattern.
• Rust und kube-rs harmonieren überraschend gut.
• Homelabs bleiben ein guter Ort, um vermeintliche Defaults zu hinterfragen.

Vibe Code Survival Guide für Open Source

Vadim Bauer – 8gears

Vadim Bauer, Maintainer des CNCF-Projekts Harbor, sprach über eine Frage, die in Open Source gerade zur Schlüsselfrage wird: Wie hält man ein Projekt zusammen, wenn KI-gestützte Beiträge schneller hereinkommen, als Maintainer sie überhaupt reviewen können?

KI-Beiträge pauschal zu verbieten, sei keine Lösung – sich vom schieren Volumen die Richtung des Projekts wegspülen zu lassen, aber genauso wenig. Aus den Erfahrungen mit Harbor und Harbor Satellite teilte Vadim das Playbook, mit dem sein Team versucht, die Übersicht zu behalten:

• Eine klare Projektrichtung definieren, damit Beitragende – ob Mensch oder KI-gestützt – wissen, was im Scope ist.
• Explizite Akzeptanzkriterien und Guardrails setzen.
• KI auch auf Maintainer-Seite einsetzen, um Beiträge zu triagieren, zu reviewen und zu filtern.
• Als Projekt klar entscheiden, was Core ist, was Extension – und was schlicht ausserhalb des Scopes liegt.

Ein ehrlicher Blick darauf, was funktioniert, was nicht – und wie sich Open-Source-Projekte im Zeitalter von Vibe Coding neu organisieren müssen.

Einen Kubernetes Cluster Autoscaler Provider mit externalgrpc bauen

Marco De Luca – VSHN

Den Abschluss machte ein technischer Deep Dive von Marco De Luca aus dem VSHN-Team. Auf mdnix.io schreibt er über Infrastruktur, Linux, Kubernetes und die Dinge, die er nebenbei baut.

Der Kubernetes Cluster Autoscaler entscheidet, wann skaliert wird – aber nicht, wie eine VM entsteht. Das ist Sache des Cloud Providers, und der Upstream-Tree deckt vor allem die grossen Anbieter ab. Regionale und spezialisierte Clouds bleiben aussen vor. Mit externalgrpc lässt sich praktisch jede Cloud per gRPC an den Autoscaler anbinden.

Marco nahm das Publikum mit durch:

• wie der Cluster Autoscaler intern funktioniert und wo der Cloud Provider andockt
• die Implementierung eines Out-of-Tree-gRPC-Providers für einen Schweizer IaaS-Anbieter
• die Design-Entscheidungen und die Stellen im Contract, die wirklich zählen
• die Stolpersteine, die man erst beim Lesen des Autoscaler-Sourcecodes findet

Am Ende hatten die Teilnehmenden eine klare Vorstellung davon, wie sich Autoscaling auch an Clouds anbinden lässt, die nicht auf der Upstream-Liste stehen – ein Thema, das besonders im Schweizer Umfeld relevant ist, wo souveräne und regionale Cloud-Anbieter eine wichtige Rolle spielen.

Wir werden einen Folgeartikel zu Marcos Thema veröffentlichen – bleibt dran!

Networking und Apéro

Nach den Vorträgen blieben viele noch für das Networking und den traditionellen Apéro – bei Kubernetes-nativer Delivery, Rust, Open-Source-Governance und Autoscaling gab es genug Gesprächsstoff.

Genau dafür gibt es diese Meetups: Engineers aus unterschiedlichen Firmen, die Praxiserfahrungen, Lessons Learned und Open-Source-Lösungen teilen – sie sind das, was die Schweizer Cloud-Native-Community ausmacht.

Die Talks im Video

Die Aufzeichnungen erscheinen auf dem VSHN TV YouTube-Kanal.

Am besten gleich abonnieren, dann verpasst du keine neue Folge.

Mach mit in der Community

Das Cloud Native Computing Switzerland Meetup richtet sich an alle, die mit Cloud-Native-Technologien und Open Source arbeiten – Engineers, Architekt:innen, Entwickler:innen.

Du möchtest selbst einen Talk halten oder dein Projekt vorstellen oder die Meetup-Location und den Apéro sponsern? Reich deinen Vorschlag hier ein.

Wir freuen uns aufs nächste Meetup im September!