Der Platform Orchestrator von Humanitec

Ich habe mich gefragt, wie Workload und Infrastruktur-Deployment als eine Einheit betrachtet werden können. Gute Software ist schließlich erst dann wertvoll, wenn sie stabil mit der dazugehörigen Infrastruktur betrieben werden kann. Dabei sollen interne Developer-Plattformen helfen. Bei meiner Suche nach einer Lösung für dieses Problem im Aufbau von Developer-Plattformen bin ich auf den Platform Orchestrator gestoßen.

Was ist ein Platform Orchestrator?
Man kann sich den Platform Orchestrator als einen Rule-Engine vorstellen, die versteht, was die Entwickler*innen benötigen und es basierend auf den Konfigurationen und Templates, die vom Platform-Team bereitgestellt werden, anbietet. Humanitecs Platform Orchestrator ist eine solche Regel-Engine. Neben dem SaaS Produkt von Humanitec gibt es noch andere explizite Platform Orchestrator wie z.B. Kratix oder KusionStack. Thoughtworks hat Platform Orchestrator als Tool-Kategorie 2023 in ihr bekanntes Technologie-Radar aufgenommen. Wie einen Platform Orchestration Layer ebenfalls implementieren kann, erklärt mein Kollege Jonas Hecht in seinem Artikel Going full GitOps with Crossplane & ArgoCD.

Wir sehen immer wieder, dass sich fast jedes Plattform-Design im Wesentlichen darauf konzentriert, vorgefertigte Git-Repository Templates mit unterschiedlichsten Konfigurationsdateien über ein vermeintliches Developer-Portal bereitzustellen. Danach bleibt es den Entwickler*innen überlassen, das “Skriptchaos” zu warten. Wenn sie damit überlastet sind, übertragen sie dieses Chaos an die IT-Operations-Teams. Das Ergebnis ist, dass die Entwickler*innen langsamer werden, auf andere warten müssen und die IT-Operations-Mitarbeitenden sich durch unzählige Tickets kämpfen müssen. Dabei leidet die Time-to-Market, das Lebenselixier jedes Softwareentwicklungsprozesses.

Platform Architekturen sollten in Front- und Backend unterteilt werden. Platform Orchestrator bilden den Kern eines solchen Backends. Die Idee, die gesamte Anwendung und ihre abhängigen Ressourcen - Datenbanken, Objekt-Storage, Rechenleistung oder DNS etc. - bei jedem einzelnen Deployment neu zu konfigurieren. Ein Platform Orchestrator liest im Wesentlichen ein Rezept von Entwickler*innen und erstellt dynamisch Anwendungs- und Infrastruktur-Konfigurationen bei jedem Deployment. Auf diese Weise gibt es im Deployment keinen Unterschied zwischen dem ersten und dem x-ten Mal. Dieser Ansatz ermöglicht ein hohes Maß an Standardisierung und ermöglicht es den Plattform Engineers, hoch skalierbare sogenannte Golden-Paths zu erstellen, die standardmäßig alle Ressourcen, Konfigurationen und Richtlinien enthalten. Außerdem führt dies zur deutlichen Reduzierung der Anzahl an Konfigurationsdateien.

Der Platform Orchestrator schafft klare geteilte Verantwortung
Der Orchestrator integriert sich in die Pipeline, ist an die Image-Registry und das Secret-Management angebunden und möglicherweise auch an ein Developer-Portal und Service-Katalog - Post-CI also. Was genau der Orchestrator dort macht, basiert auf den Eingaben von zwei in der Regel unterschiedlichen Benutzergruppen. Die erste Gruppe sind die Entwickler*innen. Sie wissen am besten, welche Infrastruktur-Ressourcen ihre Workload benötigt, wie diese Ressourcen angebunden werden müssen und möglicherweise auch, wie sie mit anderen Workloads kommunizieren soll. Um dies zu beschreiben, gibt es für jede Workload ein kleines Rezept, die sogenannte Workload-Specification. In diesem Fall ist das score. Wenn die Workload beispielsweise von einer PostgreSQL-Datenbank abhängt, dann wird genau das und nur das in die Workload-Specification eingetragen. Diese Rezepte sind umgebungs agnostisch und um es möglichst einfach zu machen, basieren sie auf der YAML-Syntax und liegen im gleichen Repository wie der Applikations Code selbst.

Wir wissen jetzt, dass die Workload von einer PostgreSQL-Datenbank abhängt. Wir wissen nicht, ob wir diese Workload an eine vorhandene Datenbank anschließen oder eine neue erstellen sollen. Wir wissen auch nicht, wie wir die Konfiguration für das Anwendungs-Deployment erstellen sollen. Wie viel Rechenleistung benötigen wir? Brauchen wir Sidecars, Labels und Annotationen? Welche Security- und Compliance Anforderungen gibt es an diese Infrastrukturr Ressourcen? Diese fehlenden Informationen werden vom Platform Team, unserer zweiten Benutzergruppe, bereitgestellt. Das Platform Team hinterlegt im Orchestrator vorher sogenannte Resource Definitions. Das ist sozusagen der Capability-Katalog, den die Plattform zur Verfügung stellt und an dem sich Entwickler*innen bedienen können. Über gängige Infrastructure as Code Tools wie Terraform oder Crossplane wird beschrieben, wie in unserem Beispiel Postgres Datenbanken auszusehen haben.

Um den Ablauf jetzt einmal greifbar zu machen, gehen wir ihn Schritt für Schritt einmal durch.
Im ersten Schritt pushen wir unseren Applikations Code und unser kleines Rezept, die Workload Spezifikation, in unsere CI-Pipeline. Die CI-Pipeline pusht das Image in die Image-Registry und das Rezept an den Platform Orchestrator. Der Orchestrator erhält die Information, dass ein neues Image erstellt wurde, sowie den Pfad zu diesem Image und das Rezept selbst. Daraufhin startet nun das sogenannte RMCD-Execution Pattern. RMCD steht für Read, Match, Create and Deploy. Im Read-Schritt liest der Orchestrator das Rezept und erkennt in unserem Beispiel, dass die Workload von einer Postgres-Datenbank abhängt. Im Match-Schritt versteht er den Kontext, z.B. dass die Bereitstellung für eine Entwicklungsumgebung oder die Produktivumgebung erfolgt. Er findet dann heraus, welche Resource Definitions und Regeln, Ressource Criterias, das Platform Team in dieser Situation anwenden möchte. In der Create-Phase erstellt der Orchestrator die Anwendungskonfigurationen. Dann findet er heraus, ob die Workload an eine vorhandene Ressource angeschlossen werden soll oder ob eine neue erstellt werden muss. Wenn eine neue erstellt werden muss, kann er dies mithilfe der hinterlegten Resource Definition tun.

Anschließend ruft er die Anmeldeinformationen für die Ressource ab und indiziert sie zur Laufzeit über Secrets in den Container. In der Deploy-Phase wird die Workload bereitgestellt und wir sind fertig. Diesen Prozess wiederholt der Orchestrator bei jeder Bereitstellung. Das hat einen erheblich positiven Einfluss auf die Standardisierung, Benutzerfreundlichkeit und Wartbarkeit der Applikations- und Infrastruktur Ressourcen über ihre gesamte Lebenszeit.

Fazit
Bei internal Developer Platforms geht es nicht darum, die initiale Bereitstellung von Services und ihre Infrastruktur Abhängigkeiten durch ein paar Templates oder ein schickes Developer-Portal zu optimieren. Tag fünfhundert, tausend oder zweitausend im Lebenszyklus dieser Komponenten sind die, wo am häufigsten zeitraubende Probleme entstehen. Deswegen liegt da auch der Hebel, um wirklich langfristig mehr Effektivität im Softwareentwicklungsprozess zu schaffen. Durch weniger und einfachere Konfigurationsdateien, klare, geteilte Verantwortlichkeiten zwischen Entwickler*innen und dem Platform Team, kann die kognitive Last in den Teams reduziert, die Hürden für die Nutzung der Plattform niedrig gehalten und folglich die Adaption der Plattform gefördert werden. Der Humanitec Platform Orchestrator kann für diese Herausforderung eine unterstützende Komponente sein.

Wenn du dich für den Aufbau interner Entwickler Plattformen oder speziell für den Platform Orchestrator von Humanitec interessierst, schau doch mal hier vorbei. Dort erklären wir unseren Ansatz für erfolgreiche Plattform Initiativen.