Plattform-Engineering-Tools zum Aufbau einer IDP (2025)

  • Veröffentlicht

Mit dem Wachstum Ihrer Organisation steigt auch die Nachfrage nach einer schnelleren Bereitstellung von Features. Engineering-Teams sind dann aber oft mit Infrastrukturarbeiten beschäftigt, welche die Entwicklung verlangsamen. Genau hier kommen Internal Developer Platforms (IDPs) ins Spiel.

Dieser Artikel zeigt, wie eine IDP strukturiert wird und gibt Beispiele für Tools, die verwendet werden können.

Legen wir los!

Was sollte eine erfolgreiche Internal Developer Platform leisten?

Eine IDP sollte die Softwarebereitstellung beschleunigen, indem sie sich wiederholende, wenig wertschöpfende Infrastrukturaufgaben abstrahiert und so Entwickler:innen ermöglicht, sich auf das Wesentliche zu konzentrieren: das Schreiben von Code. Über die IDP sollen Softwareentwickler:innen in der Lage sein, relevante Infrastruktur, Deployments, Komponenten, Repositories und andere für ihre Arbeit wichtige Ressourcen per Self-Service zu nutzen.

Plattform-Engineering-Teams sind für den Aufbau und die Wartung der IDP verantwortlich. Aufgaben, die zuvor von DevOps-, Operations- und Applikations-Teams übernommen wurden, verlagern sich teilweise hin zum Plattform-Engineering-Team: die Auswahl von Tools, der Aufbau von Pipelines, die Integration von Services und Infrastruktur sowie die Bereitstellung der IDP.

Um diesen Wandel zu ermöglichen, braucht es das richtige Plattform-Engineering-Team, geeignete Ressourcen und passende Tools.

platform engineering tools current state

platform engineering tools future state

Screenshots aus „How to Make the Business Case for an Internal Developer Platform

Die oben gezeigten Folien stammen aus dem Vortrag „How to Make the Business Case for an Internal Developer Platform“ und veranschaulichen, welche Funktionen von dem Software-Team auf das Plattform-Engineering-Team übergehen.

Der zentrale Punkt ist dabei, dass das Plattform-Engineering-Team diese Funktionen als Service für alle Applikationsteams bereitstellt. Dadurch entfällt die doppelte Arbeit, die in vielen Organisationen häufig vorkommt, etwa wenn jedes Software-Team sein eigenes lokales Deployment-Tooling, oder sogar eigene Testframeworks und CI/CD-Pipelines betreibt.

Die Verlagerung dieser Aufgaben auf ein dediziertes Plattform-Engineering-Team erleichtert es erheblich, unternehmensweite Standards und Richtlinien durchzusetzen, insbesondere im Hinblick auf Secret Management und Qualitätssicherung.

Kategorisierung von Tools und Komponenten

Viele Artikel listen einfach verschiedene Plattform-Engineering-Tools auf, ohne eine Kategorisierung anzubieten. Das Ergebnis ist eine sinnfreie Sammlung von Tools und die Herausforderung für Leser:innen besteht dann darin, herauszufinden, wie (oder ob) diese Tools in den Plattform-Engineering-Tech-Stack passen.

Um mehr Klarheit und Struktur zu schaffen, kategorisieren wir diese Tools anhand einer „Referenzarchitektur“, die von platformengineering.org Popularität erlangt hat. Dieses Framework unterteilt das Ökosystem in fünf zentrale Komponenten, sogenannte „Ebenen“ (Planes):

  • Developer Control Plane: Alle Komponenten, über die Entwickler:innen mit der Plattform interagieren. Dazu gehören in der Regel GUIs / Portale, Versionskontrolle, Cloud-Entwicklungsumgebungen (CDEs) sowie Konfigurationsstandards, die von Entwickler:innen selbst gepflegt werden (typischerweise im Quellcode-Repository), wie z. B. Ansible-Playbooks, Helm-Charts, devfile.yaml usw.
  • Integration & Delivery Plane: Hier findet die gesamte Automatisierung statt. CI/CD-Pipeline-Tools, Infrastrukturautomatisierung sowie andere Automatisierungs-Tools (z. B. Plattform-Orchestrierer) gehören typischerweise zu dieser Ebene.
  • Monitoring & Logging Plane: Wie der Name schon sagt, befinden sich hier alle Überwachungs-Tools.
  • Security Plane: Verwaltung von Secrets, Richtlinien-Tools und weitere Sicherheitstechnologien.
  • Resource Plane: Rechenleistung und Speicherressourcen.

Nicht jede Internal Developer Platform muss zwingend alle fünf Ebenen enthalten. Es ergibt auch nicht immer Sinn, eine IDP streng in diese fünf Ebenen zu unterteilen, zum Beispiel, wenn mehrere Ebenen durch dasselbe Tool abgedeckt werden.

Visuell sieht das folgendermaßen aus:

idp architecture cloudomation

Als Nächstes zeigen wir ein Beispiel, wie eine IDP gestaltet werden kann, inklusive einem Vorschlag an Tools.

Beispiel: Aufbau einer Internal Developer Platform

Hier ist eine Übersicht von Tools, die Sie zum Aufbau einer IDP verwenden könnten. Wichtiger Hinweis: Es gibt natürlich sehr viele Tools in jedem Bereich (Kommerzielle und Open Source Tools) und die in diesem Artikel genannten sind lediglich Beispiele.

Developer Control Plane

#1 Developer Portal

Warum das wichtig ist: Interne Developer-Portale dienen als einheitliche Schnittstelle und ermöglichen es Softwareentwickler:innen, Teams und Engineering-Managern, Services zu entdecken, Verantwortlichkeiten zu verfolgen, Standards durchzusetzen und Software zu verbessern. Wir haben ausführlich über Developer-Portale in diesem Blogbeitrag geschrieben: 5 Internal Developer Portale (…und was Software Engineers über sie sagen). Das Plattform-Engineering-Team stellt sicher, dass das Portal aktuell bleibt, sich nahtlos in bestehende Tools integriert und sich anhand von Feedbacks weiterentwickelt.

Tools, die Sie in Betracht ziehen können:

  • Engine Forms: Engine Forms sind leichtgewichtige, auf JSON-Schema basierende Formulare, die als einfache Benutzeroberflächen dienen können, etwa zum Auslösen eines Deployments oder zur Anzeige des Pipeline-Status. Sie sind besonders nützlich für schnelles Prototyping oder als UI für einzelne Anwendungsfälle. Als vollwertige Portal-Lösung sind sie aber nicht gedacht. Für eine IDP empfiehlt sich ein dediziertes Portal, mit dem Cloudomation Engine Daten und Dienste bereitstellen kann, die Entwickler:innen dann über das Portal nutzen.
  • Backstage: Backstage ist ein beliebtes Open-Source-Framework zum Aufbau von Developer-Portalen. Es handelt sich nicht um eine Plug-and-Play-Lösung und erfordert dedizierte (personelle) Ressourcen. Für Organisationen mit entsprechender Kapazität bietet Backstage eine leistungsstarke und äußerst flexible Lösung für Developer-Portale.
  • Port: Port bietet ein No-Code-Setup, das einen schnellen Einstieg ermöglicht. Es verfügt auch über Automatisierungsfunktionen, mit denen auf Ereignisse reagiert oder Aktionen basierend auf Benutzereingaben ausgelöst werden können.
  • Cortex: „Cortex is the enterprise Internal Developer Portal built to accelerate the path to engineering excellence.“ Cortex bietet einen umfassenden Servicekatalog, Scorecards und Integrationen mit zahlreichen Tools. Leider sind Preise nur auf Anfrage verfügbar.

#2 Cloud Development Environments (CDEs)

Warum das wichtig ist: CDEs sind Remote-Entwicklungsumgebungen, die entweder in der Cloud oder selbst gehostet werden. Sie ermöglichen es Softwareentwickler:innen, in konsistenten, standardisierten Umgebungen zu arbeiten, wodurch typische Probleme wie „Works On My Machine“ vermieden werden. Das Plattform-Engineering-Team sorgt dafür, dass CDEs sicher, leistungsfähig und nahtlos in den Workflow eingebettet sind.

Tools, die Sie in Betracht ziehen können:

  • Cloudomation DevStack: Die Cloud Development Environments (CDEs) von Cloudomation DevStack sind vollständig gleichwertig mit lokalen Entwicklungsumgebungen. Komplexe Anwendungen können direkt in der CDE ausgeführt werden. Der Quellcode kann lokal gespiegelt werden, sodass weiterhin lokale IDEs verwendet werden können. Softwareentwickler:innen müssen ihre gewohnten Arbeitsweisen nicht ändern und können mit der CDE arbeiten wie mit ihrer lokalen Umgebung, nur mit mehr Ressourcen.
  • Gitpod: Mit Gitpod lassen sich Umgebungen starten, die für Softwareentwickler:innen und ihre Agents auf Enterprise-Niveau konzipiert sind.
  • Coder: Coder stellt sichere Umgebungen für Softwareentwicklerentwickler*innen und deren Agents bereit.

Wir haben einen Artikel über aktuell verfügbare CDE-Tools geschrieben: 7 Remote Development Environments: 7 Tools im Überblick

Außerdem haben wir ein umfassendes Whitepaper erstellt, das alle wichtigen Tools und Anbieter detailliert vergleicht, inklusive einer übersichtlichen Vergleichstabelle. Soweit wir wissen, ist es bisher die einzige Ressource, die eine derart tiefgehende Gegenüberstellung von CDEs bietet.

Integration & Delivery Plane

#1 CI Pipeline

Warum das wichtig ist: CI-Pipelines automatisieren die Codevalidierung, das Testen und sorgen für schnellere Feedback-Schleifen. So werden Qualität und Effizienz im Entwicklungsprozess gesteigert.

Tools, die Sie in Betracht ziehen können:

  • Cloudomation Engine: CI-Pipelines können nativ von Grund auf gebaut, von anderen Tools migriert oder bestehende Pipelines integriert und erweitert werden. Ermöglicht die Orchestrierung und Verbindung verschiedener Tools.
  • GitHub Actions: Native CI-Lösung für GitHub mit anpassbaren Workflows.
  • CircleCI: Hochgradig skalierbar mit Unterstützung für fortgeschrittene Parallelisierung.

#2 CD Pipeline

Warum das wichtig ist: CD-Pipelines automatisieren das sichere und wiederholbare Deployment von Software in verschiedenen Umgebungen.

Tools, die Sie in Betracht ziehen können:

  • Cloudomation Engine: End-to-End-Automatisierung von Deployments. Komplexe Deployment-Logik kann mit Python umgesetzt werden. Volle Transparenz durch visualisierte Abläufe.
  • Argo CD: GitOps-basierte Auslieferung für Kubernetes-Umgebungen.
  • Flux: Kubernetes-GitOps-Controller für kontinuierlichs Deployment.
  • Octopus Deploy: Besonders geeignet für Multi-Cloud- und On-Premise-Umgebungen.

#3 Platform Orchestrator

Warum das wichtig ist: Orchestrierungstools liefern die Logik, um Workflows über verschiedene Tools und Services hinweg miteinander zu verbinden. Sie sind essenziell, um komplexe Abläufe automatisiert, konsistent und nachvollziehbar auszuführen.

Tools, die Sie in Betracht ziehen können:

  • Cloudomation Engine: Ist ein Python-Framework für Platform Engineering. Ermöglicht die Bereitstellung von Self-Service-Tools, die Automatisierung komplexer Aufgaben und vollständige Transparenz über die Infrastruktur hinweg, alles mit einem einzigen Tool.
  • Humanitec: Ein Plattform-Orchestrator, der dynamische Umgebungen bereitstellt.

Mehr erfahren: Cloudomation Engine vs. Humanitec

Monitoring & Logging Plane

#1 Observability

Warum das wichtig ist: Observability-Tools schaffen Transparenz über den Zustand, die Performance und Zuverlässigkeit von Anwendungen und Infrastruktur. Das Plattform-Engineering-Team pflegt Dashboards und Alert-Regeln.

Tools, die Sie in Betracht ziehen können:

  • Prometheus: Toolkit für Monitoring und Alerting, besonders geeignet für Kubernetes-Umgebungen.
  • Grafana: Visualisierungstool für Dashboards, das häufig mit Prometheus kombiniert wird.
  • Datadog: Cloud-Monitoring- und Analyseplattform mit umfassender Integration und Visualisierung.

#1 Secret Manager

Warum das wichtig ist: Secret Manager speichern und verteilen sensible Daten wie Zugangsdaten, API-Schlüssel und andere vertrauliche Informationen. Sie sind entscheidend, um Sicherheitsrisiken zu minimieren und Compliance-Vorgaben einzuhalten.

Tools, die Sie in Betracht ziehen können:

  • HashiCorp Vault: Branchenführende Lösung für Secret Management – flexibel, sicher und weit verbreitet.
  • AWS Secrets Manager / Azure Key Vault / GCP Secret Manager
  • Sealed Secrets (Bitnami): Tool zur Verschlüsselung von Kubernetes-Secrets, sodass sie sicher in Git gespeichert und verwaltet werden können.

Fazit

Das Ziel von Plattform-Engineering besteht nicht darin, nur die besten Tools auszuwählen, sondern diese so zusammenzusetzen, dass eine nahtlose Developer Experience entsteht. Denken Sie weniger in Kategorien wie „Welches Tool soll ich auswählen?“, sondern: „Wie kann ich eine Plattform gestalten, die für mein Team unsichtbar und gleichzeitig leistungsstark ist und dabei echten Mehrwert für das Unternehmen liefert?“

Denn die wahre Magie entsteht erst, wenn diese Tools nicht mehr einzelne Puzzlestücke sind, sondern Teil einer kohärenten Developer Platform werden, mit der Softwareentwickler:innen die zugrunde liegende Komplexität kaum bemerken, weil die Plattform nicht gehen sie arbeitet, sondern mit ihnen.

Eine schmerzhafte Lektion, die viele Plattform-Teams früh lernen: Die Funktionen einzelner Tools sind weitaus weniger entscheidend als deren Fähigkeit, sich nahtlos in die IDP einzufügen und den Softwareentwickler:innen eine gute Experience zu bieten, denn sonst bleibt selbst das beste Tool ungenutzt. Deshalb ist eine zentrale Integrationskomponente (wie ein Plattform-Orchestrator) der Schlüssel zum Erfolg einer internen Developer Platform.

Und zum Schluss...

Cloudomation Engine ist ein Plattform-Orchestrator, mit dem Sie Self-Service-Tools bereitstellen, komplexe Aufgaben automatisieren und vollständige Transparenz über Ihre Infrastruktur gewinnen.