Platform Engineering – So optimieren Sie Ihren Bereitstellungsprozess 

Um eine Lösung zu entwickeln, wählen Entwickler die besten, ihnen zur Verfügung stehenden Tools aus. Während Unternehmen über etablierte Standards verfügen müssen, um niedrigere und vorhersehbarere Betriebskosten zu erzielen. Als Lösung dokumentieren Unternehmen häufig Lieferprozesse und akzeptable Tools. Dies verringert jedoch die Autonomie der Entwickler und erhöht ihre Arbeitsbelastung, da sie sich mit diesen Richtlinien vertraut machen und ihnen folgen müssen. 

Stattdessen sollten Unternehmen ihre Entwickler als erstklassige Benutzer behandeln und den Bereitstellungsprozess als ein Produkt betrachten. Das Produkt kann dann von Entwicklern verwendet werden, um Lösungen schneller bereitzustellen – ohne, dass ihre Autonomie eingeschränkt wird. Ein solches Produkt wird als interne Entwicklerplattform bezeichnet und in diesem Artikel werde ich die wichtigsten Annahmen und Komponenten einer solchen Plattform, sowie Beispiele für die von unseren Kunden verwendeten Tools erörtern. Sie werden auch sehen, dass die meisten davon bereits in Ihrer Organisation zu finden sind. 

Annahmen und Mission 

Da wir die Plattform als Produkt behandeln, müssen wir die Annahme und das allgemeine Ziel definieren. „Lösungen schneller und gemäß den Unternehmensstandards bereitstellen“ ist ein gutes Leitbild, aber versuchen wir es genauer. 

Aus Entwicklersicht sollte die gesamte Lösung ein Self-Service-Tool sein. Mit anderen Worten, es sollte nicht erforderlich sein, Tickets zu erstellen oder auf Maßnahmen anderer Teams zu warten. 

Offensichtlich wird es Situationen geben, in denen der Entwickler Tools benötigt, die noch nicht in der Plattform enthalten sind. In diesem Fall muss ihnen Autonomie bei der Erreichung ihres Ziels eingeräumt werden, insbesondere wenn es sich um eine rein technische Entscheidung handelt und nicht um eine strategische Unternehmensentscheidung. Diese Maßnahmen müssen jedoch den weit verbreiteten Unternehmensstandards entsprechen. Der Mechanismus zur Validierung der Unternehmensstandards sollte unbedingt unabhängig von der Plattform funktionieren. 

Da die Plattform ein Produkt ist und Entwickler ihre Benutzer sind, müssen die Nutzung und das Verhalten überwacht werden. Einerseits das Wissen, wie jede Komponente verwendet wird, andererseits das Überwachen von gemeinsamen Aufgaben, welche ohne die Hilfe der Plattform ausgeführt wurden. Dies sind natürliche Kandidaten für neue Tools, die vom Plattform-Engineering-Team hinzugefügt werden.  

Schließlich erfordert eine erfolgreiche Plattform einen GitOps-Ansatz, was bedeutet, dass der Prozess der Bereitstellung der Infrastruktur größtenteils bis zur Übernahme des Infrastruktur-als-Code-Paradigmas automatisiert wird. Was auch immer Sie tun, es muss in Form von Code vorliegen und in Git gespeichert werden. 

Jetzt ist es an der Zeit, das Leitbild für unsere Plattform zu definieren. Das häufigste Szenario ist, wenn das Unternehmen über eigene Produkte verfügt und die Plattform während des gesamten Lebenszyklus der erstellten Dienste nutzt. Entwickler müssen jeden neuen Dienst, den sie erstellen, der Plattform hinzufügen, da er Teil des Produkts werden kann. 

Andere Situationen umfassen die Erstellung vieler Proofs of Concepts (PoC), Pilot- oder Demoprojekte, die nur außerhalb der Plattform produziert werden, z. B. auf der Infrastruktur des Kunden. Schließlich nutzen einige Unternehmen die Plattform ausschließlich, um Dienstleistungen zu erstellen, die von ihren Mitarbeitern intern genutzt werden. 

Begünstigte 

Die Hauptnutzer der Plattform sind Entwickler, aber das muss nicht die einzige Gruppe sein. Unterschiedliche Datenquellen und Datenformate machen den Datensuchprozess zeitaufwändig, sodass die Art und Weise, wie die Plattform Speicherressourcen bereitstellt, die Arbeit von Data Scientists und Data-Governance-Teams vereinfachen kann. 

Engineering-Manager können auch von der Plattform profitieren, um Standards aufrechtzuerhalten und Best Practices im gesamten Unternehmen auszutauschen, z. B. in Bezug auf die Art und Weise, wie Anwendungen miteinander kommunizieren sollten oder wie die Codestruktur in einer bestimmten Art von Service aussehen sollte. Gleichzeitig benötigen Stakeholder und Sponsoren möglicherweise Berichtsfunktionen und Informationen über Kosten, die durch bestimmte Dienstleistungen oder Projekte entstehen, die auf der Plattform gehostet werden. 

Schließlich sollte auch das Plattform-Engineering-Team als einer der Nutzer betrachtet werden. Schließlich ermöglicht ihnen die Plattform, schnell neue Tools einzuführen, Messungen zu vollziehen und vor allem mehr Aufgaben an die Nutzer der Plattform zu delegieren. 

Plattform-Teams 

Aufgrund des breiten Angebots sind die Ingenieure der Plattform möglicherweise nicht als einzelnes Team organisiert. Normalerweise gibt es mindestens zwei getrennte Gruppen, nämlich das Kernplattform-Team und das Sicherheitsteam. 

Das Kernteam der Plattform kümmert sich um Projektvorlagen, Infrastruktur und CI/CD-Tools. Die Aufgaben des Sicherheitsteams konzentrieren sich auf Tools für statische Analysen und alle Arten von Scannern, die Infrastrukturskripte, Docker-Bilder analysieren oder nach vertraulichen Daten suchen, die versehentlich im Code der Anwendung hinterlassen wurden. Wenn alles wie vorgesehen funktioniert, analysieren sie alles, was die Produktteams erstellen, ohne die Bereitstellung zu verlangsamen. 

Das Sicherheits- oder Security-Team kann, obwohl es nicht immer anwesend ist, Projektvorlagen durch die Integration mit Protokollverwaltungs- und Service-Überwachungstools oder durch die Bereitstellung von Beispielen für die verteilte Ablaufverfolgung erweitern. Sie können auch sicherstellen, dass Produktteams sofort Zugriff auf Monitoring-Dashboards für jeden neuen Service erhalten. 

Dokumentation und Kommunikation 

Wir haben bereits erwähnt, dass eine erfolgreiche Plattform den GitOps-Ansatz erfordert und ähnliche Praktiken für die Dokumentation gelten. Jede Plattformkomponente in Git sollte eine Beschreibung ihres Zwecks, Beispiele und Referenzen enthalten. Auf diese Weise ist es genau wie die entsprechende Komponente versioniert und steht allen Arten von Tools zur Verfügung, die für den Veröffentlichungsprozess verantwortlich sind. 

Die Dokumentation ist und sollte nicht vollständig sein. Es wird immer Fragen geben, welche die Dokumentationen nicht beantworten können, aber das ist in Ordnung. Alles was Sie brauchen ist ein effizienter Kommunikationskanal und die Möglichkeit, um Hilfe zu bitten, entweder von den Erstellern der Plattformkomponenten oder von Ihren Kollegen. Heutzutage verwenden alle Unternehmen Kommunikationstools wie Slack oder Teams, aber es ist erwähnenswert, dass Plattform-Engineering-Teams Kanäle haben sollten, die allen offen stehen, mit Mitarbeitern im Dienst. Diese Kanäle werden Menschen mit ähnlichen Herausforderungen verbinden und zu einer unschätzbaren Quelle für Feedback darüber werden, wie ein bestimmtes Plattformelement funktioniert und welche Funktionen ihm fehlen. 

Plattformkomponenten 

Projektvorlagen 

Projekt-Bootstrapping-Lösungen wie Cookiecutter, Giter8 oder einfaches Tenpureto standardisieren die Struktur von Diensten, beschleunigen ihre Entwicklung und Bereitstellung und vereinfachen operative Aspekte. 

Nehmen wir an, dass Entwickler oft Services erstellen, die in Java geschrieben sind, die RESTfull-API verfügbar machen und auf AWS gehostet werden. Wenn sie dieselbe Vorlage verwenden, hätten alle diese Dienste eine ähnliche Paketstruktur und würden ähnlichen Namenskonventionen folgen, was das Verständnis für Personen aus anderen Teams erleichtert. 

Eine solche Vorlage kann auch Informationen über die Infrastrukturressourcen enthalten, die zum Hosten eines solchen Dienstes erforderlich sind, oder zeigen, wie sie bereitgestellt werden könnten. In unserem Beispiel kann ein aus einer Vorlage erstelltes Projekt ein separates Paket mit AWS CDK-Code zur Bereitstellung von Fargate und RDS haben, die jeweils zum Hosten von Anwendungen und zum Speichern von Daten verwendet werden. Entwickler müssen möglicherweise die Parameter solcher Ressourcen feinabstimmen, aber zumindest ist dies ein Ausgangspunkt. 

Die Vorlage kann auch Beispiele dafür enthalten, wie eine ordnungsgemäße Protokollierung und Ablaufverfolgung aussehen sollte. Dadurch wird die Wahrscheinlichkeit erheblich erhöht, dass der Service, sobald er produktiv ist, den Überwachungs-Service korrekt über seinen Status und seine Verwendung informiert. 

Schließlich kann die Vorlage den Entwickler dazu zwingen, Metainformationen über die Anwendung einzugeben, wie z. B. Zweck, Wichtigkeit oder Zielgruppe. Solche Informationen können in einem Servicekatalog verwendet werden und helfen der Organisation, ihre Anwendungen zu verwalten. 

CI/CD 

Die Plattform sollte Entwickler davon befreien, sich Gedanken über den Erstellungsprozess zu machen. Das Warten auf einen Build- oder Bereitstellungsagenten ist Zeitverschwendung, daher müssen sie nach Bedarf verfügbar sein. Die besten Lösungen, die wir gesehen haben, basierten auf serverlosen oder Kubernetes-basierten Dienstleistungen und wurden mit dem IaaC-Ansatz bereitgestellt. Angenommen, das Unternehmen aus unserem Beispiel verwendet Jenkins, würden solche Agenten mit benutzerdefinierten AWS CDK-Ressourcen erstellt. 

Unterschiedliche Service-Arten erfordern unterschiedliche Build-Agents. In unserem Fall wäre das ein Agent, der eine Java-Anwendung erstellen kann. Daher sollten Plattformteams diese oder Agenten-Images pflegen, sodass die Entwickler nur angeben müssten, welcher Agent erforderlich ist. Im besten Fall wären diese Informationen sowieso in der Projektvorlage enthalten. 

Infrastruktur als Code 

Cloud-Ressourcen, die von einer neu erstellten Anwendung benötigt werden, müssen aus Code erstellt werden. Das ist jedoch noch nicht alles. Die Plattform muss Vorlagen zum Erstellen von Ressourcen bereitstellen und es Entwicklern gleichzeitig ermöglichen, ihre eigenen Skripte von Grund auf neu zu schreiben. 

Der GitOps-Ansatz garantiert, dass der Bereitstellungsprozess automatisiert werden kann, und ermöglicht es der Plattform, IaC-Skripte mit Arten von Services zu kombinieren, die Entwickler erstellen. Dies können Rechendienste (z. B. EC2, AKS, Lambdas) oder Speicherdienste (z. B. S3, EBS) sein, aber auch CI/CD-Elemente (Build and Deploy-Agents) und Monitoring (Dashboards, Alarme). In unserem Java-Anwendungsbeispiel wird dies erreicht, indem einfach Vorlagen (in diesem Fall AWS CDK, aber es kann sich auf Terraform oder Azure Bicep verlassen) in den Anwendungscode eingebettet werden, aber man kann anspruchsvollere Tools wie Platform Orchestrators (z. B. Hummanitec) verwenden. 

Dennoch gibt es zwei Risiken in diesem Ansatz. Der erste ist, dass die Vorlagenbibliothek möglicherweise nicht das enthält, was der Entwickler derzeit benötigt. Dies kann ein weniger beliebter oder neuer Dienst sein, der von einem Cloud-Anbieter angeboten wird. Zweitens können die Vorlagen einfach zu komplex sein, um effizient verwendet zu werden und wir haben ein solches Beispiel im Fall von Terraform-basierten Vorlagen gesehen. Aus diesem Grund müssen Entwickler in der Lage sein, ihre eigenen Bereitstellungsskripts zu erstellen. Wenn ein Unternehmen nur Terraform verwenden möchte, ist das in Ordnung, aber es sollte die Leute nicht zwingen, nur die auf der Plattform verfügbaren Vorlagen zu verwenden. 

Der Vorteil von Vorlagen besteht darin, dass Plattformteams eine bessere Kontrolle darüber haben, was bereitgestellt wird. Auf diese Weise können sie angeben, was erstellt werden kann und was nicht. Sie können sicherstellen, dass Ressourcen richtig gekennzeichnet sind und wissen zu welchem Projekt sie gehören und wer sie bezahlen soll. Es gibt jedoch einen anderen Weg, dies zu erreichen. 

Policy-as-Code 

Policy-as-Code dient als flexibler Mechanismus, der die Richtlinien einer Organisation auf kostengünstige und konkrete Weise überprüfen kann. Sie können mehrere Aspekte abdecken, darunter Compliance, Security, Kostenoptimierung und Architektur. Tools wie Azure Policies und Cloud Custodian können sowohl die bereits vorhandenen Ressourcen als auch IaC-Skripte (Open Policy Agent) validieren. Im letzteren Fall fungieren Richtlinien als eine Art Integrationstest. 

Dennoch können sie in die Integrationspipeline eingebettet werden und dem Produktteam bei Regelverstößen sofortiges Feedback geben. Während dies die in Ressourcenvorlagen codierte Logik duplizieren kann, besteht das Ziel nicht darin, Duplikate zu vermeiden, sondern eine Lösung bereitzustellen, die Entwickler und andere Beteiligte zufriedenstellt. 

Entwicklerportal und CLIs 

Interne Entwicklerportale (IDP) bieten einen Ausgangspunkt für Entwickler und führen sie durch den Serviceerstellungsprozess. Sie sind wertvolle Werkzeuge, aber noch nicht zwingend erforderlich. 

Entwickler sind daran gewöhnt, Dokumentation zu lesen, Code zu lesen (was tatsächlich eine Art von Dokumentation ist) und verschiedene Arten von Befehlszeilenschnittstellen (CLIs) zu verwenden. Ein IDP kann alle oben genannten Komponenten kombinieren und beim Erstellen des Grundgerüsts der Anwendung behilflich sein. Es stellt auch die Infrastruktur bereit - automatisch - und stellt die Einhaltung von Richtlinien sicher. Denken Sie nur daran, dass IDP selbst nur das Sahnehäubchen ist und eine solide Grundlage erfordert, über die wir gesprochen haben. 

Bevor Sie in einen IDP investieren, müssen Sie außerdem bewerten, ob der Umfang Ihrer Entwicklung, die Anzahl der Entwickler und Benutzer ein solches Produkt rechtfertigen. Wenn ja, haben Sie zwei Möglichkeiten. Entweder Sie bauen es selbst oder Sie finden ein Standardprodukt, das Ihren Anforderungen entspricht. Bei unseren Kunden haben wir bisher nur individuell maßgeschneiderte Lösungen gesehen, aber das kann daran liegen, dass viele Produkte nicht lange genug verfügbar sind. 

Derzeit sind die beiden besten Standardoptionen Backstage.io und Configure8. Backstage.io ist ein Open-Source-Projekt, das von Spotify gestartet und in CNCF aufgenommen wurde; es hat derzeit den Inkubationsstatus. Seine Integrationen und Funktionen beruhen auf Plugins von dedizierten Marketplaces. Wenn Sie also Azure DevOps in Ihrem CI verwenden, sollten Sie theoretisch in der Lage sein, Plugins zu finden, die Backstage mit Azure DevOps integrieren. 

Dies sind jedoch keine echten „Plugins“, da jedes zusätzliche Codierung und Bereitstellung erfordert. Darüber hinaus gibt es nur wenige Plugins und sie werden oft von einer einzelnen Person erstellt, sodass das Risiko des Abbruchs zu hoch ist, um eine solche Lösung zu empfehlen. Es funktioniert für Spotify, ist ein interessantes Projekt, aber noch nicht ausgereift genug. 

Ein weiteres Produkt, diesmal kommerziell, ist Configure8, aber wir können im Moment keine Empfehlungen dafür geben. 

Zusammenfassung 

Eine interne Entwicklerplattform stellt den Entwicklern Tools zur Verfügung, mit denen sie Anwendungen schnell und effizient erstellen und bereitstellen können. Durch die Aufrechterhaltung einer standardisierten und optimierten Entwicklungsumgebung kann die Plattform: Entwicklungszeit und -kosten reduzieren, die Zusammenarbeit zwischen Teams verbessern und die Gesamtqualität von Anwendungen steigern. 

Letztendlich sollte einer Investition in Plattform-Engineering immer eine gründliche Analyse der Plattformnutzer, des Entwicklungsaufwands Ihrer Organisation und der bereits implementierten Tools vorausgehen. Wenn es jedoch gerechtfertigt ist, kann es eine kluge strategische Entscheidung sein, die es Ihnen ermöglicht, bessere Dienstleistungen anzubieten und wettbewerbsfähig zu bleiben.