Welche Internal Developer Platform passt zu Ihrem IT-Team?

Ob Backstage, Port oder Cortex zu Ihnen passt, hängt vor allem daran, wer die Plattform in zwei Jahren noch pflegt. Wir vergleichen die Optionen an Ihrer Toolchain und begleiten den Aufbau mit GitOps und SRE-Praxis, von Puchheim bei München aus für IT-Unternehmen im DACH-Raum.

Erstgespräch buchen Whitepaper herunterladen

SEIT 2006 · 47+ PROJEKTE · IT · ECOMMERCE · FINANCE · PLATFORM ENGINEERING

Aktualisiert · 2026-09-29//Autor · Andreas Schönfeld, Comquent GmbH//Lesezeit · 14 min//Backstage 1.55 · ArgoCD 3.5 · Flux 2.9 · Kubernetes 1.37//Standort · Puchheim bei München

Wie skaliert man DevOps mit Platform Engineering?

Platform Engineering skaliert DevOps, indem ein dediziertes Platform-Team eine Internal Developer Platform (IDP) bereitstellt: Golden Paths, Self-Service-APIs und standardisierte Templates. Entwickler erhalten Environments, Pipelines und Deployments auf Knopfdruck. Die kognitive Last sinkt, die Developer Experience steigt, und DevOps-Praktiken tragen über 10, 20 oder 50 Teams statt nur im Pilotteam. Als IDP-Basis kommen Backstage, Port oder Cortex infrage; welche davon passt, entscheidet die verfügbare Engineering-Capacity, nicht der Hype.

Direkt zum Vergleich Backstage, Port und Cortex

// Einordnung

Diese Seite steht bei den Industrial-DevOps-Anwendungsfällen, obwohl hier keine Maschine steht. Der Grund ist der gemeinsame Kern: Ob ein Team einen Softwarestand auf ein Steuergerät, auf eine Fertigungslinie oder in ein Kubernetes-Cluster bringt, die Reihenfolge bleibt dieselbe. Versionieren, automatisiert testen, nachvollziehbar freigeben, kontrolliert ausrollen.

Unterschiedlich ist der Preis eines Fehlers. Ein fehlgeschlagenes Deployment rollt zurück, eine fehlerhaft geflashte Steuerung hält die Linie an. Deshalb kennt die IT-Seite Canary und Error Budgets, die OT-Seite Wartungsfenster und Approval-Gates. In Unternehmen, die beides haben, etwa bei Zulieferern mit eigener Fertigung, treffen die zwei Kulturen aufeinander. Für diesen Fall lohnt der Blick auf Fertigung und Maschinenbau gleich mit.

// 02Herausforderungen

Was bremst
wachsende IT-Teams?

An diesen Stellen bleiben Projekte in dieser Branche am häufigsten hängen. Wie wir sie angehen, steht im nächsten Abschnitt.

/01
Tool-Wildwuchs
Jenkins im einen Team, GitHub Actions im nächsten, dazwischen ein CircleCI-Projekt, das keiner mehr anfassen will. Jede dieser Pipelines hat eigene Konventionen, eigene Secrets und einen eigenen Wartungsweg. Was das kostet, merkt man meist zum ungünstigsten Zeitpunkt, nämlich wenn der Kollege kündigt, der als Einziger wusste, warum der Release-Job seit drei Jahren diesen einen Groovy-Block braucht.
/02
Langsame Cloud-Migration
Der Umzug in die Cloud ist beschlossen, kommt aber nicht voran. Die alten Anwendungen lassen sich schwer in Container packen, niemand hat die Netzwerkabhängigkeiten vollständig aufgeschrieben, und im Team fehlt die Erfahrung mit Kubernetes im Betrieb.
/03
Fehlende Internal Developer Platform
Eine neue Testumgebung ist ein Ticket, und das Ticket liegt eine Woche. Entwickler verbringen mehr Zeit mit Infrastruktur als mit Features, weil es weder Self-Service noch Vorlagen gibt und keine Stelle, an der steht, welcher Service wem gehört.
/04
DevOps-Skalierung über Teams
Im Pilotteam funktioniert DevOps. Bei zehn, zwanzig oder fünfzig Teams kippt es, weil gute Lösungen in dem Team bleiben, in dem sie entstanden sind, verbindliche Regeln fehlen und jedes Team seine Pipeline wieder von vorn baut.

// 03Unser Ansatz

Wie wird aus Wildwuchs eine
Plattform?

Vier Schritte, die wir in dieser Reihenfolge gehen. Der erste bringt noch keine Pipeline, sondern Klarheit darüber, welcher Softwarestand heute wo läuft.

Schritt / 01

Toolchain ordnen

Wir erfassen, welche CI/CD-Werkzeuge heute wo laufen und was jedes davon an Pflege kostet, und bewerten sie nach Team-Fit, Skalierbarkeit und Wartbarkeit. Danach führen wir die Teams auf eine gemeinsame Plattform und migrieren die Pipelines mit, statt sie ihnen als Hausaufgabe zu überlassen.

Schritt / 02

Cloud in Etappen

Der Umzug läuft von On-Premise über einen hybriden Betrieb in die Cloud, Anwendung für Anwendung. Jede Anwendung prüfen wir vorher auf Container-Tauglichkeit, danach folgen Kubernetes und der schrittweise Wechsel, ohne dass der laufende Betrieb stehen bleibt.

Schritt / 03

Plattform mit Self-Service

Wir bauen die Internal Developer Platform mit Self-Service-Portal, Vorlagen für neue Services, automatisch bereitgestellten Umgebungen und eingebauter Observability. Als Portal kommen Backstage, ein gehostetes Backstage oder Port infrage, je nachdem, wie viel Engineering-Kapazität Sie dauerhaft dafür haben. Ob sich das gelohnt hat, sehen Sie an dem Tag, an dem ein neues Team seinen Service selbst anlegt und vor der Mittagspause deployt, ohne Ticket und ohne Rückfrage bei der Plattform-Mannschaft.

Schritt / 04

Teams mitnehmen

Wir bilden interne Trainer aus, bauen eine Community of Practice auf und legen zentrale Regeln fest, die jedes Team selbst umsetzt. Den Fortschritt machen wir an DORA-Kennzahlen fest und gehen sie regelmäßig mit Ihnen durch.

// 04Ergebnisse

Was ändert sich
messbar?

Messgröße

Vorher

Nachher

Ergebnis

/01

Deployment-Frequenz

Wöchentlich

10× höher

→

/02

Lead Time for Changes

Wochen

−75 %

→

/03

Zufriedenheit im Entwicklerteam

Niedrig

+40 %

→

/04

Onboarding neuer Entwickler

Wochen

Tage

→

/05

Pipeline-Wartungsaufwand

Hoch

Minimal

→

/06

Environment-Bereitstellung

Tage

Minuten

→

// 05Technologien

Welche Tools gehören in den
Stack?

Womit wir in diesem Umfeld arbeiten. Die Auswahl richtet sich nach der Toolchain, die bei Ihnen schon läuft, nicht nach unserer Präferenz.

/01

GitLab CI

/02

GitHub Actions

/03

Kubernetes

/04

Terraform

/05

ArgoCD

/06

Flux

/07

Backstage

/08

Port

/09

Cortex

/10

OpenTelemetry

/11

Prometheus

/12

Grafana

/13

Docker

/14

Helm

/15

Kustomize

/16

Vault

/17

AWS / Azure / GCP

/18

Crossplane

// 06 — Nächster Schritt

Erst planen, dann bauen?

Lassen Sie uns sprechen. In einem kostenlosen Erstgespräch klären wir, wie wir Ihre spezifischen Herausforderungen lösen können.

Erstgespräch buchen→→ Reifegrad-Check starten

// 07Internal Developer Platforms

Backstage, Port
oder Cortex?

Eine Internal Developer Platform soll Entwicklern Arbeit abnehmen: weniger kognitive Last, schnelleres Onboarding, Self-Service statt Ticket-Queue. Welches Portal das leistet, hängt an Ihrer Engineering-Kapazität und am Reifegrad der Teams. Wie sich Platform Engineering von DevOps abgrenzt, zeigt unser Vergleich DevOps vs. Platform Engineering.

Tool

Stärken

Aufwand

Passt zu

/01

Backstage

Eigenbetrieb

Open Source als CNCF-Incubating-Projekt, größte Plugin-Auswahl, vollständig anpassbar, Software-Katalog und TechDocs

Hoch: eigene Anwendung bauen, hosten und aktualisieren, Plugins pflegen

Konzerne, dauerhaft finanzierte Platform-Teams

/02

Backstage gehostet

Spotify Portal · Roadie · Harness IDP

Backstage-Katalog und Plugins, Betrieb und Upgrades übernimmt der Anbieter

Mittel: Katalog, Integrationen und eigene Plugins bleiben bei Ihnen

Teams, die Backstage wollen, aber keinen eigenen Betrieb

/03

Port

SaaS

Einführung in Tagen, starke Self-Service-Oberfläche, Free-Plan bis 15 Nutzer

Niedrig: Datenmodell und Integrationen, kein eigener Betrieb

Mittelstand, schnelle Einführung

/04

Cortex

SaaS

Scorecards für Service-Reife, Production-Readiness-Prüfungen, Engineering-Kennzahlen

Mittel: Integrationen, Standards definieren, Daten pflegen

Reife Organisationen, die Standards durchsetzen wollen

Stand 29.09.2026 · Quellen: Port Pricing · CNCF Backstage

Welche Vor- und Nachteile hat Backstage?

Backstage punktet mit Open Source, der größten Plugin-Auswahl aller Developer Portals und einem Software-Katalog, der Templates und TechDocs aus einem Guss liefert. Sein Nachteil ist derselbe Umstand aus anderer Richtung: Es ist ein Framework, kein Produkt. Wer es einsetzt, entwickelt, hostet und aktualisiert eine eigene Anwendung. Für die Developer Experience entscheidet deshalb nicht die Funktionsbreite, sondern ob ein Platform-Team den Katalog dauerhaft pflegt.

Vorteile

/01Open Source als CNCF-Incubating-Projekt, keine Lizenzkosten pro Entwickler
/02Größte Auswahl an Backstage-Plugins: CI/CD-Status, Kubernetes, Kosten und Security-Findings in einer Oberfläche
/03Software-Templates erzeugen Repository, Pipeline und Standardkonfiguration per Klick
/04TechDocs hält die Dokumentation als Markdown neben dem Code statt in einem vergessenen Wiki

Nachteile

/01Framework statt Produkt: eigene Anwendung in TypeScript und React, die gebaut, gehostet und aktualisiert werden muss
/02Plugin-Pflege: Upgrades brechen Community-Plugins, eigene Plugins binden Engineering-Kapazität
/03Ein leerer oder veralteter Katalog schadet der Developer Experience mehr als gar kein Portal
/04Realistischer Eigenbetrieb: etwa zwei Vollzeit-Engineers dauerhaft, darunter sind Port oder ein gehostetes Backstage meist günstiger

Welche Alternativen zu Backstage gibt es?

Eine Platform-Engineerin gleicht eine ausgedruckte Service-Liste mit dem Software-Katalog am Monitor ab, ein Kollege zeigt auf eine Zeile mit orangem Status — Der Katalog ist nur so gut wie seine Pflege. Ohne feste Zuständigkeit veraltet er in wenigen Monaten, mit welchem Tool auch immer.

Wer eine Alternative zu Backstage sucht, will meist weniger Betriebsaufwand, selten mehr Funktionen. Dafür gibt es inzwischen zwei Wege. Der erste bleibt bei Backstage und gibt nur den Betrieb ab: Spotify Portal for Backstage, Roadie und das Harness IDP liefern Katalog und Plugins als Dienst. Der zweite wechselt das Werkzeug. Port bringt Self-Service-Kataloge als SaaS, Cortex setzt den Schwerpunkt auf Service-Reife und Standards, und OpsLevel verbindet Katalog und Reifegrad-Prüfungen.

Backstage im Eigenbetrieb bleibt die richtige Wahl, wenn Sie ein Platform-Team dauerhaft finanzieren und die Plattform tief in bestehende Systeme integrieren wollen. Vor der Toolwahl lohnt deshalb eine andere Frage als die nach dem Funktionsumfang: Wer pflegt das Ding in zwei Jahren?

Wann Port, wann Cortex?

Port passt, wenn Entwickler vor allem Self-Service brauchen. Umgebung anlegen, Service erzeugen, Berechtigung anfragen: Das läuft über Formulare und Automationen im Portal, und der Free-Plan bis 15 Nutzer macht den Einstieg billig. Cortex passt, wenn das Problem weniger der Weg zum Service ist als die Frage, wem ein Service gehört und ob er den Produktionsstandards genügt. Seine Scorecards zeigen Service Ownership und Production Readiness pro Team.

Port hat inzwischen ebenfalls Scorecards, Cortex eigene Self-Service-Workflows. Der Schwerpunkt der beiden bleibt trotzdem gut erkennbar, und viele Organisationen brauchen erst das eine und zwei Jahre später das andere.

Welche Rolle spielen KI-Agenten?

Arbeitsplatz mit zwei Monitoren: links ein Code-Diff mit einer grün und einer orange markierten Zeile, rechts der Katalogeintrag eines Services mit seinem Owner — Links der Diff, rechts der Katalogeintrag, aus dem der Agent seine Annahmen nimmt. Stimmt der Eintrag nicht, stimmt der Diff auch nicht.

Alle genannten Anbieter haben sich 2025 und 2026 auf KI-Agenten ausgerichtet. Port nennt sich inzwischen „Agentic Engineering Platform“, Spotify bewirbt sein Portal als Quelle für „engineers and agents“, Roadie als „Engineering Context for AI Agents“.

Hinter dem Etikett steckt ein nüchterner Gedanke, den wir teilen. Ein Coding-Agent, der einen Service ändern soll, braucht dieselben Antworten wie ein neuer Kollege: Wem gehört der Service, welche Pipeline baut ihn, welche Standards gelten? Steht das im Katalog, liest der Agent es nach. Fehlt es oder ist es veraltet, rät er, und zwar mit großer Überzeugung. Ein gepflegter Katalog war bisher eine Frage der Developer Experience. Sobald Agenten im Team mitarbeiten, entscheidet er mit darüber, ob deren Änderungen stimmen.

By 2026, 80 % of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components and tools for application delivery.

— Gartner, Prognose von 2023. Das Zieljahr ist jetzt.

// 08GitOps für Platform Teams

Wie läuft GitOps
im Platform-Team?

GitOps macht Git zur einzigen Quelle der Wahrheit für Cluster und Deployments. Ein Reconciler vergleicht den Live-Zustand laufend mit dem Stand im Repository und korrigiert Abweichungen selbst.

Für ein Platform-Team heißt das weniger kubectl von Hand und eine lückenlose Spur jeder Änderung. Als Reconciler kommen ArgoCD und Flux infrage. ArgoCD bringt die stärkere Oberfläche und ApplicationSets für viele Cluster mit, Flux ist schlanker und API-zentriert. Den ausführlichen Vergleich finden Sie unter ArgoCD vs. Flux. Wir bauen beide produktionsreif auf.

/01
App-of-Apps und ApplicationSets
Eine Root-App synchronisiert die Plattform-Ebene, ApplicationSets erzeugen daraus Hunderte Anwendungen deklarativ, etwa eine Variante pro Mandant oder Cluster.
/02
Progressive Delivery mit Argo Rollouts
Canary- und Blue-Green-Rollouts mit automatischer Analyse gegen Prometheus- oder Datadog-Metriken. Fällt eine Kennzahl durch, rollt Argo Rollouts selbst zurück, bevor alle Nutzer die neue Version sehen.
/03
Infrastruktur per Self-Service mit Crossplane
Crossplane bildet Cloud-Ressourcen als Kubernetes-Objekte ab. Ein Team legt seine Datenbank als YAML-Datei ins Repository, ArgoCD synchronisiert sie, Crossplane legt sie beim Cloud-Anbieter an. Welche Varianten erlaubt sind, legt das Platform-Team in einer Composition fest, und die Infrastruktur läuft durch denselben Review wie der Code.
/04
Secrets, Policies und signierte Images
Der External Secrets Operator holt Geheimnisse aus Vault, Kyverno- oder OPA-Policies prüfen jedes Manifest, bevor es im Cluster ankommt, und Sigstore/cosign signiert die Images. Die Prüfspur steht im Pipeline-Log.
/05
Mandanten und Skalierung
AppProjects mit RBAC pro Team, aufgeteilte Repo-Server und hochverfügbare ArgoCD-Controller, erprobt in Setups mit mehr als 50 Teams und über 1.000 Workloads.

ArgoCD & GitOps Workshop mit KI

// 09Site Reliability Engineering

Woran misst ein
Platform-Team Stabilität?

SRE macht Verfügbarkeit zu einer Abmachung zwischen Produkt- und Platform-Team, die sich messen lässt. Ohne sie verhandelt jedes Release aufs Neue, was „stabil genug“ bedeutet, und DevOps skaliert nicht.

/01 · SLI / SLO

Indikator und Ziel

Service Level Indicators wie Erfolgsrate oder Latenz im 99. Perzentil liefern die Daten. Service Level Objectives setzen das Ziel über ein rollierendes Fenster, etwa 99,9 % über 28 Tage. Den SLO-Review verankern wir als festen Termin in jedem Quartal.

Glossar: SRE

/02 · Error Budget

Lizenz zum Risiko

Die Differenz zwischen 100 % und dem SLO ist das Error Budget. Solange es reicht, darf das Team ausrollen und experimentieren. Ist es aufgebraucht, stellt das Team auf Stabilisierung um, und darüber muss niemand mehr diskutieren.

Glossar: Error Budget

/03 · Toil

Höchstens die Hälfte

Toil ist wiederkehrende, manuelle Betriebsarbeit, die sich automatisieren ließe. Google gibt seinen SRE-Teams das Ziel vor, unter 50 % Toil zu bleiben. Wir messen den Anteil als Pflichtkennzahl und automatisieren zuerst, was die meiste Zeit frisst.

Glossar: Toil

Quelle 50-%-Grenze: Google SRE Book, Eliminating Toil

SRE vs. DevOps: wo liegt der Unterschied?

Vier Personen in einem kleinen Besprechungsraum vor einem Bildschirm mit einer fallenden Kurve, deren Endpunkt orange markiert ist; ein Engineer erklärt, eine Kollegin schreibt mit — Quartals-Review: Das Error Budget ist fast aufgebraucht, das nächste Release wartet. Die Entscheidung dauert Minuten, weil die Regel vorher feststand.

DevOps beschreibt die Kultur, Site Reliability Engineering die konkrete Engineering-Praxis. Google fasst das in den Satz „class SRE implements DevOps“. DevOps sagt, dass Entwicklung und Betrieb gemeinsam Verantwortung tragen. SRE beantwortet die Anschlussfrage, woran man das misst: SLIs als Indikatoren, SLOs als Ziele, Error Budgets als Regel für die Frage „ausrollen oder stabilisieren?“. Die beiden konkurrieren also nicht. Ein Platform-Team ohne SRE-Praxis hat DevOps als Haltung, aber keine Zahlen, mit denen sich ein Konflikt zwischen Tempo und Stabilität sachlich klären lässt.

// 10Häufige Fragen

Was Entscheider
wirklich fragen.

Elf Fragen, die in Erstgesprächen mit IT-Leitern zuverlässig kommen, von der Toolwahl über die Begriffe bis zur Migration.

Q.01Backstage vs. Port vs. Cortex: welche Internal Developer Platform passt?: Backstage ist der Open-Source-Standard mit der größten Plugin-Auswahl, braucht aber ein eigenes Team für Aufbau und Pflege. Port ist eine SaaS-IDP mit kurzer Einführungszeit und Schwerpunkt auf Self-Service und Software-Katalog, ohne eigene Infrastruktur. Cortex macht Service-Reife und Engineering-Standards mit Scorecards messbar. Unsere Faustregel: Mit dauerhaft verfügbarer Engineering-Kapazität Backstage, für eine schnelle Einführung ohne eigenes Platform-Team Port oder ein gehostetes Backstage wie Spotify Portal oder Roadie, und wenn Sie vor allem Service-Reife messen wollen, Cortex. Welche Variante bei Ihnen trägt, prüfen wir an Ihrer Toolchain.
Q.02Was sind die Vor- und Nachteile von Backstage für Platform Engineering und Developer Experience?: Vorteile von Backstage: Open Source (CNCF), die größte Plugin-Auswahl aller Developer Portals, Software-Katalog, Software-Templates und TechDocs aus einem Guss, vollständig anpassbar und ohne Lizenzkosten. Nachteile: Backstage ist ein Framework, kein Produkt. Sie entwickeln, hosten und aktualisieren eine eigene Anwendung, Plugins brechen bei Upgrades, und ohne ein dauerhaft finanziertes Platform-Team veraltet der Katalog innerhalb weniger Monate. Für die Developer Experience zählt deshalb weniger die Funktionsbreite als die Pflege: Ein halb gefülltes Portal schadet mehr als gar keins. Faustregel: ab etwa zwei Vollzeit-Engineers für die Plattform lohnt sich Backstage im Eigenbetrieb; darunter ist eine SaaS-IDP wie Port oder ein gehostetes Backstage meist die bessere Wahl.
Q.03Welche Vorteile hat Port gegenüber Cortex für Platform-Engineering-Teams?: Port ist beim Self-Service stärker: Entwickler legen Services, Umgebungen oder Berechtigungen über Formulare und Automationen im Portal selbst an, und ein Free-Plan bis 15 Nutzer senkt die Einstiegshürde. Cortex ist stärker, wenn es um Service Ownership und Production Readiness geht, denn seine Scorecards zeigen pro Team, welche Services die vereinbarten Standards erfüllen. Für die Developer Experience im Alltag liegt Port meist vorn, für das Durchsetzen von Standards in einer großen Organisation Cortex.
Q.04Platform Engineering vs. DevOps: was ist der Unterschied?: DevOps beschreibt Kultur und Prinzipien: gemeinsame Verantwortung von Entwicklung und Betrieb, Automatisierung, kurze Feedbackschleifen. Platform Engineering ist die organisatorische Antwort darauf, sobald viele Teams beteiligt sind. Ein eigenes Platform-Team baut die Internal Developer Platform, mit der alle anderen Teams DevOps-Praktiken anwenden können, ohne selbst tiefes Infrastrukturwissen aufzubauen. Kurz gesagt ist DevOps das Ziel und Platform Engineering der Weg, der auch bei fünfzig Teams noch trägt.
Q.05Was ist Platform Engineering?: Platform Engineering ist die Disziplin, interne Entwicklerplattformen zu entwerfen und zu betreiben. Platform-Teams bauen Golden Paths, Self-Service-APIs und Vorlagen, mit denen andere Teams produktiv arbeiten, ohne die Infrastruktur im Detail kennen zu müssen. Gartner hatte 2023 vorhergesagt, dass bis 2026 80 % der großen Softwareentwicklungsorganisationen eigene Platform-Engineering-Teams aufbauen.
Q.06Was ist eine Internal Developer Platform?: Eine Internal Developer Platform (IDP) ist eine Self-Service-Schicht, die Entwicklern Infrastruktur, CI/CD-Pipelines, Monitoring und Deployment auf Knopfdruck bereitstellt. Sie nimmt den Teams die Infrastrukturdetails ab, damit sie sich auf die Produktentwicklung konzentrieren können. Das Portal, also Backstage, Port oder Cortex, ist nur die Oberfläche dieser Plattform.
Q.07Was ist ein Golden Path?: Ein Golden Path ist der vom Platform-Team kuratierte Weg für eine wiederkehrende Aufgabe, etwa einen neuen Microservice aufzusetzen: Vorlage, CI/CD-Pipeline, Observability und Security-Standards inklusive. Golden Paths sind ein Angebot, kein Zwang. Teams, die dem Standard folgen, sind in Minuten produktiv, begründete Abweichungen bleiben möglich. Spotify hat den Begriff geprägt, Netflix nennt dasselbe Prinzip Paved Road. Golden Paths sind das wichtigste Werkzeug, um Standardisierung und Team-Autonomie gleichzeitig zu erreichen, und damit die Basis guter Developer Experience.
Q.08Was ist GitOps für Platform Teams, und wann ArgoCD statt Flux?: GitOps macht Git zur einzigen Quelle der Wahrheit für Cluster, Helm-Releases und Konfigurationen. Ein Reconciler, ArgoCD oder Flux, gleicht den Live-Zustand laufend mit dem Soll-Zustand im Repository ab und synchronisiert bei Abweichungen automatisch. ArgoCD bietet eine starke Oberfläche, das App-of-Apps-Muster und ApplicationSets für viele Cluster. Flux ist API-zentrierter, schlanker, lässt sich über seinen Notification-Controller gut anbinden und passt gut zu GitLab und SOPS. Wir setzen beide ein; die Wahl hängt vom Betriebsmodell und der gewünschten Mandantentrennung ab.
Q.09Was sind SLOs, Error Budgets und Toil, die SRE-Grundbegriffe?: Site Reliability Engineering (SRE) übersetzt Verfügbarkeit in messbare Abmachungen. SLIs sind Indikatoren wie Erfolgsrate oder Latenz, SLOs sind Ziele wie 99,9 % über 28 Tage, und das Error Budget ist das erlaubte Fehlerkontingent dazwischen. Toil ist wiederkehrende, automatisierbare Betriebsarbeit, die nach der Vorgabe von Google unter 50 % der SRE-Zeit bleiben soll. Wir führen SLO-Reviews, Regeln für ein aufgebrauchtes Error Budget und automatisierte Runbooks für Platform-Teams ein.
Q.10Wann lohnt sich eine Tool-Konsolidierung?: Eine Tool-Konsolidierung lohnt sich, wenn Teams unterschiedliche CI/CD-Tools nutzen, die Wartungskosten steigen, das Wissen auf einzelne Personen verteilt ist und es keine gemeinsamen Standards gibt. Typische Migrationspfade führen von Jenkins zu GitLab CI oder Azure DevOps, wobei wir die Pipelines weitgehend automatisiert übertragen.
Q.11Wie funktioniert eine Cloud-Migration mit DevOps?: Eine Cloud-Migration mit DevOps läuft in Iterationen: Die Workloads werden priorisiert, Infrastructure as Code beschreibt die Zielarchitektur, CI/CD-Pipelines automatisieren den Umzug, und Tests sichern jeden Schritt ab. Der Übergang von On-Premise über einen hybriden Betrieb in die Cloud erfolgt schrittweise, damit der laufende Betrieb nicht leidet.