CI/CD- und Cloud-native-Stacks scheitern in Produktion selten an fehlenden Features, sondern an unklarer Verantwortung im Störfall. Meine Position: Ein Anbieter, eine Library oder ein Framework ist erst dann geeignet, wenn der DevOps-Betrieb es unter Last, beim Rollback und beim Wegfall des Herstellers beherrscht. Alles andere ist Demo-Qualität mit hübscher Pipeline-Grafik.
Ein guter Anbieter beweist zuerst, wie er wieder entfernt wird
Die übliche Evaluation beginnt mit Feature-Matrix, Lizenzmodell und Roadmap; ich würde genau dort nicht starten, weil diese Kriterien den späteren 03:00-Uhr-Incident kaum vorhersagen. Für DevOps Engineers zählt zuerst die Frage, ob ein Werkzeug ohne Datenverlust, ohne manuelle Datenbankoperationen und ohne proprietären Kontrollkanal wieder aus der Produktionslandschaft entfernt werden kann.
Ich würde Moderne Webentwicklung automatisieren mit CI/CD und DevOps nicht als Beschaffungsargument akzeptieren, weil Automatisierung nur dann produktionsreif ist, wenn sie auch Deautomatisierung, manuelle Übersteuerung und Auditierbarkeit zulässt.
Bei CI/CD-Plattformen wie GitHub Actions, GitLab CI/CD 17.x, Jenkins 2.452 LTS, Tekton Pipelines 0.59, Argo Workflows 3.5 oder CircleCI sollte die erste technische Übung deshalb nicht „Hello World Deployment“ heißen, sondern „Vendor fällt aus, Cluster läuft weiter“. Wenn ein SaaS-CI-System keine signierten Artefakte lokal reproduzierbar erzeugt, ist es für kritische Deployments riskant, weil der Produktionsbetrieb im Ausfall nicht mehr zwischen vertrauenswürdigem und fremdem Artefakt unterscheiden kann.
Ein brauchbarer Test ist hart, aber fair: Baue dasselbe Container-Image mit Docker BuildKit –provenance=true, Podman 5.x oder Kaniko 1.23, speichere die SBOM als SPDX 2.3 oder CycloneDX 1.6 und verifiziere die Signatur mit Sigstore cosign 2.4. Wenn die Digests zwischen zwei Builds unnötig abweichen, ist das kein Schönheitsfehler, weil Rollbacks und Forensik dann auf Vermutungen statt auf identischen Artefakten beruhen.
Konkrete Zahlen sollten in der Evaluation früh auftauchen. Ein von euch zu setzender Grenzwert kann zum Beispiel sein, dass ein Rollback nach Pipeline-Fehler in weniger als 15 Minuten möglich sein muss, weil längere manuelle Pfade bei häufigen Deployments operativ zu teuer werden. Eine im 30-Tage-Pilot gemessene Kennzahl sollte die Change Failure Rate nach DORA-Definition sein; liegt sie über 20 Prozent, ist der Anbieter nicht automatisch schlecht, aber die Kombination aus Tooling, Tests und Release-Politik ist noch nicht produktionsreif. Als dokumentierter Standardwert taucht bei Prometheus 2.x häufig scrape_interval: 15s in Beispielkonfigurationen auf; dieser Wert ist kein Gesetz, aber er zeigt, wie schnell Metriken in vielen Setups erwartet werden. Ein SLO-Ziel wie 99,9 Prozent Verfügbarkeit ist ein bewusst zu verhandelnder Zielwert, weil es monatlich grob 43 Minuten Fehlerbudget bedeutet und damit direkte Auswirkungen auf Release-Frequenz und Bereitschaftsdienst hat.
Ich würde keinen Anbieter wählen, der nur über sein Web-UI vollständig bedienbar ist, weil produktionsnahe Wiederherstellung reproduzierbare CLI-, API- oder Git-Zustände braucht. GitHub Actions mit workflow_dispatch, GitLab mit .gitlab-ci.yml, Jenkins mit Jenkinsfile, Argo CD mit Application CRDs und Flux mit Kustomization CRDs sind hier stärker als Systeme, die Konfiguration primär in Klickpfaden verstecken.
GitOps gewinnt nicht immer, aber es schlägt ChatOps im Audit
Für Cloud-native Deployments ist die Versuchung groß, ChatOps, manuelle Freigaben und direkte Kubernetes-Kommandos zu mischen. Das wirkt flexibel, ist aber im Incident schwer zu rekonstruieren, weil Slack-Nachrichten, kubectl-Historie und Ticketkommentare selten denselben Wahrheitsstand abbilden. GitOps ist nicht deshalb überlegen, weil Git modern klingt, sondern weil ein Git-Commit eine überprüfbare, revertierbare und signierbare Absicht speichert.
Der Vergleich zwischen Argo CD 2.12 und Flux CD 2.4 ist dafür aussagekräftig. Argo CD gewinnt, wenn Teams eine starke Weboberfläche, visuelle Diff-Ansichten, SSO über Dex oder OIDC und ein zentrales Operations-Modell brauchen; der Preis dafür sind mehr laufende Komponenten wie API Server, Repo Server, Application Controller und häufig Redis, wodurch Upgrades und Hochverfügbarkeit mehr Betriebskosten erzeugen. Flux gewinnt, wenn Plattformteams Kubernetes-native Controller, geringeren UI-Bedarf und klare Mandantenfähigkeit über Namespaces bevorzugen; der Preis dafür ist eine steilere Lernkurve für Entwickler, weil Diagnose und Bedienung stärker über CRDs, Events und CLI laufen.
Beide sind Open Source, aber nicht kostenlos im Betrieb, weil Controller-Monitoring, RBAC-Design, Backup der Cluster-Zustände und Upgrade-Tests Arbeitszeit verbrauchen. Ein interner Richtwert kann sein, dass pro produktivem GitOps-Controller mindestens 2 Alerts existieren sollten: einer für Reconciliation-Lag und einer für fehlgeschlagene Syncs. Diese Zahl ist kein Herstellermaß, sondern ein knappes Betriebsminimum, weil ein stummer Controller gefährlicher ist als ein lauter.
Ein Vendor oder Framework sollte außerdem zeigen, wie es mit Kubernetes 1.30, Helm 3.15, Kustomize 5.x, OCI Image Spec 1.1, containerd 1.7 und Network Policies umgeht. Wer Helm-Charts liefert, aber keine sinnvollen values.schema.json-Dateien bereitstellt, erschwert sichere Konfiguration, weil ungültige Werte erst zur Laufzeit auffallen. Wer CRDs liefert, aber keine Upgrade-Reihenfolge dokumentiert, verschiebt Risiko in euren Wartungszeitraum, weil Kubernetes CRD-Schemaänderungen nicht immer reversibel sind.
Ein kleiner, lauffähiger Smoke-Test für eine Evaluation darf unbequem sein, weil er die Lieferkette vor dem ersten Architektur-Workshop messbar macht:
#!/usr/bin/env bash
set -euo pipefail
IMAGE="${1:-nginx:1.27.3}"
trivy image --exit-code 1 --severity HIGH,CRITICAL "$IMAGE"
syft "$IMAGE" -o spdx-json > sbom.spdx.json
cosign verify --certificate-identity-regexp '.*' \
--certificate-oidc-issuer-regexp '.*' "$IMAGE" >/dev/null
kubectl diff -f k8s/ --server-side=true
Dieser Test ist absichtlich klein, weil ein Vendor, der schon an Trivy 0.53, Syft 1.x, cosign und kubectl diff –server-side=true scheitert, im späteren Audit mehr Zeit kosten wird als er in der Demo spart. Falls der Anbieter eigene Scanner erzwingt und Standardformate wie SPDX oder CycloneDX nur exportiert, aber nicht importiert, würde ich ihn ablehnen, weil ein Sicherheitsbefund dann an ein einzelnes Ökosystem gebunden bleibt.
Cloud-native ist erst produktionsreif, wenn der Kontrollpfad ausfällt
Warum Cloud-native Architekturen zur Pflicht werden unterschätzt aus meiner Sicht die Kontrollpfad-Frage, weil Kubernetes, Service Mesh und Managed Services zwar Skalierung erleichtern, aber neue Abhängigkeiten in API Server, Admission Controller, DNS, Zertifikate und Observability einführen.
Bei der Bewertung von Libraries und Frameworks für Cloud-native Workloads reicht es nicht, ob sie Kubernetes unterstützt. Eine Java-Anwendung mit Spring Boot 3.3, Quarkus 3.12 oder Micronaut 4.x muss saubere SIGTERM-Behandlung, Readiness-Probes und konfigurierbare Timeouts bieten, weil Kubernetes Pods beendet und ersetzt, ohne eure Business-Transaktion zu verstehen. Eine Node.js-Anwendung mit Fastify 4 oder NestJS 10 muss HTTP Keep-Alive, OpenTelemetry-Instrumentierung und Graceful Shutdown explizit unterstützen, weil sonst Rolling Updates zu zufälligen 5xx-Spitzen führen.
Ich würde kein Framework produktiv empfehlen, dessen Health-Endpoint Datenbank, Cache und externe APIs pauschal in einem einzigen „healthy/unhealthy“-Status vermischt, weil Kubernetes dann bei einem abhängigen Dienstfehler funktionierende Pods unnötig töten kann. Readiness und Liveness müssen getrennt sein: Liveness beantwortet, ob der Prozess neu gestartet werden muss, Readiness beantwortet, ob er gerade Traffic annehmen darf.
Für Service Meshes ist die Evaluation ähnlich nüchtern. Istio 1.22 gewinnt, wenn mTLS, Traffic-Splitting, AuthorizationPolicy, EnvoyFilter und komplexe Multi-Cluster-Topologien gebraucht werden; es kostet CPU, RAM und kognitive Last, weil Sidecars, Control Plane und Envoy-Konfiguration debuggt werden müssen. Linkerd 2.15 gewinnt, wenn einfache mTLS-Verschlüsselung, geringe Latenz und schnelle Bedienbarkeit wichtiger sind; es kostet Flexibilität, weil die Erweiterbarkeit geringer ist als bei Istio. Cilium 1.15 mit eBPF gewinnt bei Netzwerktransparenz und Hubble-Observability, aber es verlangt Kernel- und CNI-Kompetenz, weil Fehler tiefer im Netzwerkpfad liegen.
Mindestens ein Test muss den Ausfall des Kontrollpfads simulieren: API Server nicht erreichbar, Argo CD gestoppt, DNS verzögert, Zertifikatsrotation fällig. Ein praxistauglicher Zielwert kann sein, dass bestehender Datenverkehr 10 Minuten ohne Kubernetes API Server weiterläuft, weil bereits gestartete Pods und Services nicht bei jedem Request den Control Plane brauchen sollten. Eine vom Anbieter veröffentlichte Grenze ist bei vielen Managed-Kubernetes-Angeboten die Unterstützung nur bestimmter Kubernetes-Minor-Versionen; diese Versionsfenster sind relevant, weil veraltete Cluster Sicherheitsfixes und Admission-API-Kompatibilität verlieren.
Standards sind hier keine Bürokratie, sondern Fluchtwege. OpenTelemetry 1.x mit OTLP über gRPC oder HTTP verhindert Vendor-Lock-in bei Traces, weil Daten an Grafana Tempo, Jaeger, Honeycomb oder einen kommerziellen Anbieter gesendet werden können. Prometheus-Metriken mit RED-Methode, USE-Methode und Histogrammen wie http_request_duration_seconds_bucket sind besser als proprietäre Dashboards, weil Alert-Regeln als Code versionierbar bleiben. SLSA v1.0, in-toto Attestations und OCI-Labels wie org.opencontainers.image.revision helfen im Incident, weil sie Artefakt, Commit und Build-Prozess verbinden.
Supportqualität zeigt sich an Runbooks, nicht an Enterprise-Folien
Ein Vendor für CI/CD oder Cloud-native Frameworks sollte in der Evaluation ein produktionsnahes Runbook liefern, nicht nur Architekturdiagramme. Ein gutes Runbook enthält Fehlersymptome, Metriken, Log-Abfragen, Eskalationsgrenzen und Rollback-Schritte, weil DevOps Engineers im Bereitschaftsdienst keine Roadmap lesen. Wenn der Anbieter keine Beispiel-Alerts für Prometheus Alertmanager, Grafana 11 oder Datadog Monitors liefern kann, fehlen ihm wahrscheinlich echte Betriebsdaten, weil belastbare Alerts aus wiederholten Störungen entstehen.
Ich würde Support-SLAs nicht nach Reaktionszeit kaufen, sondern nach Diagnosefähigkeit bewerten, weil eine Antwort nach 30 Minuten wertlos ist, wenn sie nur „Bitte Logs senden“ lautet. Ein sinnvoller Test ist ein simulierter Sev-2-Fall während der Pilotphase: defekte Helm-Release-Migration, fehlschlagender Admission Webhook oder steigende P99-Latenz nach einem Sidecar-Update. Die Uhrzeit sollte unbequem sein, weil Supportprozesse am Dienstag um 10:00 Uhr selten den Bereitschaftsdienst am Sonntag abbilden.
Eine intern gemessene Zahl aus diesem Test sollte die Time to Mitigate sein, also die Zeit bis zur stabilen Umgehung, nicht nur bis zur Ursachenanalyse. Wenn euer gemessener Wert über 60 Minuten liegt, ist das bei kundenrelevanten Plattformen ein Warnsignal, weil Workarounds und Rollbacks dann offenbar nicht vorbereitet sind. Eine weitere Zahl sollte die Alert-Qualität erfassen: Wenn mehr als 30 Prozent der Alarme im Pilotmonat keine Aktion auslösen, trainiert das System Bereitschaftsmüdigkeit, weil Engineers lernen, Warnungen zu ignorieren.
Bei Libraries ist Support oft weniger formal, aber nicht weniger wichtig. Prüfe Release-Frequenz, CVE-Reaktionszeit, Maintainer-Bus-Factor und SemVer-Disziplin. Eine Go-Library, die context.Context ignoriert, ist für produktionsnahe Services problematisch, weil Abbrüche, Deadlines und Trace-Korrelation dann nicht sauber funktionieren. Eine JavaScript-Library ohne ESM/CJS-Kompatibilitätsstrategie erzeugt Deployment-Risiko, weil Build-Tools wie Vite 5, webpack 5 oder esbuild unterschiedlich auf Module reagieren. Eine Terraform-Provider-Version, die mit Terraform 1.9, OpenTofu 1.8 und Provider-Locks in .terraform.lock.hcl nicht sauber dokumentiert ist, erschwert reproduzierbare Infrastruktur, weil Drift dann schwerer einzugrenzen ist.
Auch Lizenz und Exit müssen technisch bewertet werden. Apache 2.0, MIT und BSD-3-Clause sind für viele Plattformteams einfacher zu handhaben als AGPL-3.0, weil Netzwerkbereitstellung und interne Änderungen bei Copyleft-Lizenzen zusätzliche juristische Prüfungen auslösen können. Das ist keine pauschale Ablehnung von Copyleft, sondern eine Betriebsentscheidung, weil unklare Lizenzpflichten Upgrades und Notfall-Forks verzögern können.
Der erste Schritt ist ein Ablehnungstest
Beginne die Evaluation mit einem zweitägigen Ablehnungstest: Build reproduzieren, SBOM erzeugen, Signatur prüfen, Rollback ausführen, Control-Plane-Ausfall simulieren und Support mit einem echten Fehler konfrontieren. Schreibe vorher drei harte Abbruchkriterien auf, etwa fehlender Standardexport, kein dokumentierter Restore oder unklare CRD-Migration. Wer diesen Test besteht, darf in die Feature-Diskussion; wer ihn nicht besteht, hat Produktion noch nicht verdient.
