Jede IDP ist einzigartig, aber es gibt einige grundlegende Merkmale, die die meisten gemeinsam haben. Ganz einfach gesagt besteht jede IDP aus ungefähr drei „Teilen“:
- Ein IDP-Frontend, über das Entwickler:innen auf die IDP zugreifen und z. B. Dokumentationen lesen, Services bereitstellen oder den Status ihres Builds überprüfen können. Ein IDP-Frontend kann eine grafische Benutzeroberfläche (GUI), eine Kommandozeilen-Schnittstelle (CLI) und/oder eine API sein (idealerweise alle drei). IDP-Frontends werden oft als Portale bezeichnet.
- Ein IDP-Backend, das die Integration mit anderen Tools, Automatisierungen und oft auch dem Konfigurationsmanagement (bis zu einem gewissen Grad) übernimmt. IDP-Backends werden manchmal als Plattform-Orchestratoren bezeichnet.
- Viele weitere Tools, die in die IDP integriert sind. IDPs werden typischerweise von Unternehmen entwickelt, die bereits viele Tools und Automatisierungen für zentrale Prozesse im Einsatz haben – wie z. B. CI/CD-Pipelines – die bereits andere Tools wie Testautomatisierung, Build-Automatisierung, Versionskontrollsysteme, Infrastruktur-Automatisierungstools, eigene Skripte usw. miteinander verknüpfen. IDPs ersetzen diese bestehenden Tools in der Regel nicht, sondern bieten eine integrierte Schicht darüber, über die Entwickler:innen sowohl auf Informationen als auch auf Funktionen dieser Tools zugreifen können. Beispielsweise kann die IDP Informationen über eine Komponente enthalten, darunter das README aus dem Quellcode-Repository sowie Statistiken aus vergangenen Durchläufen einer CI/CD-Pipeline. Einer der Hauptgründe, warum IDPs immer individuell angepasst sind, liegt darin, dass sie auf einer bereits vorhandenen, vielfältigen Tool-Landschaft aufbauen, die in jedem Unternehmen unterschiedlich ist.
Wenn man sich den großen und komplexen Tool-Stack in der Softwareentwicklung vorstellt, kann man sich das IDP-Backend als eine Spinne vorstellen, die in der Mitte all dieser Tools sitzt und sie miteinander verknüpft, während das IDP-Frontend eine Schicht darüber ist, die es Entwicklern ermöglicht, die zugrunde liegenden Tools im Self-Service zu entdecken und zu nutzen.
Architektur
Das folgende Architekturdiagramm von CNOE (Cloud Native Operational Excellence) gibt eine detaillierte Übersicht:
In diesem Diagramm wäre das „Developer Portal“ das Frontend der Internal Developer Platform. Der Bereich „Workflow Orchestration“ würde das Backend darstellen.
Unten folgt eine detaillierte Beispielarchitektur, die unsere eigene Software enthält und zeigt, welche anderen Arten von Tools und Services Teil einer IDP sein könnten:
Kernfunktionen einer IDP
Die Hauptidee einer Internal Developer Platform (IDP) besteht darin, Tools, Services, Konfigurationen sowie andere Informationen und Ressourcen an einem zentralen Ort zu bündeln. Softwareentwickler:innen, aber auch andere Stakeholder wie Operations-Teams, sollten die IDP als einheitlichen Einstiegspunkt nutzen können, um Anwendungen und Infrastruktur eines Unternehmens zu entdecken und mit ihnen zu interagieren.
Daher muss das IDP-Backend insbesondere zwei zentrale Funktionen erfüllen:
#1 Integration
Die IDP muss eine große Anzahl unterschiedlicher Systeme und Tools miteinander verbinden, hauptsächlich in zwei Kategorien:
📌 Informationen
Eine IDP sollte in der Lage sein, Informationen aus verschiedenen Quellen zu sammeln und sie an einem zentralen Ort für Entwickler:innen bereitzustellen. Dazu gehören beispielsweise:
- Inhalte aus Git-Repositories (z. B. README-Dateien)
- Uptime-Statistiken aus Cloud-Infrastrukturen
- Manuell gepflegte Dokumentationen (direkt in der IDP oder aus externen Quellen)
- Links zu Swagger-Dokumentationen für REST-APIs
- Datenbankinformationen oder andere relevante Daten
Ein leistungsfähiges IDP-Backend sollte mit einer Vielzahl von Quellen und Formaten kompatibel sein und Informationen bidirektional übertragen können – sowohl von den Ursprungsquellen zur IDP als auch umgekehrt.
🔹Beispiel:
Falls Backstage als IDP-Frontend genutzt wird, könnte das IDP-Backend Informationen aus verschiedenen Systemen abrufen und in das Format des Backstage-Softwarekatalogs umwandeln. Änderungen, die direkt im Backstage-Katalog vorgenommen werden, sollten dann von der IDP an die entsprechenden Systeme zurückübertragen werden.
📌 Funktionalität
Das IDP-Backend muss Funktionalitäten bereitstellen, unabhängig von der zugrunde liegenden Technologie oder den verwendeten Tools. Diese Funktionalitäten sollten den Entwicklern über das IDP-Frontend in einem einheitlichen Format zur Verfügung stehen.
Das bedeutet konkret, dass das IDP-Backend:
✅ Ereignisse und Prozesse in anderen Tools auslösen kann, z. B.:
- Webhooks aufrufen
- API-Requests ausführen
- Skripte auf Remote-Systemen starten
- CI/CD-Pipelines auslösen
- Infrastruktur über Terraform oder Cloud-Provider-APIs bereitstellen
✅ Ereignisse empfangen kann, z. B.:
- Webhooks anbieten, die von anderen Tools ausgelöst werden können
- APIs bereitstellen, über die externe Systeme Prozesse im IDP-Backend auslösen können (z. B. beim Push in ein Repository oder bei einem Fehler in einer CI/CD-Pipeline)
✅ Funktionalitäten für Entwickler:innen einheitlich verfügbar machen, sodass sie:
- Über eine API, CLI oder ein grafisches Portal auf dieselben Funktionen zugreifen können
- Den Status einer Pipeline einsehen
- Eine Umgebung kopieren oder sperren
- Feature-Branch-Systeme erstellen
- … und viele weitere Aufgaben durchführen können
Die Funktionalitäten sollten immer einer einheitlichen Struktur folgen, sodass Entwickler:innen die IDP nur einmal verstehen müssen, um Zugriff auf die gesamte Infrastruktur und alle Anwendungen eines Unternehmens zu erhalten.
#2 Automatisierung
Da Unternehmen selten mit einer IDP starten, sondern diese meist auf bereits vorhandene und komplexe IT-Ökosysteme aufbauen, muss das IDP-Backend besonders gut darin sein, Lücken in den bestehenden Automatisierungen zu schließen.
Häufig bedeutet das:
✅ Auflösen von Abhängigkeiten und Anwenden von Konfigurationen
✅ Erweiterung bestehender Automatisierungen mit zusätzlichen Schritten oder spezifischen Anpassungen für verschiedene Anwendungsfälle
Das IDP-Frontend sollte die Automatisierung für Entwickler:innen in ihre bestehenden Workflows integrieren. Während grafische Portale wie Backstage weit verbreitet sind, sollte eine leistungsstarke IDP zusätzlich:
- Eine CLI-Schnittstelle bieten
- Eine API bereitstellen (z. B. REST), über die Entwickler:innen Automatisierungen auch direkt ansprechen können
Manchmal können API und CLI direkt vom IDP-Backend bereitgestellt werden, sodass das IDP-Frontend lediglich als GUI dient, die die API-Aufrufe an das Backend weiterleitet.
IDP als Abstraktionsschicht
Eine gut aufgebaute IDP ist eine Abstraktionsschicht, die es Entwicklerinnen und Entwicklern ermöglicht, in einem einheitlichen und unterstützten Rahmen mit den Anwendungen und der Infrastruktur eines Unternehmens zu interagieren.
Das heißt:
✅ Weniger Komplexität für Entwickler:innen
✅ Mehr Kontrolle für Plattform-Engineering-Teams
✅ Einheitliche Durchsetzung von Richtlinien und Standards
Ziel ist es, eine zentrale Schicht zu schaffen, durch die sämtliche Infrastruktur und Anwendungen eines Unternehmens verwaltet werden – auch wenn das in der Praxis wahrscheinlich nie zu 100 % gelingt. 😉
Zusammenfassung
IDPs sind per Definition einzigartig für jedes Unternehmen, aber sie verfolgen alle dasselbe Ziel:
🛠 Eine Abstraktionsschicht
➡️ Die es Entwicklerinnen und Entwicklern ermöglicht, die Anwendungen und Infrastruktur eines Unternehmens
➡️ Einheitlich und unterstützt zu entdecken und zu nutzen
Wie erreichen IDPs das?
✅ Integration von Skripten, Tools, Pipelines, Datenquellen, Umgebungen etc.
✅ Bereitstellung von Informationen & Funktionalität für Entwickler:innen im Self-Service
✅ Zentrale Plattform mit einer einheitlichen Schnittstelle, die
- Immer auf die gleiche Weise funktioniert
- Unabhängig von den zugrunde liegenden Technologien ist
Was braucht eine IDP dafür?
✔ Ein Backend mit starker Integration und flexiblen Automatisierungsfunktionen
✔ Ein Frontend, das eine einheitliche Schnittstelle für Entwickler:innen bietet –
- Grafisch (GUI)
- Über eine API
- Per Kommandozeile (CLI)
Beispiele aus der Praxis
▶ Ein Testingenieur kann jede Anwendung, die getestet werden muss, immer auf die gleiche Weise deployen – egal ob per Knopfdruck im IDP-Frontend oder per CLI-Befehl. Es spielt keine Rolle:
- Wo die Anwendung läuft (Kubernetes, Linux-VM, Windows-Server)
- In welcher Sprache sie geschrieben ist (Java, Python etc.)
- Welche CI/CD-Pipeline sie nutzt
➡️ Für den Testingenieur sieht alles gleich aus und funktioniert einheitlich
▶ Ein Site Reliability Engineer (SRE) hat einen zentralen Ort, um:
- Alle aktuell deployten Anwendungen und Umgebungen zu sehen
- Nachzuvollziehen, welche Softwareversion wo läuft
- Direkt auf Monitoring-Tools und weitere Informationen zuzugreifen
➡️ Egal, welche Umgebung, Anwendung oder Infrastruktur sie suchen – die IDP liefert die Infos
Kurz gesagt: Eine gut gebaute IDP reduziert Komplexität für Entwickler:innen, während sie gleichzeitig Plattform-Engineering-Teams ermöglicht, Richtlinien und Standards zentral durchzusetzen. 🚀
