Interne Developer Platforms richtig bauen: Von Silo-Prozessen zu produktiven, autonomen Teams

Einordnung: „Internal Developer Platforms“ mit Katharina Sick (Dynatrace GmbH)

In der Session „Internal Developer Platforms“ von Katharina Sick (Dynatrace GmbH) verfolgten wir einen klaren roten Faden: Wie wir als Engineering-Organisation vom mühsamen Silo-Betrieb über „You build it, you run it“ hin zu skalierbarer Autonomie mit niedriger kognitiver Last gelangen – und zwar durch eine Internal Developer Platform (IDP). Die Softwareingenieurin, die selbst aus der Produktentwicklung kommt und heute Plattformthemen treibt, formuliert das Ziel prägnant: Die Alltagsproduktivität und Zufriedenheit von Entwicklerinnen und Entwicklern steigern, indem wiederkehrende Betriebs- und Delivery-Aufgaben zentralisiert, automatisiert und als einfache, einheitliche Workflows konsumierbar gemacht werden.

Sick macht zugleich deutlich: Nicht alle Developer teilen die Leidenschaft für CI/CD, Infrastruktur, Security oder Observability – und das ist völlig in Ordnung. Genau hier setzt Plattform-Engineering an: Aufgaben bündeln, standardisieren und als Self-Service anbieten, damit Produktteams sich auf das konzentrieren können, wofür sie da sind – Features liefern und Bugs fixen.

Vom Silo zum „You build it, you run it“ – und darüber hinaus

Sick zeichnet den historischen Bogen vom Vorgehen vor der Agilität bis zum heutigen Status vieler Organisationen:

• Früher standen getrennte Teams für Test, Build und Operations zwischen Entwicklung und Produktion. Entwickler gaben Artefakte an Tester, bekamen Feedback, wiederholten Schleifen, gaben weiter an Build und schließlich an Operations. Das Resultat: lange Durchlaufzeiten, späte Fehlerentdeckung, mühsames Nacharbeiten.
• Mit Agile wanderten Test (und ggf. Build) in die Entwicklungsteams. Containerisierung (etwa mit Docker) erleichterte Builds enorm. Der nächste logische Schritt folgte: Operations wurde ebenfalls näher an oder in die Teams integriert. Das Prinzip „You build it, you run it“ wurde gelebte Praxis.
• Doch eine Restabhängigkeit blieb: Infrastruktur. Für Datenbanken, Kubernetes-Cluster oder Cloud-Services musste weiterhin ein zentrales Operations-/Infrastrukturteam bemüht werden. Und hier setzt die IDP an, indem sie Infrastruktur-Provisionierung in die gleichen einfachen Self-Service-Flows integriert.

Das Ergebnis laut Sick: wirklich selbstständige Teams, die Applikationen implementieren, deployen, betreiben – und die dafür nötige Infrastruktur eigenständig beschaffen können.

Skalierungsprobleme: Vier Teams, zehn Tools, drei Lösungen für dasselbe Problem

Der „You build it, you run it“-Ansatz wirkt pro Team attraktiv, bringt aber bei vielen Teams eine neue Herausforderung: kognitive Last und Duplikation. Sick veranschaulicht das an einem scheinbar simplen Beispiel – automatisierte Dependency-Updates. Selbst wenn das Unternehmen ein gemeinsames Tool bereitstellt, schreibt jedes Team seine eigene Konfiguration. Das führt zu mehreren, leicht unterschiedlichen Lösungen für dasselbe Problem. Es erschwert Teamwechsel, gegenseitige Unterstützung und das Halten eines hohen Sicherheitsniveaus.

Außerdem müssen Teams sehr viele Technologien gleichzeitig im Blick behalten: Code, Tests, Security-Scanner, CI/CD, Deployment, Observability, Infrastruktur – plus die jeweils eigenen Betriebs- und Compliance-Regeln. Spätestens im Maßstab von dutzenden Services und mehreren Teams wird das unübersichtlich.

Die Idee: Eine Internal Developer Platform als Dreh- und Angelpunkt

Die Antwort, so Sick, ist eine Internal Developer Platform in der Mitte. Statt dass jedes Team alle Toolchains individuell pflegt, standardisiert die Plattform zentrale Lösungen und macht sie konsumierbar:

• Eine gemeinsame, kuratierte Konfiguration für wiederkehrende Aufgaben (z. B. Dependency-Updates), die alle Teams verwenden – und bei Bedarf gemeinsam verbessern.
• Einheitliche Wege für Image Builds, Deployments (etwa zu Kubernetes oder Cloud-Run), Observability und Security.
• Integrierte Infrastruktur-Provisionierung – die letzte verbleibende Abhängigkeit vom zentralen Operations-Team verschwindet als Wartezeit aus dem Alltag der Produktteams.

Das ist kein Selbstzweck. Der Mehrwert zeigt sich in vier Dimensionen: weniger kognitive Last, mehr Autonomie, einheitliche Lösungen und standardisierte Workflows (der „golden path“). Als praktischen Dreh- und Angelpunkt erwähnt Sick außerdem einen Servicekatalog, in dem Ownership, Laufzeitumgebungen und Build-Status zentral auffindbar sind.

Warum eine IDP wirklich zählt: Nutzen für Teams und Organisation

Weniger kognitive Last

Sick betont: Es geht nicht darum, dass Entwicklerinnen und Entwickler etwas nicht könnten. Vielmehr ist es ineffizient, wenn jede Person ständig in alle Schichten von Code bis Produktion eintaucht. Eine Plattform senkt die mentale Last, indem sie komplexe Infrastruktur- und Delivery-Aufgaben abstrahiert und vereinheitlicht. So bleibt mehr Fokus auf die fachlichen Features – und auf das schnellere Schließen von Bugs.

Autonomie und Self-Service

Mit einer IDP müssen Teams nicht mehr auf überlastete Operations-Kollegen warten. Deployments werden selbst ausgelöst, Infrastruktur (z. B. eine Datenbank) wird in Minuten bereitgestellt – unabhängig davon, ob die anfordernde Person Infrastruktur-Admin ist oder Node.js entwickelt. „Es sollte einfach sein“, fasst Sick zusammen.

Vereinheitlichte Lösungen statt Varianten-Zoo

Statt drei Konfigurationen für dasselbe Tool gibt es eine kuratierte Lösung, die für alle funktioniert. Das erleichtert Onboarding, Teamwechsel und gegenseitiges Aushelfen. Gleichzeitig bleibt Raum für Beiträge aus den Produktteams zurück in die Plattform – ein gemeinsamer, lebendiger Standard.

Standardisierte Workflows und der „golden path“

Sick schildert eine typische Erfahrung beim Start in eine neue Firma: Man bekommt ein Repository, beginnt im Code zu lesen, stolpert über Unklarheiten, fragt herum, folgt Doc-Links, findet veraltete Seiten – und verliert Tage bis zum ersten produktiven Commit. Ein standardisierter, klar dokumentierter golden path für z. B. „Neuen Microservice anlegen“ reduziert diesen Aufwand auf Stunden. Genau diese schafft die IDP: wiederkehrende Aufgaben als geführte, stabile Pfade.

Servicekatalog als Navigationszentrum

Wer gehört zu welchem Service? Läuft er in Staging und Produktion? Wo liegt das Build? Mit einem sauberen Servicekatalog ersparen sich Teams Git-Historie-Bingo und halten Ownership-Informationen aktuell. Die IDP liefert die konsolidierte Sicht, angepasst an die Bedürfnisse der Organisation.

Anti-Pattern: „Wir haben Monate gebaut – und die Developer hassen es“

Sick verweist auf einen viel diskutierten Reddit-Post: „Wir haben Monate an der Plattform gebaut. Developer hassen sie. Warum?“ Ihre Schlussfolgerung aus der Diskussion: Ein Team hat im stillen Kämmerlein „coole Tools“ gestapelt, dann die fertige Plattform über den Zaun geworfen – und erwartet, dass alle sie nutzen. Das funktioniert nicht. Eine IDP „für“ Teams zu bauen, ohne sie einzubeziehen, produziert Reibung statt Nutzen.

So gelingt es: Die IDP als Produkt denken

Dieser Satz ist Sick besonders wichtig. Eine IDP ist kein internes Sideproject, sondern ein Produkt mit echten Nutzerinnen und Nutzern – den Engineering-Teams. Was folgt daraus?

1) Es kommt darauf an – Use Cases und Stakeholder klären

„It depends“ ist hier keine Ausrede, sondern Grundlage. Kleine Unternehmen oder Teams, die bei Null starten, können eine Meinungs-starke Platform-as-a-Service-Lösung einkaufen. Sie versteckt Komplexität durch klare Vorgaben und verlangt, das eigene Arbeiten an diese Meinungen anzupassen.

Größere Organisationen mit gewachsenen Prozessen müssen hingegen ihre Stakeholder breit einbeziehen: natürlich Developer, aber auch Architektinnen, Product Owner, Teamleads, Management – je nach Struktur weitere Rollen. Welche Probleme sollen gelöst werden? Welche Anforderungen gibt es an Security, Compliance, Observability, Bereitstellungszeiten?

2) Klare Mission: Was lösen wir – und was nicht?

Eine IDP darf nicht „alles“ sein. Formuliert Ziele, Scope und Nicht-Ziele explizit: Welche Probleme adressieren wir zuerst, wie messen wir Erfolg, was bleibt bewusst außerhalb? Das schützt vor Plattform-Bloat und verringert Enttäuschungen bei Nutzerinnen und Nutzern.

3) UX-Design statt „RTFM-driven Design“

Sick unterscheidet zwischen schöner UI und echter User Experience. „RTFM“ – also „Read the effing manual“ – darf nicht der primäre Zugang sein. Die Plattform braucht sinnvolle Design-Constraints und Signale, die Nutzer durch die richtigen Entscheidungen führen. Die Doku ist Ergänzung, nicht Eintrittskarte. Das Nutzererlebnis muss selbsterklärend genug sein, damit neue Kolleginnen und Kollegen in Stunden produktiv werden.

4) Klein starten: MVP, Early Adopter, Qualität vor Quantität

Bewährte Software-Prinzipien gelten auch hier: Mit einem Minimum Viable Product beginnen, gezielt Early Adopter onboarden, Feedback einsammeln, iterativ erweitern. Qualität wichtiger als Umfang – stabile, gut erklärte erste Flows schlagen zehn halbgare Features.

5) Plattform observierbar machen

Zwei Gründe sind zentral: Troubleshooting und Erfolgsmessung. Probleme werden passieren – Observability beschleunigt die Ursachenanalyse. Zusätzlich braucht ihr Metriken zum Impact: Wie viele Nutzer verwenden die Plattform? Wie viele kehren zurück, wie viele bleiben „Einmal-Nutzer“? Was können wir tun, um sie wieder abzuholen?

Sick verweist auf Metriken aus der DevOps-Welt, die sie „driver metrics“ nennt – um die Performance von Deployments zu bewerten. Der Clou: Diese lassen sich wiederverwenden, um den Effekt der Plattform zu messen, etwa wie viel schneller Deployments mit versus ohne Plattform ablaufen.

Der konkrete Durchstich mit Alex: Vom Code zum laufenden Service

Um die Prinzipien greifbar zu machen, führt Sick eine kompakte, aber aussagekräftige Beispielreise mit „Alex“ vor – und zeigt ihre bevorzugten Tools als mögliche Bausteine. Wichtig: Es ist ein abstrahiertes Beispiel, keine Dogmen. Jede Organisation kombiniert die Bausteine passend zu den eigenen Anforderungen.

Schritt 1: Build-Image mit GitHub Actions

Alex hat die Applikation inklusive Tests fertig. Der erste Plattform-Schritt: ein Container-Image bauen und in ein Registry pushen. Sick setzt hier auf GitHub Actions. Eine YAML-Workflowdatei orchestriert den Build und Push. Für die Developer-Perspektive zählt: Der Build ist automatisiert, reproduzierbar und findet dort statt, wo ohnehin Code-Änderungen leben.

Schritt 2: Die App definieren – Open Application Model (OAM)

Als Nächstes beschreibt Alex, wie die Applikation deployed werden soll – in einer knappen, für Developer relevanten Spezifikation. Sick nennt das Open Application Model (OAM) als Spezifikation, die definiert, wie Anwendungen beschrieben und ausgerollt werden.

In ihrem Beispiel beschreibt Alex eine „Hello World“-Webservice-Anwendung, referenziert das zuvor publizierte Image, öffnet Port 8080 und deklariert eine Datenbank der Größe „medium“. „Medium“ ist eine Entwickler-freundliche Abstraktion; die Plattform-Engineers mappen sie intern auf konkrete Parameter. Sick betont: Rund 20 Zeilen YAML genügen für das Minimal-Setup. Zusätzliche Traits (z. B. weitere Abhängigkeiten) können ergänzt werden – aber die Basiskonfiguration bleibt bewusst klein.

Schritt 3: Spezifikation in Git als Source of Truth

Die gewünschte Zielkonfiguration gehört in Git. Alex committed und pusht die OAM-Definition – damit ist aus Entwicklerperspektive die Pflicht erfüllt: Image gebaut, Spezifikation geschrieben, in Git abgelegt.

Schritt 4: GitOps-Sync nach Kubernetes – plus Infrastruktur via Crossplane

Ab hier übernimmt die Plattform. Ein GitOps-Controller synchronisiert den gewünschten Zustand aus Git in die Laufzeitumgebung:

• Sick nennt Argo CD als präferiertes Werkzeug; Flux CD wäre eine Alternative. Beide bringen die deklarative Definition in Einklang mit dem tatsächlichen Systemzustand.
• Als Orchestrator setzen Plattform-Teams auf Kubernetes. Für Infrastrukturressourcen außerhalb des Clusters – etwa Cloud-Datenbanken oder Dienste in AWS und Google Cloud – nutzt Sick Crossplane. Dadurch lassen sich über dieselben deklarativen Workflows auch Cloud-Ressourcen verwalten.

Das Zusammenspiel aus Git (Desired State), Argo CD/Flux (Sync), Kubernetes (Orchestrierung) und Crossplane (Infrastruktur) schafft einen durchgehenden, reproduzierbaren Delivery-Prozess.

Schritt 5: Observability – Dashboard und Alerts out of the box

Zum Abschluss erhält Alex „automatisch“ ein Dashboard und Alarme – passiv beobachten ist nicht nötig. Sick nennt als Open-Source-Kombination Grafana zusammen mit einem OpenTelemetry Collector und „Kepton“, um „Dwarven metrics“ zu gewinnen. Sie merkt an, dass für sie persönlich Dynatrace naheliegt, bleibt im Beispiel jedoch bei der OSS-Variante. Die Botschaft: Observability ist kein Add-on, sondern integraler Bestandteil der Plattform – Entwickler bekommen sie als Teil des golden path.

Das Resultat: „Deployment fertig. Zeit zum Feiern.“

Praktische Handlungsanweisungen für Engineering-Teams

Aus der Session leiten wir klare, unmittelbar anwendbare Schritte ab:

• Wiederkehrende Aufgaben identifizieren und zentralisieren: Dependency-Updates, Container-Builds, Image-Publishing, Standard-Deployments, Secret- und Policy-Handling, Observability-Baseline, Infrastruktur-Provisionierung.
• Ein Minimalkonfigurationsmodell definieren: Einfache, entwicklernahe Spezifikationen (z. B. anhand OAM) statt dutzender Low-Level-Flags. Plattform-Teams mappen Abstraktionen (wie „Datenbank: medium“) auf konkrete Parameter.
• Git als Single Source of Truth etablieren: Alle gewünschten Zustände versionieren; GitOps-Controller (Argo CD / Flux CD) übernehmen den Sync in die Laufzeit.
• Golden paths kuratieren: „Neuen Service anlegen“, „Deployment konfigurieren“, „Observability aktivieren“ – wenige, gut dokumentierte Pfade mit hoher Erfolgsquote. Qualität vor Feature-Breite.
• Servicekatalog bereitstellen: Ownership, Umgebungen (Staging/Prod), Build- und Laufzeitinformationen strukturiert auffindbar machen.
• Plattform-Observability einrichten: Nutzung messen (aktive Nutzer, Wiederkehrer, Einmal-Nutzer), Probleme schneller debuggen, Effekte auf Delivery-Geschwindigkeit mit „driver metrics“ quantifizieren.
• Stakeholder aktiv einbinden: Entwickler, Architektinnen, Product Owner, Teamleads, Management – Anforderungen konsolidieren, Prioritäten abstimmen.
• Iterativ liefern: MVP bauen, Early Adopter onboarden, Feedback verwerten, schrittweise ausrollen.

Fazit aus Redaktion und Praxis: Eine IDP ist ein Produkt – behandelt sie auch so

Sicks Abschlussappell lässt kaum Spielraum für Missverständnisse: Eine Internal Developer Platform ist ein Produkt mit echten Nutzerinnen und Nutzern. Sie verlangt Product Discovery, klare Zielbilder, intuitives UX-Design, fokussiertes MVP-Delivery und konsequente Observability – genauso wie jedes erfolgreiche Kundenprodukt.

Technisch ist der Weg greifbar: Container-Image bauen (z. B. via GitHub Actions), die App knapp und entwicklernah beschreiben (OAM), den gewünschten Zustand in Git festhalten, per Argo CD oder Flux CD nach Kubernetes synchronisieren, Infrastruktur mit Crossplane einbinden, Observability per Grafana und OpenTelemetry plus „Kepton“ integrieren. Organisatorisch braucht es Stakeholder-Einbindung, Standardisierung und eine Kultur, die Autonomie und Qualität vor Tool-Zählerei stellt.

Die Vorteile zahlen direkt auf den Alltag der Teams ein: weniger kognitive Last, spürbar mehr Autonomie, hohe Wiederholbarkeit und ein schnelleres, sichereres „Idea-to-Prod“. Oder in Sicks eigenen Worten zusammengefasst: Eine Plattform, „die Entwickler wirklich nutzen wollen“, entsteht nicht im Alleingang, sondern indem wir sie wie ein Produkt bauen – für die Menschen, die täglich damit arbeiten.

• 

  

  Indermohan Singh, Platform Developer Advocate bei Dynatrace

  Indermohan Singh von Dynatrace spricht im Interview von seinen ersten Berührungspunkten mit Software Development bis hin zu seiner aktuellen Arbeit und gibt Tipps für Neueinsteiger.

  Jetzt ansehen
• 

  

  DevStory: Perihan Rashed, Senior Product Experience Designer bei Dynatrace

  Perihan Rashed von Dynatrace erzählt im Interview über ihren ursprünglichen Zugang zum UX Design, was ihre aktuelle Arbeit beinhaltet und gibt Ratschläge für Neueinsteiger.

  Jetzt ansehen