Platform Engineering: Die 3 größten Herausforderungen – und wie man sie meistert

  • Veröffentlicht

Kommen wir gleich zum Punkt: Platform Engineering ist schwierig. Plattform-Engineering-Teams existieren per Definition nur dann, wenn der Tech-Stack eines Softwareunternehmens zu komplex ist, als dass einzelne Softwareentwickler:innen ihn allein bewältigen könnten. Der eigentliche Zweck des Plattform-Engineerings besteht darin, diese Komplexität zu verringern. Das bedeutet, dass die Komplexität stattdessen beim Plattform-Team landet (Siehe „Law of conservation of complexity“: Komplexität kann nicht reduziert, sondern nur verschoben werden). Mehr dazu im Post: Warum Platform Engineering?

Daher sollte man nicht die Erwartungen haben, dass Plattform-Engineering einfach ist. Es gibt keine magischen Tools, die das Leben eines Plattform-Ingenieurs plötzlich erleichtern und es Junior-Systemadministratorinnen und -administratoren ermöglichen, sofort als Plattform-Engineer durchzustarten.

Aber es gibt Entscheidungen, die du als Plattform-Ingenieur treffen kannst – Entscheidungen, die dein Leben entweder schwerer oder leichter machen. Sehen wir uns das einmal genauer an.

Challenge 1: Zu viele Tools

TL;DR: Ja. Damit musst du klarkommen. Dafür wurdest du eingestellt. Um es langfristig besser zu machen, setze auf neue Tools, die generisch, vielseitig einsetzbar und flexibel sind. Und ja – man kann Tools auch wieder loswerden.

„Zu viele Tools“ ist genau der Kern des Problems im Platform Engineering. Es geht nicht nur um einzelne Tools, sondern um Cloud-Provider, interne Komponenten und deren Abhängigkeiten, Skripte aus dem eigenen Team – alles, was diesen hochgradig vernetzten Stack und die Infrastruktur ausmacht, die du für andere einfacher machen sollst. (Themenverwandt: Platform Engineering ohne Kubernetes)

In Blogposts liest man oft schlaue Konzepte wie „Portfolio-Management-Strategien“ oder „Vendor-Ecosystems“. Die zugrunde liegende Annahme ist meist folgende: Eine zentrale Steuerung soll helfen, das tägliche Chaos zu bewältigen, mit dem Platform-Engineers zu tun haben. Ich halte das für ineffizient und realitätsfern. Es basiert auf der Annahme, dass man eine Liste an Anforderungen erstellen kann, die alle zukünftigen Tools erfüllen müssen. Das soll den Beschaffungsprozess erleichtern.

Meiner Erfahrung nach funktioniert das selten. Im Gegenteil: Es erschwert die Suche nach brauchbaren Lösungen erheblich. Am Ende bekommen nur große Anbieter eine Chance, denn sie erfüllen alles am Papier, aber nicht unbedingt die eigentlichen Anforderungen. Und das Preis-Leistungs-Verhältnis ist oft enttäuschend.

Was sich hingegen bewährt hat: Teams, die selbst entscheiden dürfen, welche Anforderungen für sie wichtig sind, Tools vorselektieren und diese dann an Teams wie Security oder Compliance übergeben, damit sie dort geprüft und ggf. abgelehnt werden können. Das ist viel effektiver und schneller, als Security, Legal und Co. eine generische Anforderungsliste erarbeiten zu lassen. Das führt oft dazu, dass diese Liste so umfassend und abstrakt wird, dass kein Tool sie je erfüllen kann. Solche Prozesse enden typischerweise in den klassischen Enterprise-Entscheidungen: Man kauft Tools, die juristisch und sicherheitstechnisch ein Häkchen bekommen – aber nicht das tun, was eigentlich gebraucht wird.

Es mag sein, dass du in deinem Unternehmen keinen Einfluss darauf hast, wie Tools ausgewählt werden. Aber was du sehr wahrscheinlich tun kannst, ist, dich für Tools stark zu machen, die:

  • Offen sind, also angepasst oder erweitert werden können, ohne dass man auf den Hersteller angewiesen ist,
  • Einfach zu integrieren sind, sprich: gut dokumentierte REST-APIs und im Idealfall zusätzliche Integrationsmöglichkeiten wie Webhooks mitbringen,

Möglichst allgemein einsetzbar, breit aufgestellt und flexibel sind. Das kann bedeuten, dass du anfangs etwas mehr Zeit investieren musst, um das Tool so hinzubekommen, wie du es brauchst, aber langfristig kannst du damit genau das erreichen, was du willst. Und du brauchst insgesamt weniger Tools.

Nebenbei bemerkt:
Es gibt im Software-Bereich starke Anreize, sehr spezialisierte Tools für ganz bestimmte Anwendungsfälle zu entwickeln. Aus Sicht eines Anbieters: Wenn ein Tool nur eine Sache macht, lässt es sich sehr einfach erklären und es macht genau diese eine Sache meist sehr gut. Das macht den Vertrieb einfacher.

Aber: Dadurch wird der Markt regelrecht überschwemmt mit Nischenlösungen für sehr spezifische Use Cases. Wenn du genau in die Zielgruppe des Produkts fällst – super. In den meisten Fällen wirst du aber ein Tool bekommen, das in einem Bereich gut ist und in allem anderen schlecht. Allgemein einsetzbare Tools mit einem breiten Funktionsspektrum bieten in der Regel ein deutlich besseres Preis-Leistungs-Verhältnis. Sie brauchen zwar etwas länger, um verstanden und eingerichtet zu werden, aber wenn man sie einmal beherrscht, sind sie wesentlich mächtiger. Und sie bringen dir am Ende mehr Nutzen als ein Dutzend Spezial-Tools, die du alle einzeln lernen, pflegen und irgendwie integrieren musst.

Noch ein sinnvoller Ratschlag, der erstaunlich selten in Blogposts auftaucht:
Man kann Tools wieder loswerden. In 90 % der Fälle stimmt es zwar, dass man ein Tool, sobald es integriert ist, ewig weiter nutzt. Aber in 10 % der Fälle ist es absolut machbar, es einfach wieder rauszuwerfen, beispielsweise, wenn es mehr Aufwand als Nutzen bringt.

Auch hier gilt wie bei allem: Setze deine Energie gezielt ein. Wenn man ein Tool loswerden kann, ist das meistens eine gute Idee, aber eben nicht immer die wichtigste. Daher: Sprich das nur dann an, wenn du einen wirklich guten Grund dafür hast.

Herausforderung 2: Entwickler:innen nutzen die Plattform nicht

TL;DR: Immer wenn du an einem Feature oder Service arbeitest, stell dir die Frage: Wer braucht das eigentlich? Dann geh zu diesen Leuten, frag sie warum, und notiere dir mindestens einen, besser drei konkrete Use Cases. Bau das Feature oder den Service so, dass genau diese Anwendungsfälle abgedeckt werden.

Es ist eine der ältesten Sünden in der Softwareentwicklung:
Ingenieure entwickeln etwas technisch Brillantes. Dann geben sie es an die Leute weiter, die es nutzen sollen…und die weigern sich einfach das Tool zu nutzen. Warum? Höchstwahrscheinlich, weil sie es schlichtweg nicht brauchen.

Meiner Erfahrung nach ist es der direkteste und effektivste Weg zu einem nützlichen Feature oder Service, wenn man Leute ganz konkret fragt, wie sie etwas nutzen wollen und wofür. Also: Frag nach den konkreten Use Cases.

Mehr gibt’s dazu eigentlich nicht zu sagen. Wenn du möchtest, kannst du es „Product Mindset“, „User Centricity“ oder „Features nach Nutzermehrwert priorisieren“ nennen. Ich nenne es einfach: Mit Leuten reden. (Alternativ kannst du ihnen auch einfach ein Ticket zuweisen, wenn dir Reden nicht liegt.)

Herausforderung 3: Legacy-Tools und Technical-Debt

TL;DR: Das wird sich nicht ändern. Je eher du das akzeptierst, desto schneller findest du Wege, trotzdem produktiv zu arbeiten. Beispiel: Ergänze deinen Stack um Tools, die sich mit Legacy-Systemen integrieren lassen, oder einigt euch auf einen festen Pufferfaktor in euren Aufwandschätzungen, um Problemen mit Technical-Debt gerecht zu werden.

Wenn man mit Softwareentwickler*innen spricht, wirkt Return on Investment oft wie ein Schimpfwort. Entwickler:innen klagen darüber, dass ihre Manager sich nicht für das Beheben von Technical-Debt interessieren, und freuen sich insgeheim ein bisschen, wenn sie wieder sagen können: „Hab ich doch gesagt“, weil ein Legacy-Tool oder ein Codeabschnitt mal wieder der größte Zeitfresser bei der Umsetzung eines neuen Features ist. (Falls ihr überhaupt noch schätzt. Ich persönlich finde: Aufwandschätzungen sind Zeitverschwendung.)

Am Ende lohnt es sich oft schlicht nicht, technische Schulden abzubauen.
Und in anderen Fällen ist es schlicht unmöglich, den tatsächlichen Return on Investment realistisch einzuschätzen.

Trotzdem: Es lohnt sich immer, sich hinzusetzen und ehrlich darüber nachzudenken, was es wirklich bedeuten würde, genau diese eine technische Schuld zu beseitigen oder dieses eine alte Tool loszuwerden, das alles so schwer macht.

Überleg dir, ob es machbar ist, was konkret dafür nötig wäre, und verdopple dann den geschätzten Aufwand. Frag dich dann noch einmal:

  • Willst du deine Zeit wirklich genau damit verbringen?
  • Glaubst du ehrlich, dass es das wert ist?

Wenn die Antwort ja ist – großartig. Mach dir Gedanken zu Kosten und Nutzen, bring sie vor, und mit ein bisschen Glück bekommst du sogar grünes Licht.
Aber: Verlass dich nicht drauf.

Dinge loszuwerden, die nerven, stehen einfach zu selten in direktem Zusammenhang mit dem, was Geld bringt.

Was also in deinem Einflussbereich bleibt: Finde Wege, dir die Arbeit mit der vorhandenen technischen Schuld zu erleichtern. Das kann bedeuten: Bewusst Tools zu kaufen, die sich mit alten Systemen integrieren oder sie zumindest überwachen lassen, oder intern einen festen Multiplikator für Aufwandsschätzungen zu etablieren, der zusätzlichen Aufwand durch Technical-Debt berücksichtigt.

Fazit

Platform Engineering ist schwer. Und das aus gutem Grund: Die Aufgabe dieser Disziplin ist es, mit Komplexität umzugehen – damit Softwareentwickler*innen es nicht müssen.

Und: Diese Zielgruppe ist berüchtigt schwierig. Sie will alles verstehen, aber nichts davon anfassen müssen, wenn es nicht nötig ist.

Deshalb ist es schwer, eine Plattform zu bauen – und genauso schwer, Entwickler*innen dazu zu bringen, sie zu nutzen.

Damit dein Leben ein bisschen einfacher wird, hier drei praktische Ansätze:

✅ Wähle Tools, die mit Komplexität umgehen können.

Setze auf Tools, die:

  • anpassbar sind,
  • sich gut integrieren lassen (APIs, Webhooks),
  • möglichst generisch oder zumindest vielseitig einsetzbar sind.

✅ Lass Entwickler:innen konkrete Use Cases beschreiben.

Frag: Was genau willst du tun? Warum?
So vermeidest du Feature-Wunschlisten, die niemand wirklich braucht. Damit entwickelst du nur Features, die wirklich relevant sind. Und auch ein minimaler Service wird genutzt, wenn er ein relevantes Problem wirklich löst.

✅ Akzeptiere Technical-Debt und Legacy-Tools.

Bau keine Plattform für eine utopische Idealwelt. Bau eine für die Realität, die du jetzt hast. Heißt konkret: Nimm Tools, die mit alten Systemen umgehen können. Plane bei neuen Features oder Services immer Zeit für technischen Altlasten mit ein.

Ein bisschen Eigenwerbung

Wir haben ein Tool gebaut, das genau für diese Art von Komplexität gemacht ist: Cloudomation Engine – ein Python-Framework für Platform Engineering.

Wir haben damit angefangen, bevor der Begriff „Platform Engineering“ überhaupt ein Ding war und freuen uns jetzt riesig, dass sich immer mehr Personen genau mit diesen Herausforderungen und Chancen beschäftigen: Komplexität in Tech und Infrastruktur richtig zu managen.

Als ehemalige Software- und DevOps-Engineers kennen wir die echten Pain Points nur zu gut:

  • Zu viele Tools,
  • störrische Entwickler:innen als Nutzer:innen,
  • und die endlose zusätzliche Komplexität durch Technical-Debt und Legacy-Tech.

Also haben wir ein Framework gebaut, das sich genau darum kümmert. In Python, weil wir Python mögen. Wenn du neugierig bist, was Cloudomation Engine kann:

Wir glauben: Wenn Platform Engineering dein Ding ist, wirst du es spannend finden.