Guides

Was ist Platform Engineering — und warum jetzt?

Was Platform Engineering wirklich bedeutet, was ohne sie schiefläuft und wie sie auf DevOps aufbaut.

André Loreth··4 Min. Lesezeit
Teilen
Abstrakte isometrische Illustration einer geschichteten Plattform, auf der mehrere kleine, unabhängige Knotenpunkte frei stehen.

Ein Begriff, der mehr Fragen aufwirft als er beantwortet

Platform Engineering klingt nach einem weiteren Buzzword aus der Entwickler-Welt, direkt neben DevOps, SRE und Cloud-Native. Für ein Unternehmen, das gerade wachsen will und dessen Fokus auf dem eigenen Geschäft liegt, nicht auf Entwickler-Tooling, ist der Begriff wenig hilfreich, wenn niemand erklärt, was dahintersteckt. Deshalb einmal ohne Fachjargon: Platform Engineering ist die Praxis, eine interne Plattform zu bauen, mit der dein Entwicklungsteam Software zuverlässig und eigenständig ausliefert, ohne bei jedem Schritt auf eine einzelne Person angewiesen zu sein.

Was ohne Platform Engineering passiert

Die meisten Unternehmen stolpern nicht über die Idee, sondern über drei sehr konkrete Symptome.

Das erste: Jedes Deployment braucht dieselbe eine Person, weil sonst niemand weiß, wie es geht. Das funktioniert, solange diese Person verfügbar ist. Ist sie im Urlaub, krank oder einfach ausgelastet, steht die Auslieferung still, unabhängig davon, wie fertig eine Änderung ist.

Das zweite: Neue Entwickler brauchen Wochen, bis ihre erste Änderung produktiv läuft. Nicht, weil sie schlecht programmieren, sondern weil niemand den Weg von der Änderung bis in Produktion dokumentiert oder vereinheitlicht hat. Jeder neue Kollege lernt den Weg wieder von jemand anderem im Kopf.

Das dritte: Monitoring und Bereitschaft laufen nebenher, weil niemand explizit dafür zuständig ist. Ein Fehler in Produktion fällt auf, wenn ein Kunde sich meldet, nicht, weil ein System Alarm geschlagen hat.

Keins dieser drei Symptome bedeutet, dass dein Team schlecht arbeitet. Es bedeutet, dass die Infrastruktur zwischen fertiger Änderung und laufender Produktion nicht mitgewachsen ist, während das Team gewachsen ist.

Was gute Plattform-Arbeit tatsächlich liefert

Eine gute interne Plattform reduziert nicht die Anzahl der Entwickler, die du brauchst, sondern die Reibung, die jeder Einzelne bei jedem Deployment überwindet. In der Praxis heißt das: ein goldener Pfad, also ein Standardweg von einer Codeänderung bis in Produktion, den jeder im Team gehen kann, nicht nur die eine Person, die ihn erfunden hat. Pipelines und Umgebungen, die reproduzierbar sind. Und Monitoring, das von Anfang an Teil der Auslieferung ist, nicht ein nachträglicher Punkt auf einer To-do-Liste.

Das Ergebnis ist, dass dein Team ohne Rücksprache deployt und der Weg von der Änderung bis in Produktion für jeden im Team derselbe ist, egal wer ihn geht.

Wie das in der Praxis aussieht

Konkret heißt der Aufbau einer solchen Plattform meist drei Dinge gleichzeitig. Erstens klären wir, was dein Team heute beim Ausliefern und Betreiben tatsächlich bremst, nicht was theoretisch verbessert werden könnte, sondern die konkreten Stellen, an denen Zeit verloren geht. Zweitens bauen wir die Pipelines, Umgebungen und Werkzeuge, die diese Reibung beseitigen, angepasst an das, was dein Team tatsächlich braucht, nicht an ein generisches Plattform-Konzept von der Stange. Drittens führen wir die Plattform gemeinsam mit deinem Team ein, statt sie nur zu übergeben, damit sie tatsächlich genutzt wird und nicht als weiteres ungenutztes Werkzeug neben dem alten Weg existiert.

Wie das mit DevOps zusammenhängt

Die Frage, die uns dazu am häufigsten gestellt wird: Ist das nicht einfach DevOps mit einem neuen Namen? Nein, aber die beiden gehören zusammen. DevOps bringt CI/CD, zuverlässige Deployments und Monitoring für ein einzelnes Team in Ordnung. Platform Engineering setzt genau dort an, wo diese Arbeit nicht mehr nur für ein Team, sondern als wiederverwendbares Fundament für mehrere Teams und Projekte funktionieren muss. Der Aufwand fließt dann einmal in die Plattform, nicht wiederholt in jedes einzelne Team, das dieselben Probleme separat löst.

Warum jetzt

Ein ehrlicher Blick auf den Zeitpunkt: Es gibt keinen Stichtag, ab dem Platform Engineering plötzlich Pflicht wird. Der richtige Moment ist, wenn eines der drei Symptome von oben regelmäßig auftritt, nicht als Ausnahme, sondern als Normalzustand. Wenn dein Team wächst und trotzdem langsamer wird, statt schneller, ist das kein Zufall. Es ist meistens genau dieser fehlende Unterbau.

Passt das für dich?

Wichtig ist: Der Umfang einer Plattform richtet sich nach deiner Teamgröße, nicht umgekehrt. Auch ein kleines Team profitiert, wenn die Plattform entsprechend schlank gebaut ist, und wenn ihr schon Teile einer Plattform habt, bauen wir darauf auf, statt alles zu ersetzen.

Wenn du dir gerade die Frage stellst, wie lange es bei euch heute dauert, bis eine fertige Änderung tatsächlich in Produktion läuft, hast du wahrscheinlich schon die Antwort, ob sich der Blick auf euer Platform Engineering lohnt.

Häufige Fragen

Platform Engineering baut auf DevOps auf. Sobald CI/CD, Deployment und Monitoring nicht mehr nur für ein Team, sondern als wiederverwendbares Fundament für mehrere Teams und Projekte funktionieren müssen, wird daraus Platform Engineering, die nächste Stufe nach DevOps, nicht ihr Ersatz.

Nicht zwingend. Wir bauen die Plattform so, dass sie ohne dedizierte Plattform-Rolle wartbar bleibt, und dokumentieren, wo Grenzen liegen.

Ja. Der Umfang der Plattform richtet sich nach deiner Teamgröße, nicht umgekehrt.

Wir bauen darauf auf, wo es sinnvoll ist, und ersetzen nur, was tatsächlich bremst.

Teilen

Passende Leistung

Platform Engineering

Wir bauen die interne Plattform, mit der dein Entwicklungsteam eigenständig und zuverlässig ausliefert.

Platform Engineering ansehen