Die perfekte Internal Developer Platform für eure Teams entwickeln

Warum also nicht einfach loslegen? Was könnte schon schiefgehen?

Wie bei vielen anderen Projekten besteht die größte Herausforderung darin, überhaupt zu starten – und zwar richtig. Doch das allein reicht nicht: Eine Plattform muss trotz aller Hindernisse fertiggestellt und genutzt werden.

In diesem Blogbeitrag beantworte ich folgende Fragen:

1. Wie startet ihr mit dem Aufbau einer Plattform?

2. Wie gestaltet ihr ihre Architektur?

3. Vor welchen Herausforderungen steht ihr? Wie könnt ihr sie bewältigen?

So startet ihr mit dem Aufbau einer Plattform

Wie wird aus einer Plattform also Realität? Der Aufbau einer IDP umfasst drei wesentliche Schritte:

1. Architektur und Softwaretools definieren

Um eine Plattform aufzubauen, müsst ihr einige wichtige Architektur- und Technologieentscheidungen treffen. Neben dem Entwicklerportal basieren die meisten Plattformen auf Kubernetes. Es schafft die Grundlage für die Abstraktionen und Paradigmen, die von den verschiedenen Softwarekomponenten genutzt werden.

2. Komponenten integrieren und Funktionen ergänzen

Sobald der Kern der Plattform steht, ist es Zeit, die verschiedenen Komponenten zusammenzuführen. Integration bedeutet mehr, als den Quellcode mit Build-Pipelines zu verbinden. Dazu gehören auch Zugriffskontrollen und die Einhaltung von Compliance-Vorgaben. So müsst ihr beispielsweise oft Sicherheitsscans und automatisierte Quality Gates in eure IDP integrieren.

3. Entwickler in die Plattform einbinden

Mithilfe von Anleitungen und Tutorials können Entwickler die Plattform nutzen, sobald sie ausreichend ausgereift ist. Sie können frühzeitig Feedback zu den Funktionen geben und Features anfordern, die ihren Workflow verbessern. Eine Plattform wird erfolgreich angenommen, wenn Entwickler aktiv dazu beitragen – etwa indem sie Vorlagen erstellen, Dokumentation schreiben und dem Dashboard individuelle Ansichten hinzufügen.

Die Plattformarchitektur gestalten

Die Architektur einer Plattform zu definieren, ist komplex. Daher liegt es nahe, vorhandene Tools und Services als Ausgangspunkt weiterzuverwenden. In vielen Fällen kann das jedoch keine gute Idee sein. Es ist sinnvoll, die Plattform so zu denken, wie sie sein sollte: als Greenfield-Projekt. So könnt ihr Altsysteme hinter euch lassen und moderne Technologien einsetzen. Doch wie geht ihr mit der Komplexität um? Beginnt mit einem soliden Fundament und überlegt dann, was den Kern der Plattform ausmacht. Auch „Referenzimplementierungen“ erleichtern den Einstieg.

Cloud-Native-Prinzipien

Das Fundament einer Plattform bilden die zugrunde liegenden technischen Ansätze und die Basis-Komponenten, die sie funktionsfähig machen. Moderne Cloud-Native-Technologien sind gezielt darauf ausgelegt, die Vorteile der Cloud zu nutzen. Sie richten sich insbesondere an skalierbare Systeme mit lose gekoppelten Komponenten, die zuverlässig und sicher sind. Ein Cloud-Native-Ansatz für den Aufbau von IDPs basiert auf einigen zentralen Prinzipien.

• Kubernetes. Neben seiner Rolle als Orchestrator prägt Kubernetes die praktische Funktionsweise moderner Anwendungen: als مجموعة zustandsloser Microservices, die mit Softwarecontainern umgesetzt werden. Dadurch lassen sich Anwendungen in Cloud-Umgebungen einfach skalieren.

• Everything as Code. Ein System wird für alle seine Komponenten, einschließlich der zugrunde liegenden Infrastruktur, als Code definiert. Dieser Code ist für Menschen lesbar und versioniert, typischerweise über YAML-Konfigurationsdateien, die in einem Versionskontrollsystem gespeichert sind.

• Sicherheit überall. Der Zugriff auf die Plattform wird durch rollenbasierte Zugriffskontrolle geregelt. Es kommt gegenseitige Authentifizierung zum Einsatz, und alle Daten werden bei der Übertragung verschlüsselt. Tokens und Zertifikate sind kurzlebig und werden automatisch generiert.

Kernkomponenten

Die beschriebenen Prinzipien sind die grundlegenden Abstraktionen für den Aufbau von Plattformen. Sie alle nutzen dieselben Kernkomponenten.

• Identität und Zugriff. Ermöglicht Nutzern die Authentifizierung und den Zugriff auf die Plattform mit den Rechten, die ihrer Rolle entsprechen. In der Regel kommen dabei Identitätsföderation und eine zentralisierte Zugriffsverwaltung zum Einsatz.

• Bereitstellung der Infrastruktur: Dazu gehören das Deployment und die Konfiguration der Infrastruktur, die die Services der Plattform unterstützt. Typische Infrastruktur umfasst Kubernetes-Cluster, Datenbanken und Netzwerkressourcen.

• Versionskontrollsystem. Speichert Code und verfolgt Änderungen im Zeitverlauf, indem es eine Historie führt. Git ist heute der De-facto-Standard und wird für Code, Konfigurationsdateien und Dokumentation genutzt.

• Continuous Integration und Continuous Delivery. Ermöglicht das Erstellen einer Anwendung, die Durchführung verschiedener Tests und das Deployment der Anwendung in eine Zielumgebung.

• Entwicklerportal. Umfasst einen Servicekatalog, Softwarevorlagen und technische Dokumente in einer einheitlichen Ansicht. In der Regel handelt es sich um ein Dashboard, das den Status verschiedener Services anzeigt und Self-Service-Funktionen bietet.

Referenzarchitekturen

Nun kennen wir die grundlegenden Komponenten einer Plattform und können für jede davon passende Software oder Services auswählen und die übrigen Komponenten ergänzen. Die Auswahl ist riesig – es gibt viel zu viele Optionen. Die Cloud Native Computing Foundation (CNCF) pflegt eine Übersicht über Open-Source-Projekte und kommerzielle Produkte. Diese Übersicht dient als Karte, um die verfügbaren Optionen zu erkunden, die übersichtlich nach Kategorien geordnet sind. Dennoch umfasst sie Hunderte von Lösungen. Die „richtigen“ für eure Plattform auszuwählen, kann eine Herausforderung sein.

Die Cloud Native Computing Foundation (CNCF) ist eine Initiative, die die Einführung moderner Technologien fördert, mit denen sich skalierbare Anwendungen in der Cloud betreiben lassen – darunter Softwarecontainer, Microservices und deklarative Programmierschnittstellen für Anwendungen. Die CNCF unterstützt außerdem ein Ökosystem aus Open-Source-Projekten, die von der Community getragen werden. Insbesondere pflegt sie eine Übersicht dieser Projekte und definiert Kennzahlen zur Bewertung ihres Reifegrads.

Plattformen sollten auf jede Organisation zugeschnitten sein. Doch gibt es „Vorlagen“, auf denen ihr aufbauen könnt? Cloud Native Operational Excellence (CNOE) möchte eine Referenzarchitektur bereitstellen, indem es Toolchains und Best Practices für den Aufbau einer IDP bündelt. CNOE setzt auf Open-Source-Lösungen und richtet sich an IDPs, die auf verschiedenen Cloud-Anbietern umgesetzt werden können. CNOE trifft folgende Technologieauswahl:

• Keycloak für Identity and Access Management.

• External Secrets Operator zur Anbindung an Vaults und Secret Manager von Drittanbietern.

• Crossplane und Terraform für Infrastructure as Code.

• Argo Workflows und Tekton für Continuous Integration.

• Argo CD und Flux für Continuous Delivery.

• Backstage als Entwicklerportal.

Cloud Native Operational Excellence (CNOE)

Cloud Native Operational Excellence (CNOE) ist eine Open-Source-Initiative zum Aufbau von Internal Developer Platforms (IDP), die von führenden Unternehmen wie Adobe, Amazon Web Services, Autodesk, Salesforce und Twilio getragen wird. CNOE ist keine fertige Plattformlösung, sondern eine Initiative zum Austausch von Entwickler-Tools und Mustern, die Organisationen für die Erstellung ihrer IDPs übernehmen können. Als Community entwickelt CNOE zudem Tools und Referenzimplementierungen für verschiedene Cloud-Anbieter.

Die Herausforderungen, auf die ihr stoßen werdet

Trotz der Vorteile braucht ihr Unterstützung beim Aufbau einer Plattform.

Komplexität managen

Eine Plattform zu entwickeln, ist anspruchsvoll. Viele Komponenten müssen sorgfältig integriert werden, damit sie wie vorgesehen funktionieren. Die Integration basiert oft auf Konfigurationsdateien unter Versionskontrolle. Dieser Ansatz ist leistungsstark, aber auch etwas umständlich. Die Dateien sind nicht besonders benutzerfreundlich und müssen möglicherweise mit spezialisierten Tools vorverarbeitet werden. 

Eine Möglichkeit, dieses Problem zu lösen, besteht darin, die über das Dashboard verfügbaren Self-Service-Funktionen der Plattform zu erweitern. So können Entwickler Ressourcen über eine benutzerfreundliche und vertraute Weboberfläche erstellen, statt sie nur zu visualisieren.

Freiheit und Governance in Einklang bringen

Entwickler könnten die Plattform als Bedrohung wahrnehmen – als Struktur, die ihre Freiheit einschränkt und ihren Workflow stört. Das passiert in der Regel, wenn die Plattform nicht die erwarteten Funktionen bietet. 

In solchen Fällen werden Entwickler nach Wegen suchen, die Plattform zu umgehen, und letztlich möglicherweise ihre eigene aufbauen. Deshalb müsst ihr Entwickler frühzeitig in den Aufbau der Plattform einbeziehen. Umfangreiches Feedback aus mehreren Teams ist äußerst wertvoll, um fundierte Entscheidungen zu treffen und den Funktionsumfang festzulegen.

Die Plattform nachhaltig gestalten

Sobald eure Plattform verfügbar ist, muss sie kontinuierlich aktualisiert, erweitert und betrieben werden. 

Ein gängiger Ansatz besteht darin, die Plattform wie ein Produkt zu behandeln und ein Platform-Team aufzubauen, das sie unterstützt. Dieser Ansatz liegt nahe, doch er birgt das Risiko, gegen die DevOps-Prinzipien zu verstoßen. Entwicklung und Betrieb werden getrennt, wodurch möglicherweise ein Plattform-Silo entsteht.

Eine Möglichkeit, diesem Risiko entgegenzuwirken, besteht darin, Entwicklern Beiträge zur Plattform zu ermöglichen, zum Beispiel durch Innersourcing – eine Methode der Softwareentwicklung, die Best Practices aus Open-Source-Projekten innerhalb eines Unternehmens anwendet.

Fazit

Der Aufbau einer Internal Developer Platform (IDP) ist entscheidend, um DevOps-Initiativen zu skalieren, ohne Entwickler zu überlasten. Doch sowohl der Einstieg als auch der Betrieb bringen Herausforderungen mit sich. Mit diesem Blogbeitrag wollte ich einen Überblick über den Aufbau einer IDP geben – von der Definition ihrer Architektur bis zur Bewältigung unvermeidlicher Hindernisse.

Ihr habt das Wissen. Jetzt ist es Zeit, loszulegen!