Referenzarchitekturen für interne Entwicklerplattformen (IDPs) sind in letzter Zeit äußerst beliebt und machten über 20 % der Vorträge auf der PlatformCon 2024 aus (laut dem „State of Platform Engineering Report Vol. 3“ von Humanitec und Gitpod). Referenzarchitekturen sind hilfreich, um eine gemeinsame Sicht auf die Komponenten zu haben, die Teil einer IDP sein können. Hier möchte ich zeigen, wie Cloudomation in diese Referenzarchitekturen passt.
Referenzarchitekturen und sogenannte “Planes”
Die von platformengineering.org populär gemachte Referenzarchitektur besteht aus fünf Hauptkomponenten, den sogenannten „Planes“:
- Developer Control Plane: Alle Komponenten, über die Entwickler:innen mit der Plattform interagieren. Dazu gehören typischerweise GUIs / Portale, Versionskontrolle, Cloud-Entwicklungsumgebungen (CDEs) sowie Konfigurationsstandards, die Entwickler:innen selbst pflegen (in der Regel in ihrem 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 Automatisierungstools (z. B. Plattform-Orchestratoren) sind typischerweise in dieser Ebene angesiedelt.
- Monitoring & Logging Plane: Wie der Name schon sagt, befinden sich hier alle Überwachungs-Tools.
- Security Plane: Verwaltung von Secrets, Richtlinien-Tools und andere Sicherheits-Tools.
- Resource Plane: Rechenleistung und Speicher.
Nicht alle internen Entwicklerplattformen (IDPs) verfügen zwangsläufig über alle fünf Planes, und es ist nicht immer sinnvoll, eine IDP in genau diese fünf Ebenen aufzuteilen – beispielsweise, wenn einige von ihnen durch dasselbe Tool oder dieselbe Plattform abgedeckt werden. Dennoch ist diese Kategorisierung als Referenz und Ausgangspunkt für Gespräche über IDPs nützlich.
Wie fügt sich Cloudomation in IDP-Referenzarchitekturen ein?
Als ein Python-Framework ist Cloudomation eine flexible Lösung, die alle Automatisierungs-, Orchestrierungs- und Integrationsdienste für Ihre interne Entwicklerplattform (IDP) bereitstellen kann. Cloudomation kann in verschiedenen Rollen eingesetzt werden:
#1 Platform Orchestrator
Der häufigste Anwendungsfall für unser Produkt Cloudomation Engine in einer IDP ist die Rolle eines Plattform-Orchestrators. Als Backend Ihrer IDP übernimmt Engine folgende Aufgaben:
- Automatisierung: Mit einem Fokus auf Infrastruktur- und Deployment-Automatisierung kann Cloudomation Engine nativ Ressourcen und Anwendungen deployen.
- Orchestrierung: Vorhandene Automatisierungen werden verknüpft, verwaltet, aufgelöst und über ein Portal oder benutzerdefinierte REST-APIs verfügbar gemacht.
- Integration: Dank seiner ETL-Funktionen kann Engine Daten wie Nutzungsstatistiken, Build-Statistiken, Log-Zusammenfassungen und andere Insights aus verschiedenen IDP-Tools abrufen, validieren, aggregieren und über eine API, ein Portal oder vorhandene Dashboards bzw. Monitoring-Tools bereitstellen.
#2 Cloud Development Environment (CDE)
Wir haben Cloudomation DevStack entwickelt, um für unsere eigenen Entwickler:innen ein One-Click-Deployment von Entwicklungsumgebungen zu ermöglichen. DevStack basiert auf Cloudomation Engine und nutzt dessen Automatisierungsfunktionen zum Deployment von Infrastruktur und Software in CDEs. Es verfügt über eine CLI und eine leichtgewichtige Web-App zur Konfiguration und Verwaltung von CDEs. Mehr dazu: Was DevStack von anderen CDE-Lösungen unterscheidet.
#3 CI/CD
Mit einem besonderen Fokus auf Continuous Deployment kann Cloudomation Engine für verschiedene CI/CD-Anwendungsfälle genutzt werden:
- Native Erstellung von CI/CD-Pipelines oder Migration bestehender Pipelines aus anderen Tools (Migration als Service verfügbar).
- Integration vorhandener Tools in eine einheitliche Pipeline.
- Orchestrierung bestehender Pipelines,
- Erweiterung bestehender Pipelines.
#4 Configuration Management
Mit einem integrierten Konfigurations- und Stammdatenmanagement-System kann Engine Ihre individuelle Konfigurationslandschaft modellieren. Typischerweise umfasst dies:
- Verschiedene Konfigurationsstandards, die durch Engine verwaltet, aufgelöst und angewendet werden können.
- Weitere individuelle Konfigurationsdaten Ihrer IDP, die über das Engine-Konfigurationsmanagement modelliert und durchgesetzt werden können.
#5 Portal
Engine Forms sind leichtgewichtige, auf JSON-Schema basierende Formulare, die als einfache Benutzeroberflächen dienen können – z. B. zum Auslösen von Deployments oder Anzeigen von Pipeline-Statusinformationen. Sie sind ideal für schnelles Prototyping und einfache Anwendungsfälle, aber nicht als vollständige Portal-Lösung gedacht. Für eine IDP ist ein dediziertes Portal (z. B. Backstage) sinnvoll. Cloudomation Engine kann Daten und Dienste bereitstellen, die Entwickler:innen dann über das Portal nutzen.
Darüber hinaus verfügt Cloudomation Engine über native Integrationen mit:
- Git: Alle in Cloudomation Engine erstellten und verwalteten Benutzerinhalte (Python-Skripte, Konfigurationsdateien, Konnektoren etc.) werden nativ in Git versioniert. Nutzer:innen können Inhalte entweder direkt über die Engine-UI erstellen und bearbeiten oder das Git-Repository auschecken und Änderungen in ihrer eigenen IDE vornehmen. Sobald ein Commit erfolgt, werden die Änderungen mit Engine synchronisiert.
- HashiCorp Vault und Devolutions Secret Manager: Die native Integration dieser beiden Secret Manager ermöglicht es Nutzerinnen und Nutzern, Secrets direkt über Python zuzugreifen. Die Secrets werden aus den Secret Stores abgerufen und niemals in Cloudomation Engine selbst gespeichert.
Um andere Tools zu integrieren und zu orchestrieren, verfügt Cloudomation Engine über Konnektoren für:
- AWS, Azure und Google Cloud REST-Connector, der mit OpenStack (z. B. OpenShift) genutzt werden kann
- SSH
- Viele weitere Konnektoren für verschiedene Tools, Protokolle und Schnittstellen
Die vollständige Liste der verfügbaren Konnektoren finden Sie hier in unserer Dokumentation.
Fazit
Cloudomation Engine ist ein Python-basierter Plattform-Orchestrator für Ihre interne Entwicklerplattform (IDP). Eine Minimum Viable IDP kann mit Cloudomation, Backstage und einem Cloud-Provider aufgebaut werden.
Seine Stärken zeigt Cloudomation besonders in komplexen Architekturen mit vielen Komponenten und anspruchsvollen Konfigurationslandschaften. Engine ermöglicht eine nachhaltige Verwaltung und Orchestrierung solcher Systeme und sorgt für mehr Transparenz, Effizienz und Automatisierbarkeit.
Ein Hinweis zu platformengineering.org und PlatformCon
Platformengineering.org (sowie internaldeveloperplatform.org und möglicherweise weitere harmlose .org-Domains) wird von PlatCo GmbH betrieben – dem Unternehmen hinter Humanitec. Sie arbeiten eng mit Gitpod zusammen. Der Großteil des Inhalts auf diesen Seiten wird von Humanitec erstellt, veröffentlicht und kuratiert, wobei Gitpod als wichtiger Mitwirkender fungiert.
Diese .org-Websites präsentieren sich als Community-Seiten, die Inhalte „von der Community, für die Community“ bereitstellen. Tatsächlich werden die Inhalte aber von PlatCo als gewinnorientiertem Unternehmen gesteuert. Dabei wird der Fokus bewusst auf Humanitec-Produkte und Gitpod gelegt – sie stehen in den Listen immer an erster Stelle, werden als Best-Practice-Beispiele dargestellt und es werden Standards etabliert, die mit ihren Produkten kompatibel sind. Letztlich dienen diese Seiten als Vertriebs- und Marketingkanal für ihre Lösungen.
Auch PlatformCon, der Platform Weekly Newsletter und der Platform Engineering Slack-Channel werden von PlatCo / Humanitec organisiert.
Ich schätze ihren Beitrag zur Community, denn ohne die aktive Unterstützung von Humanitec (und Gitpod) gäbe es vermutlich nicht eine so lebendige Plattform-Engineering-Community. Es ist großartig, dass sie Räume für den Austausch zwischen Plattformingenieuren schaffen und Wissen über Platform Engineering und IDPs verbreiten.
Dennoch halte ich es für wichtig, sich bewusst zu machen, wer hinter diesen Informationen und Community-Plattformen steht – und die Positionierung bestimmter Tools und Standards (Humanitec-Produkte, Gitpod, Score) mit einer gesunden kritischen Distanz zu betrachten.
