Internal Developer Platforms - Architekturen für echten Self-Service

In den letzten zwei Jahren ist “Internal Developer Platform” zum Buzzword avanciert. Doch während Gartner die IDP als Heilmittel gegen die kognitive Überlastung von Entwicklern preist, enden viele interne Projekte als starre Abstraktionsschichten, die mehr Probleme schaffen, als sie lösen.

Echter Self-Service entsteht nicht durch ein schickes GUI, sondern durch ein durchdachtes technisches Fundament, das Infrastruktur als Produkt begreift.

Das Kernproblem: Das “Abstraktions-Paradoxon”

Viele Plattform-Teams begehen den Fehler, Kubernetes komplett vor den Entwicklern zu verstecken. Sie bauen komplexe Wrapper um Helm-Charts oder nutzen proprietäre Portale, die nur 80 % der Use-Cases abdecken. Sobald ein Team die restlichen 20 % benötigt – etwa ein spezielles Ingress-Tuning oder ein Sidecar-Konfig – bricht das Modell zusammen und der manuelle Ticket-Prozess kehrt zurück.

Eine erfolgreiche IDP muss daher nicht die Technik verstecken, sondern Golden Paths (nicht “Golden Cages”) definieren.

Die Säulen einer belastbaren IDP-Architektur

1. Control Plane statt Ticket-System: Crossplane und die K8s-API

Anstatt Terraform-Skripte manuell auszuführen, nutzen moderne IDPs die Kubernetes-API als universelle Control Plane.

• Der Ansatz: Mit Crossplane definieren wir Composite Resources (XRDs). Ein Entwickler fordert nicht mehr eine “AWS RDS Instanz” an, sondern eine “ayedo-Postgres-DB”.
• Der Effekt: Die Komplexität des Cloud-Providers (VPCs, Subnets, IAM-Roles) ist in der XRD gekapselt. Der Entwickler nutzt ein einfaches YAML-Manifest, und die Plattform kümmert sich um das Provisioning und den Drift-Check.

2. Orchestrierung der Workflows: GitOps als Single Source of Truth

Eine IDP ohne GitOps ist lediglich ein Portal für Schatten-IT. Der State der Plattform und der Applikationen muss im Git liegen.

• Tools: ArgoCD oder Flux sind hier die gesetzten Standards.
• Wissenswert: Der entscheidende Schritt ist die Integration von ApplicationSets in ArgoCD. Damit lassen sich Templates erstellen, die basierend auf Git-Repository-Strukturen automatisch Umgebungen (Preview, Staging, Prod) im Cluster instanziieren.

3. Das Interface: Backstage vs. CLI-First

Die Diskussion “Portal oder CLI” wird oft falsch geführt. Eine IDP sollte beides bieten.

• Backstage (Spotify): Ideal als Service-Katalog und für die Visualisierung von Abhängigkeiten (Software Catalog). Es ist jedoch kein Deployment-Tool, sondern das Schaufenster der Plattform.
• CLI/API: Für Power-User muss die Plattform über die API steuerbar bleiben. Jede Aktion im GUI muss auch via kubectl oder API-Call möglich sein, um Automatisierung nicht zu behindern.

Warum viele IDP-Projekte scheitern

Der häufigste Grund für das Scheitern ist die mangelnde Berücksichtigung der “Cognitive Load”. Wenn die Plattform so komplex ist, dass Entwickler ein Handbuch lesen müssen, um einen S3-Bucket zu bekommen, werden sie Wege um die Plattform herum suchen.

Unsere Erfahrung zeigt: Eine IDP ist niemals fertig. Sie muss wie ein externes Produkt behandelt werden – inklusive User-Research bei den eigenen Entwicklern, Dokumentation und schnellen Feedback-Zyklen.

Fazit: Platform Engineering ist Produktmanagement

Der Aufbau einer IDP ist eine technologische Herausforderung, aber primär eine strategische. Wer Crossplane, ArgoCD und Backstage lediglich installiert, hat noch keine Plattform. Erst die Definition von sinnvollen Abstraktionen und automatisierten Workflows macht aus einer Sammlung von Tools ein Enabler-Werkzeug.

Technical FAQ: IDP & Platform Engineering

Warum Crossplane statt Terraform für die IDP nutzen? Terraform ist hervorragend für das initiale Bootstrapping. Crossplane hingegen nutzt das “Reconciliation-Loop”-Prinzip von Kubernetes. Es prüft permanent den Ist-Zustand gegen den Soll-Zustand und korrigiert Drift sofort. Zudem erlaubt es Entwicklern, Cloud-Ressourcen mit dem Werkzeug zu verwalten, das sie bereits für ihre Apps nutzen: kubectl.

Ist Backstage zu komplex für den Mittelstand? Backstage ist sehr mächtig, erfordert aber signifikanten Aufwand für Maintenance und Plugin-Entwicklung. Für kleinere Teams kann ein gut strukturiertes GitOps-Repository mit klaren Templates (z.B. via Copier oder Cookiecutter) und einem einfachen Dashboard oft effizienter sein.

Wie misst man den Erfolg einer IDP? Die wichtigsten Metriken sind die Lead Time for Changes und die Deployment Frequency (DORA Metrics). Wenn Entwickler nach Einführung der Plattform schneller und häufiger deployen können, ohne das Ops-Team zu kontaktieren, ist die IDP erfolgreich.