Die technischen Herausforderungen hinter Servala: Standardisierung der Applikationsbereitstellung

In diesem Nachfolgeartikel zu unserer Einführung in Servala werfen wir einen Blick auf die technischen Herausforderungen, Managed Services für Cloud Provider überall verfügbar zu machen. Erfahre, wie die wiederholte und inkonsistente Natur von Applikationspaketierung, -bereitstellung und -betrieb unsere Vision für Standardisierung inspiriert hat.

Wir gehen auf die Probleme ein, mit denen Platform Engineers heute konfrontiert sind – darunter inkonsistentes Verhalten von Containern, unvorhersehbare Helm Charts und das Chaos des Day-2-Betriebs im Hinblick auf Sicherheit, Konfiguration und Abhängigkeiten.

Lerne, wie Servalas vorgeschlagene Open Standards die Landschaft für folgende Gruppen verändern können:

• Softwareanbieter – Schnellere Markteinführung und grössere Reichweite ohne operativen Aufwand
• Cloud Provider – Erweiterung der Servicekataloge mit Enterprise-fähigen Managed Services
• Endnutzer – Selbstbedienung mit konsistenten, sicheren und konformen Applikationen

Begleite uns auf dieser Reise, um Applikationsbereitstellung zu vereinfachen und Managed Services für alle zugänglich zu machen.

In unserer Einführung in Servala haben wir die technischen Herausforderungen erwähnt, Softwareanbieter dazu zu befähigen, sich selbst auf unserer Plattform zu integrieren. Während wir Servala 2025 weiter aufbauen, widmen wir uns der grundlegendsten Herausforderung: Einen standardisierten Ansatz für Applikationsbereitstellung zu schaffen. Lass uns diese Herausforderungen und unsere vorgeschlagene Lösung im Detail anschauen.

Die wiederholende Natur des Applikationsmanagements

In den letzten Jahren haben wir bei VSHN unzählige Applikationen im Rahmen unseres Managed Services-Angebots betreut – dem Fundament von Servala. Für jede einzelne Applikation mussten wir immer wieder dieselben mühsamen Aufgaben erledigen:

Packaging: Die Applikation in ein deploybares Format bringen, typischerweise durch Erstellen eines OCI-konformen Container-Images, das mit Docker, Podman, Kubernetes und OpenShift kompatibel ist. Der Packaging-Prozess wird automatisiert, sodass er bei jeder neuen Version ausgelöst wird.

Deployment: Die verpackte Applikation automatisiert auf das Zielsystem ausrollen – nicht manuell. Die meisten Deployments umfassen mehrere Umgebungen wie Test, Staging, Pre-Prod und Produktion oder ermöglichen Self-Service-Bereitstellung für SaaS. Oft ist dies mit dem Erstellen von Helm Charts und dem Aufsetzen von Automatisierungspipelines oder APIs verbunden, z.B. über Kubernetes-Operatoren (wie Crossplane).

Day-2-Betrieb: Nach dem Deployment kommen Aufgaben wie das Sammeln von Metriken, Einrichten von Alerts, Updaten der Applikation, Skalierung bei Performanceproblemen, Backup und Restore von Daten, Log-Analyse, 24/7-Support und die Einhaltung von Compliance-Vorgaben dazu – sowie viele weitere Betriebsaufgaben.

Die aktuelle Herausforderung für Servala

Diese Schritte immer und immer wieder durchzuführen, wird ermüdend. Die gleichen Probleme zu lösen, sobald wir uns um eine neue Applikation kümmern, fühlt sich nicht wirklich wertstiftend an. In der Realität müssen wir mit einer Vielzahl unterschiedlicher Herangehensweisen umgehen. Es ist eine grosse Belastung für Engineers, all diese Varianten zu unterstützen. Einzelne Teile der oben erwähnten Funktionen sind meist schon erledigt – zum Beispiel gibt es bereits Container-Images, aber jedes davon verhält sich anders. Das bedeutet, dass wir müssen jedes Mal herausfinden müssen, wie es in den nächsten Schritt integriert werden kann. Dasselbe gilt für die verschiedenen Helm Charts da draussen. Standardisierung würde uns diese Last abnehmen, den Prozess effizienter und weniger repetitiv machen.

Das Kernproblem liegt in der Flexibilität der verwendeten Tools. Container-Images unterscheiden sich massiv in ihrer Bauweise und ihrem Verhalten. Helm Charts akzeptieren Parameter in inkonsistenten Formaten. Zum Beispiel kann ein Container-Image in einem Chart als img, image oder image-registry bezeichnet sein – je nachdem, wer es geschrieben hat.

Security Scans und Compliance Reports sind von Applikation zu Applikation unterschiedlich. Manche bringen SBOMs (Software Bill of Materials) mit, bei anderen müssen diese manuell erstellt werden. Die Konfigurationshandhabung ist genauso inkonsistent: Manche Applikationen setzen auf Umgebungsvariablen, andere erwarten Konfigurationsdateien an bestimmten Orten, wieder andere benötigen eigene Konfigurations-APIs.

Auch der Day-2-Betrieb unterscheidet sich stark. Manche Applikationen exportieren Metriken im Prometheus-Format, andere gar nicht. Identische Metriken haben unterschiedliche Namen, und Logging-Formate reichen von strukturiertem JSON bis zu einfachem Plaintext. Abhängigkeitsmanagement wird oft vernachlässigt – es gibt kaum Infos zu benötigten Services oder Komponenten. Das Betreiben dieser Applikationen wird zum nervenaufreibenden „Whack-a-Mole“-Spiel.

Wir müssen diese grundlegenden Inkonsistenzen lösen, damit Servala skalieren kann und Softwareanbieter ihre Applikationen einfacher onboarden können.

Unsere vorgeschlagene Lösung: Standardisierung

Wie lassen sich diese Hindernisse überwinden? Unser Vorschlag: eine Sammlung von Dokumenten definieren, die Muster für alle notwendigen Teile der Applikationsbereitstellung über Servala beschreiben. Du kannst diese Dokumente auch als Spezifikationen, Golden Paths, Patterns, Standards, Konventionen oder Defaults verstehen. Ziel ist es, einen gemeinsam abgestimmten Weg zu dokumentieren, um die genannten Aufgaben zu lösen – sodass wir sie nicht immer wieder neu durchdenken müssen.

Aber das nur für uns zu machen, fühlt sich nicht richtig an. Wir bei VSHN leben Open Source und Open Standards und wollen gemeinsam mit anderen einen definierten Weg finden. Daher schlagen wir vor, eine Gruppe von Menschen aus verschiedenen Unternehmen zusammenzubringen, um diese Muster gemeinsam zu dokumentieren und sich darauf zu einigen.

Unsere Vision: Eine transformierte Landschaft der Applikationsbereitstellung

Wie wird Applikationsbereitstellung aussehen, wenn die Servala-Spezifikationen weit verbreitet sind? Die Vorteile wären für alle Beteiligten transformativ:

Für Softwareanbieter:

• Schnellere Markteinführung: Anstatt Monate in den Aufbau von Deployment-, Monitoring- und Wartungssystemen zu investieren, können Anbieter sich auf ihr Kernprodukt konzentrieren und auf Servalas standardisierte Delivery-Mechanismen setzen, um global Cloud Provider zu erreichen.
• Weniger operativer Aufwand: Wer sich an die Servala-Spezifikation hält, übernimmt automatisch bewährte Praktiken wie Monitoring, Metriken, Logs, Backups etc. – ganz ohne eigenes Operations-Team.
• Grössere Marktreichweite: Die Möglichkeit, auf jedem Servala-kompatiblen Cloud Provider zu deployen, eröffnet neue Märkte ohne zusätzlichen Engineering-Aufwand.
• Bessere Sicherheitslage: Standardisierte Security-Scans, Compliance-Berichte und Konfigurationsmanagement senken Risiken drastisch – selbst ohne dediziertes internes Security-Know-how.

Für Cloud Provider:

• Erweiterte Servicekataloge: Provider können sofort Dutzende Managed Services mit einheitlichen Betriebsstandards anbieten – ein enormer Mehrwert.
• Operationale Konsistenz: Alle Services folgen denselben Mustern für Monitoring, Alerts und Wartung – das reduziert die Komplexität beim Betrieb verschiedenster Third-Party-Applikationen.
• Wettbewerbsdifferenzierung: Kleinere Cloud Provider können mit Hyperscalern mithalten, indem sie vergleichbare Kataloge an Managed Services anbieten.

Für EndnutzerInnen:

• Dank Servalas standardisierten Bereitstellungsmechanismen kannst du komplexe Managed Services mit Vertrauen deployen – in dem Wissen, dass sie konsistenten betrieblichen Mustern folgen. Dieses Empowerment gibt dir Kontrolle und Sicherheit im Betrieb.
• Die operativen Schnittstellen bleiben unabhängig von der jeweiligen Applikation konsistent, was dir ein vorhersehbares und sicheres Nutzungserlebnis bietet. Diese Vorhersehbarkeit stärkt das Vertrauen in Stabilität und Zuverlässigkeit des Systems.
• Enterprise-Readiness: Alle Services beinhalten automatisch Sicherheitsfunktionen, Backup/Restore, Monitoring und andere Enterprise-Features – ganz ohne individuellen Integrationsaufwand.
• Vereinfachte Compliance: Standardisierte Security-Scans und Compliance-Reports machen regulatorische Audits einfacher und weniger ressourcenintensiv.
• Klarheit bei Abhängigkeiten: Durch transparente Darstellung von Service-Abhängigkeiten und Kompatibilitätsanforderungen werden Deployment-Fehler und Konfigurationsprobleme reduziert.

Die Spezifikationsbereiche von Servala

Wir planen, Muster für folgende Bereiche zu dokumentieren:

Verhalten von Container-Images: Wo werden Daten gespeichert? Wie werden Ports freigegeben? Wie verhält sich der Entry Point? Mit welchen Berechtigungen läuft die Applikation?

Helm Chart „API“: Wie verhalten sich die Standardwerte? Wie sieht die Struktur der Konfiguration aus?

Einheitlicher Betriebsrahmen:

• Backup und Restore: Standardisierte Schnittstellen für konsistente Backups von Applikationen und Daten, mit klar definierten Wiederherstellungspfaden und Verifikationsmethoden
• Metriken: Klar definierte Endpunkte für Applikationsmetriken zur Alarmierung, Überwachung und Performance-Einblicke
• Alerting und Monitoring: Gemeinsame Alarmdefinitionen, Schweregrade und Reaktionserwartungen über alle Applikationen hinweg
• Logging-Standards: Einheitliche Logformate, Aufbewahrungsrichtlinien und Suchmöglichkeiten zur Vereinfachung der Fehleranalyse
• SLA-Definitionen: Standardisierte Metriken zur Messung und Berichterstattung von Verfügbarkeit, Performance und Zuverlässigkeit
• Wartungsfenster: Klare Protokolle zur Koordination und Kommunikation von Wartungen mit minimaler Unterbrechung
• Abrechnung: Einheitliche Art der Abrechnung der Service-Nutzung
• Security Scanning und Compliance: Standardisierte Ansätze für Schwachstellenmanagement, Sicherheitsrichtlinien und Compliance-Berichterstattung über alle Applikationen hinweg
• Konfigurationsmanagement: Einheitliche Muster für Konfigurationshandling, Secret Management und Laufzeit-Rekonfiguration
• Abhängigkeitsmanagement: Klare Deklaration und Handhabung von Service-Abhängigkeiten, inklusive Versionierungsanforderungen und Kompatibilitätsmatrizen

Self-Service API-Architektur: Standardisierte Strukturen für Kubernetes-Ressourcen vorschlagen, um vorhersehbare Schnittstellen für Applikationsmanagement in verschiedenen Umgebungen zu schaffen

Bisherige Arbeiten, auf denen wir aufbauen möchten

Es gibt bereits erfolgreiche Standardisierungsinitiativen, auf die wir aufbauen wollen:

OCI Image Format

Nach Jahren der Fragmentierung im Container-Bereich hat das Open Container Initiative (OCI) einen einheitlichen Image-Standard geschaffen, der von Tools wie Docker und Podman genutzt wird. Dieser Standard definiert Dateisystempfade (z. B. /var/lib/docker/), Image-Layering und Interoperabilität mit Registries wie Docker Hub, GHCR und Quay.

Kubernetes als Container-Orchestrator

Kubernetes hat sich als De-facto-Standard zur Verwaltung von Containerflotten etabliert. Es bietet eine einheitliche API zur Steuerung von Rechenleistung, Netzwerk und Storage – unabhängig vom Infrastrukturanbieter.

Pod- und Container-Lifecycle-Konventionen in Kubernetes

Die Community hat das Verhalten von Applikationen bei Lifecycle-Events wie Start, Shutdown und Health Checks standardisiert. Anwendungen reagieren nun vorhersehbar auf Restarts und Node Drainings, was den Alltag von Platform Engineers stark vereinfacht. Lifecycle Hooks sind zum Standard geworden.

Prometheus-Metriken

Viele Applikationen exportieren Metriken im Prometheus/OpenMetrics-Format über einen /metrics-Endpunkt. Es gibt etablierte Namenskonventionen (z. B. http_requests_total). Obwohl nicht alles einheitlich ist, ist dies einer der am weitesten akzeptierten inoffiziellen Standards – genutzt von Applikationen, Exportern, Sidecars und Service Monitors.

SBOM (Software Bill of Materials)

Dank offener SBOM-Standards und Unterstützung durch Tools wie GitHub, GitLab und Docker ist das Erstellen und Konsumieren von SBOMs heute Best Practice. Die EU Cyber Resilience Act (CRA) verpflichtet mittlerweile zur Nutzung von SBOMs – sowohl für proprietäre als auch für Open-Source-Software.

12-Factor App

Auch wenn es noch Unterschiede gibt, verdient das 12factor.net-Manifest eine lobende Erwähnung. Es legte 2011 den Grundstein für Cloud-Native Applikationen und beeinflusst Architektur und Plattformdesign bis heute: Konfiguration über Umgebungsvariablen, Statelessness, Logging auf stdout – vieles davon ist heute Best Practice und wird von Plattformen oft indirekt erzwungen.

Helm Chart Best Practices

Die Helm-Community hat auf die strukturelle Inkonsistenz von Charts reagiert und Best Practices, Guidelines sowie Tools wie helm lint und helm create bereitgestellt. Auch wenn diese nicht überall angewendet werden, setzen Projekte wie Bitnami, KubeApps und Backstage zunehmend auf diese Konventionen – ein solides Fundament für Servalas Standardisierungsbemühungen.

OpenAPI / Swagger

Die OpenAPI-Initiative hat die API-Standardisierung stark vorangetrieben. Sie erlaubt maschinenlesbare API-Definitionen, automatisierte SDK-Generierung, Tests, Mocks und lesbare Dokumentation. Sie ist breit akzeptiert – von Kubernetes CRDs bis hin zu GitHub APIs – und bringt Konsistenz und Interoperabilität in API-Design und -Nutzung.

OpenServiceBroker API

Wir haben diese API bereits implementiert und nutzen sie mit einigen Kunden. Sie bietet jedoch keinen deklarativen, Cloud-Nativen Ansatz für Service Listing und Provisionierung.

Crossplane

Wir sind Fans von Crossplanes deklarativem Ansatz für Service-Definitionen und -Instanziierung. Die „Composite Resource Definitions“ (XRDs) erlauben das Erstellen von benutzerdefinierten CRDs mit konsistenter Struktur. Servala ersetzt Crossplane nicht – wir nutzen es unter der Haube.

Open Application Model (OAM)

OAM unterstützt Servalas Mission, indem es einen plattformagnostischen, standardisierten Weg bietet, Cloud-Native Applikationen zu definieren. Es trennt sauber Kernlogik (Components), Betriebsfeatures (Traits) und Abhängigkeiten (Scopes). Mit wiederverwendbaren Definitionen für Metriken, Backups und Autoscaling hilft OAM, die Fragmentierung von Helm Charts und Container Images zu überwinden – eine interessante Grundlage für Servalas Spezifikation.

Platform Specification

Die Platform Spec-Initiative passt perfekt zu Servalas Vision: Sie definiert eine standardisierte YAML-basierte Schnittstelle zwischen Entwicklern und Platform Engineers für Deployment und Management – inklusive Container Images, Umgebungsvariablen, Secrets, Service Bindings und Regeln fürs Ausrollen. Damit lassen sich viele der Inkonsistenzen in Helm Charts und beim Laufzeitverhalten lösen. Durch die Übernahme oder Anlehnung an Platform Spec kann Servala Onboarding vereinfachen, Integrationsaufwand reduzieren und Plattformunabhängigkeit fördern.

Cloud Native Application Bundle (CNAB)

Die CNAB-Spezifikation unterstützt Servalas Ziele durch ein portables, standardisiertes Format für das Packaging und die Verteilung komplexer Applikationen – inklusive Kubernetes-Manifeste, Helm Charts, Terraform-Pläne und Skripte. CNAB definiert ein konsistentes Format für Code, Konfiguration und Lifecycle-Operationen (Install, Upgrade, Uninstall). Damit lässt sich ein einheitliches, wiederholbares Deployment ermöglichen – ideal für komplexe Managed Services über verschiedene Umgebungen hinweg.

Der Weg nach vorn

Servala will das Onboarding von Applikationen um den Faktor 10 beschleunigen – von Wochen auf Stunden oder Tage – und gleichzeitig die Zuverlässigkeit durch bewährte, konsistente Muster für Deployment und Betrieb dramatisch steigern. Wir haben begonnen, diese Standards in unsere Entwicklungs-Roadmap zu integrieren, doch für den Erfolg ist eine breite Zusammenarbeit in der Branche entscheidend.

Wir laden Softwareanbieter, Cloud Provider und Platform Engineers ein, gemeinsam mit uns an der offenen und kollaborativen Gestaltung dieser Standards zu arbeiten. Mit einem soliden Fundament kann Servala die Art und Weise, wie Managed Services bereitgestellt werden, neu definieren: Cloud Provider können ihre Kataloge erweitern und Softwareanbieter werden zu SaaS-Providern – ohne grossen operativen Aufwand.

Bleib auf dem Laufenden

Erfahre immer als Erste oder Erster die neuesten Nachrichten zu Servala. Gib einfach deine E-Mail-Adresse unten ein:

Was kommt als Nächstes?

Im Jahr 2025 werden wir uns darauf konzentrieren, Softwareanbietern die Möglichkeit zu geben, sich selbst in die Servala-Service-Plattform einzubinden. Mehr Informationen zu Warum wir Servala gestartet haben findest du auch in unserem Servala Launch Announcement.

Kontaktiere uns

Interessiert, mehr zu erfahren? Buche ein Meeting oder schreib uns und finde heraus, wie Servala dir helfen kann. Erlebe die Zukunft von Cloud Native Services auf servala.com. 🚀