Was ist Platform Engineering und wann es sich lohnt

Was ist Platform Engineering?

Es ist 22:10 Uhr und ein neuer Entwickler versucht seit zwei Tagen, eine Staging-Umgebung zu bekommen. Er hat drei Tickets eingereicht, denselben Terraform-Fehler zweimal in den Slack kopiert und weiß immer noch nicht, welche von vier CI-Vorlagen die echte ist. Diese Szene ist die gesamte Antwort auf „was ist Platform Engineering": Es ist die Arbeit, den internen gepflasterten Weg zu bauen, damit niemand allein durch diesen Dschungel hacken muss – und diesen Weg wie ein Produkt mit Nutzern zu behandeln.

In der Praxis bauen Platform-Teams eine interne Developer Platform (IDP): Self-Service-Tools, mit denen andere Entwickler Services erstellen, deployen und sehen können, was läuft – ohne auf einen Menschen zu warten. Hier ist, was in der Praxis schiefgeht, wenn man das auslässt: Jedes Team erfindet sein Deployment neu, und das Wissen existiert nur in den Köpfen von drei Personen.

Was Platform Engineering wirklich ist – ohne das Buzzword-Schwindel

Die klarste Definition, die ich kenne, kommt aus der platformengineering.org-Community: Plattformen gestalten und bauen, die Teams Self-Service-Fähigkeiten für die wiederkehrenden Teile ihrer Arbeit geben. Wenn man das Vokabular streicht, bleiben drei Bewegungen übrig.

Erstens die interne Developer Platform. Das ist nicht ein Produkt, das man kauft. Es ist eine dünne Schicht aus Vorlagen, Pipelines, APIs und Dokumentation, die auf den bereits laufenden Tools liegt – Cloud-Account, Kubernetes, CI, Secrets, Monitoring – und die scharfen Kanten versteckt.

Zweitens das Platform-Team. Eine kleine Gruppe von Ingenieuren, deren Kunden andere Ingenieure sind. Ihre Ausgabe ist nicht Features für Endnutzer. Ihre Ausgabe ist, wie schnell alle anderen etwas deployen können.

Drittens eine Product-Mindset. Die Plattform hat Nutzer, ein Backlog, Adoptionszahlen und eine On-Call-Rotation. Wenn niemand sie nutzt, ist sie gescheitert – egal wie elegant die Architektur ist.

Gartner sagte voraus, dass bis 2026 80 % der großen Software-Engineering-Organisationen Platform-Teams haben würden – damals 45 % im Jahr 2022. Behandeln Sie das als Trend-Marker, nicht als Versprechen. Die gleiche Branchendiskussion sagt, dass ein großer Anteil dieser Teams Mühe hat, ihre Wirkung zu zeigen – genau deswegen verbringt der Rest dieses Artikels Zeit damit, was schiefgeht.

Wie unterscheidet es sich von DevOps und SRE?

Kurzversion: DevOps ist eine Kultur, SRE ist eine Zuverlässigkeitsdisziplin, Platform Engineering ist eine Team-Form, die beide produktisiert.

DevOps sagte, dass Entwickler und Operations gemeinsam Verantwortung für das Betreiben von Software übernehmen sollten. Gute Idee. In einer 15-Personen-Firma funktioniert das, weil jeder alles sehen kann. In einer 300-Personen-Firma verwandelt sich das still in „jedes Squad muss auch Kubernetes-Experte werden", was niemand unterschrieben hat.

SRE konzentriert sich auf Zuverlässigkeitsziele: Error Budgets, Incident Response, Kapazität. Ein Platform-Team kümmert sich auch um Zuverlässigkeit, aber seine Hauptmetrik ist anders. Es misst, wie lange ein Dev wartet zwischen „ich habe eine Idee für einen Service" und „er läuft in Production mit Logs und Alerts".

Platform Engineering ist die Antwort auf die kognitive Last, die DevOps hinterlassen hat. Statt von jedem Dev zu verlangen, dass er die ganze Toolchain lernt, gibt man ihm einen unterstützten Default und hält das Experten-Know im Platform-Team. Drei Gründe dafür, ein Grund dagegen: Es zahlt sich nur aus, wenn die Zahl der Teams oder Services groß genug ist, dass Duplizierung weh tut. Dazu kommen wir später.

Was liefert ein Platform-Team wirklich ab?

Vergessen Sie die Architektur-Diagramme. So sieht das Backlog eines funktionierenden Platform-Teams an einem normalen Dienstag aus.

Eine Service-Vorlage. Ein Befehl oder ein Button in einem Portal erstellt ein Repository mit einer funktionierenden Pipeline, einem Dockerfile, Health Checks, einem Logging-Setup und einem einfachen Dashboard. Der Dev ändert die Business Logic, nicht die Rohre.

Ein Deploy-Weg. Push zu Main, Tests laufen, das Artefakt wird gebaut und durch Umgebungen mit den gleichen Schritten jedes Mal befördert. Keine Pro-Team-Schneeflocken.

Umgebung auf Abruf. Eine Preview-Umgebung pro Pull Request, automatisch gelöscht. Das ist das Feature, für das Entwickler dir danken.

Secrets und Zugriff. Kurzlebige Credentials, ein Ort zum Anfragen, eine Audit-Spur. Langweilig, und das, was dir in einem Security-Review den Rücken rettet.

Observability standardmäßig. Jeder Service aus der Vorlage kommt mit Metriken, Logs und Traces ohne dass jemand sie verkabelt. Ein Stack wie Grafana sitzt normalerweise hinter dieser Schicht und die kostenlose Version und Open-Source-Option passen zu einem kleinen Team.

Beachten Sie, was auf dieser Liste fehlt: ein benutzerdefiniertes Portal mit einer Drei-Monats-Roadmap. Das Portal ist das Letzte, das man hinzufügt, nicht das Erste.

Golden Paths: die Idee, die alles andere zum Laufen bringt

Ein Golden Path ist der unterstützte, gut durchdachte Weg, um eine häufige Aufgabe zu erledigen. Er ist schneller als manuell und sicherer als zu improvisieren, und entscheidend ist: er ist optional. Entwickler können den Weg verlassen, wenn sie einen echten Grund haben. Sie übernehmen nur die Verantwortung, die damit kommt.

Es gibt eine nützliche Unterscheidung im Octopus-Write-up zu gepflasterten versus Golden Paths: Eine gepflasterte Straße ist die breite, gut gepflegte Oberfläche, während ein Golden Path die spezifische empfohlene Route für einen Job ist. In meiner Erfahrung ist der Unterschied weniger wichtig als das Prinzip darunter. Man gewinnt, indem man die richtige Weise zur einfachen Weise macht, nicht durch das Verbieten der anderen Weisen.

So sieht der kleinste mögliche Golden Path aus. Es ist ein einziger Scaffold-Befehl, den ein Dev einmal laufen lässt:

platform new service payments-api \
  --template node-api \
  --env preview,staging,prod \
  --owner team-checkout

Hinter dieser einen Zeile sitzen ein Repo, eine Pipeline, DNS, ein Datenbank-Stub, Alerts und ein Ownership-Datensatz. Der Befehl ist trivial. Der harte Teil ist die sechs Monate Einigung darüber, was „node-api" bedeutet, und die aktuelle Haltung wenn Node, dein Base-Image oder dein Cloud-Provider sich ändert.

Getestet, nicht optimal, und hier ist, warum wir es trotzdem tun: Ein mittelmäßiger Golden Path, den 80 % der Teams nutzen, schlägt einen perfekten, den 10 % übernehmen, weil der erste dir die Hebelwirkung gibt, um alles auf einmal zu verbessern.

Wann ist es sinnvoll, und wann ist es eine Ablenkung?

Das ist die Sektion, die die meisten Posts überspringen. Platform Engineering ist nicht kostenlos, und für viele Teams ist es die falsche Bewegung.

Das platformengineering.org-Übersicht legt nahe, dass Organisationen typischerweise anfangen, von etwa 20 bis 30 Platform-Nutzern zu profitieren. Ich würde das als eine grobe Untergrenze lesen, nicht als Regel. Darunter werden ein geteiltes README, eine gute CI-Vorlage und eine Person, die sich kümmert, mehr tun als ein formales Platform-Team.

Es lohnt sich, wenn:

• Du hast mehr als eine Handvoll Teams, und jedes hat seine eigene Deploy-Pipeline gebaut

• Neue Devs brauchen Wochen, keine Tage, um ihre erste Änderung zu deployen

• Der gleiche Incident-Typ wiederholt sich, weil jeder Service seine eigenen Alerts verkabelt hat

• Sicherheit oder Compliance verlangt Konsistenz, die du nicht durch Fragen bekommst

Überspringe es, wenn:

• Du bist ein Team von fünf. Schreib ein Skript, nicht eine Plattform

• Du weißt noch nicht, wie deine Services aussehen. Zu früh standardisieren friert die falschen Entscheidungen ein

• Der Vorschlag ist „baue ein Portal" ohne Liste von Schmerzen, die es abbaut

Für Einzelne Builder und kleine Side-Project-Crews ist die ehrliche Schlussfolgerung simpler. Du brauchst kein Platform-Team, aber du brauchst die Gewohnheiten: ein wiederholbares Deploy-Skript, eine Vorlage für neue Projekte, ein Dashboard, das du checkst. Das ist eine Plattform von Eins, und sie wird dir jeden Monat ein Wochenende sparen.

Die Tools, die Menschen wirklich kombinieren

Es gibt kein einzelnes „Platform-Engineering-Produkt". Teams bauen einen Stack zusammen, und die Teile fallen in ein paar Buckets.

Für das Portal und den Katalog nutzen viele Teams Backstage oder eine gehostete Alternative, was eine durchsuchbare Liste von Services, Eigentümern und Dokumentation gibt. Zum Provisioning Terraform oder OpenTofu plus ein GitOps-Tool wie Argo CD oder Flux. Für CI und Delivery, was du bereits hast, verpackt in gemeinsamen Vorlagen.

Zwei Buckets verdienen einen näheren Blick, weil sie entscheiden, ob sich die Plattform vertrauenswürdig anfühlt.

Observability. Wenn Entwickler nicht sehen können, was ihr Service tut, werden sie der Plattform nicht trauen, die ihn deployt hat. Datadog gibt dir ein poliertes Single Pane über Infra, APM und Logs, zu einem Pro-Host-Preis, der schnell wächst. Grafana's Open-Source-Stack kostet dir Operationszeit statt Lizenzen. Wähle basierend darauf, ob deine knappe Ressource Geld oder Aufmerksamkeit ist.

Dokumentation und Qualität. Eine Plattform ohne gute Dokumente ist eine Ticket-Warteschlange in Verkleidung. Docs-as-Code-Tools halten Guides neben dem Repo, den sie beschreiben, und Code-Quality-Gates in CI halten die Vorlagen ehrlich.

Keines davon ist erforderlich. Sie sind Beispiele der Schicht, wo ein Platform-Team seine Zeit verbringt: einen Default auswählen, ihn in die Vorlage verkabeln und den Upgrade-Weg besitzen.

Wie man anfängt, ohne das Falsche zu bauen

Die meisten fehlgeschlagenen Platform-Bemühungen teilen das gleiche Muster. Sie fangen zu groß an, bauen für Monate bevor ein einziges Team es anfasst, und optimieren für die Roadmap-Folie statt für Adoption. Die Lösung ist unglamourös.

Wähle eine Aufgabe, die schmerzhaft und häufig ist. „Erstelle einen neuen Service" und „bekommen Sie eine Preview-Umgebung" sind die üblichen Sieger. Interview drei Entwickler und beobachte sie dabei. Zähle die Schritte und die Minuten.

Baue die dünnste Version, die das meiste Schmerz abzieht. Ein Template-Repo und eine gemeinsame Pipeline-Datei zählen. Gib es einem freundlichen Team und sitze neben ihnen während sie es nutzen. Repariere, was bricht, dann biete es einem zweiten Team an.

Verfolge zwei Zahlen: wie lange von „neuer Service" bis „läuft in Production", und wie viele Teams nutzen den Weg freiwillig. Wenn die zweite Zahl flach ist, ist die Plattform ein Mandat, und Mandate verfallen.

Treibe es wie ein Product-Team an. Platform-Ingenieure sind nicht DevOps mit neuem Titel. Das platformengineering.org-Material merkt an, dass Platform-Ingenieure etwa 27 % mehr verdienen als DevOps-Profis, was dir sagt, dass der Markt die Product-und-Engineering-Mischung als einen unterschiedlichen, schwierigeren Job sieht.

Ein weiterer Grund, das jetzt zu tun: Die neueste Wendung ist, dass der „Nutzer" einer Plattform nicht mehr nur ein Mensch ist. Coding-Agenten öffnen Pull Requests, führen Tests aus und fragen nach Umgebungen. Eine Plattform mit sauberen Vorlagen, klaren Berechtigungen und maschinenlesbarer Dokumentation ist ein viel sichererer Ort für einen Agenten als ein Haufen Schneeflocken-Repos.

Kurzlebige Credentials, Preview-Umgebungen und eine konsistente Pipeline sind das, was die Fehler eines Agenten auf einen disposablen Zweig beschränkt. Wenn deine Plattform einen menschlichen Deploy nicht von einem automatisierten unterscheiden kann, füge das hinzu, bevor du etwas anderes hinzufügst.

Was solltest du als Nächstes bauen?

Wenn du ein Team von 30 Devs leitest und jedes Squad hat seine eigene Pipeline, ist ein kleines Platform-Team mit einem Golden Path wahrscheinlich deine höchst-Hebel-Einstellung. Wenn du ein Solo-Dev mit drei Side-Projekten bist, kopiere die beste Pipeline deines Projekts in ein Template-Repo dieses Wochenende und nenne es fertig.

Wie auch immer, die Frage, die es wert ist, zu deiner nächsten Planning-Sitzung zu bringen, ist konkret: Welche einzelne Aufgabe wiederholen deine Entwickler am meisten, und was würde es kosten, sie zu einem Ein-Befehl-Job zu machen?