Internal Developer Platform: Einblicke aus über 100 Gesprächen

Was habe ich gelernt, und wie stehe ich zum Hype um Internal Developer Platform (IDP)?

Ich komme direkt zum Fazit aus meinen Gesprächen. Ich habe bereits einen Artikel darüber geschrieben, was eine interne Entwicklerplattform (Internal Developer Platform, IDP) ausmacht und wie alles zusammenpasst: „Interne Entwicklerplattformen: Eine echte Innovation oder nur ein Trend?“. Hier sind einige Einblicke in die interne Entwicklerplattform, die ich gewonnen habe.

1. Interne Entwicklerplattformen können alles und nichts sein

Richtig gehört. Es gibt keine eindeutige Definition, was eine interne Entwicklerplattform ist. Viele haben versucht, ein Reifegradmodell für eine IDP zu erstellen – basierend auf Merkmalen, Automatisierungsgrad und dem Wert, den sie bietet.

Ich mache es einfach und zeige Ihnen, was verschiedene Unternehmen unter einer IDP verstehen.

Eine IDP kann einfach eine Dokumentation oder ein Leitfaden mit einem Blueprint für andere Teams sein. In diesem Kontext sprechen Unternehmen nicht über Terraform-Module, Helm-Charts oder Paketierungstools wie APT. Was sie wirklich meinen, ist etwas wie:

Ja, Sie haben es richtig erkannt. Es gibt Unternehmen, die sagen: „Wenn wir einen Blueprint mit Platzhaltern bereitstellen, der von verschiedenen Entwicklern genutzt werden kann, dann qualifiziert sich das für uns als IDP.“ Ich stimme dieser Perspektive teilweise zu. Team X stellt einem oder mehreren Teams eine Vorlage zur Verfügung, zusammen mit Anleitungen, wie ein Service als Self-Service konsumiert werden kann.

Eine IDP kann auch aus Terraform-Modulen bestehen, die ein Teammitglied lokal konfiguriert und bereitstellt, basierend auf einem Leitfaden für die anderen Nutzer. Das könnte so aussehen:

Das entspricht eher meiner Auffassung davon, was eine IDP ist. Man stellt Infrastructure as Code oder Configuration as Code bereit, und es müssen nur noch benutzerdefinierte Konfigurationen eingerichtet werden.

Eine IDP kann auch ein Portal sein, das einen relativ hohen Automatisierungsgrad erreicht hat. Das bedeutet, dass ich mit einem Klick oder über eine API eine Vorlage in einer bestimmten „T-Shirt-Größe“ anfordern kann und alles automatisch bereitgestellt wird. Dies bezieht sich auf etwas wie:

Man kann sehen, dass verschiedene Unternehmen unterschiedliche Auffassungen davon haben, und es gibt auch einige nachvollziehbare Gründe für diese Unterschiede. Darauf werde ich später noch eingehen.

Im Folgenden habe ich versucht, die unterschiedlichen Entwicklungsstufen der Unternehmen darzustellen, mit denen ich gesprochen habe.

2. Reifegrad der Automatisierung

In diesem Abschnitt werden wir die unterschiedlichen Zustände der Unternehmen betrachten. Es geht hier nicht um die Qualität des jeweiligen Levels, sondern vielmehr um eine Klassifizierung dessen, wo man sich selbst sieht oder wo man operiert.

Es gibt ein hervorragendes Werk von der CNCF WG Platforms, das zum Whitepaper beigetragen hat und diese großartige Grafik mit dem Titel “Capabilities of Platforms” entwickelt hat:

Wenn Sie die Fähigkeiten von Plattformen verstehen, verfügen Sie wahrscheinlich über eine breitere Perspektive als viele kleine und mittelständische Unternehmen, deren Kerngeschäft nicht in der Software- oder Produktentwicklung liegt.

Aus diesem Grund habe ich versucht, das Konzept zu abstrahieren, um es zu vereinfachen. Ich habe einen Stack erstellt, der Ihnen vermutlich vertraut sein dürfte. Im nächsten Schritt betrachten wir die verschiedenen Automatisierungsstufen.

Level 0: ClickOps

Es gibt immer noch viele Unternehmen, die ClickOps bevorzugen, sei es vor Ort (on-premises) oder in der Cloud, weil sie glauben, dass es schneller ist. Ich werde diesen Ansatz nicht bewerten; es ist einfach eine Tatsache.

Level 1: Scripting: Bash, Python oder PowerShell

Viele Unternehmen betrachten die Ausführung von Skripten als Automatisierung. Da dies nicht über Klicks erfolgt, wird es als automatisiert angesehen. Auch hier werde ich keine Bewertung abgeben.

Level 2: Infrastructure as Code und Configuration as Code

Der nächste Schritt nach Scripting ist meiner Meinung nach der Einsatz von Tools wie Terraform zur Bereitstellung von Infrastruktur und Ansible zur Konfiguration.

Level 3: Pipelines: IaC + CI/CD oder Operatoren mit CRDs

Ein Schritt weiter: IaC wird nicht mehr lokal auf einem Client-Gerät ausgeführt, sondern über eine Pipeline, oder es wird ein Tool wie Crossplane verwendet, das die entsprechenden Ressourcen automatisch bereitstellt.

Level 4: Terraform-Module, Helm-Charts und GitOps

Mit zunehmender Professionalisierung werden wiederkehrende Infrastrukturteile in Terraform-Module gepackt, um beispielsweise Infrastruktur oder Kubernetes-Cluster bereitzustellen. Anschließend wird ein GitOps-Ansatz verwendet, um Infrastruktur als Anwendung in die jeweiligen Cluster auszuliefern. Das Automatisierungsniveau ist hier ziemlich hoch. „Ziemlich hoch“ bedeutet:

1. Kann ich mit wachsenden Projekten skalieren?
2. Kann ich auch Wartung und Betrieb skalieren, um technische Schulden zu vermeiden?
3. Kann ich das Setup skalieren, ohne die Mitarbeiterzahl zu erhöhen?

Dies wird immer noch von Menschen durchgeführt, genauer gesagt vom Plattform-Team.

Level 5: Ersetze den Menschen durch ein Portal

Die nächste Stufe würde darin bestehen, die menschliche Komponente in Level 4 durch eine Abstraktionsebene zu ersetzen. Das bedeutet nicht, dass die Plattform-Teams verschwinden; jemand muss weiterhin Terraform-Module, Helm-Charts, Pipelines usw. erstellen, damit diese über eine Vorlage ausgerollt werden können.

Ich halte es für wichtig zu verstehen, auf welcher Stufe Sie sich befinden, da ich diesen Level oft mit den Fähigkeiten und Ressourcen innerhalb eines Unternehmens in Verbindung bringe. Meinen Beobachtungen zufolge gibt es eine Korrelation zwischen einem niedrigen Automatisierungsgrad und heterogenen Infrastrukturen, was wiederum oft mit Ressourcenknappheit und dem Skalieren durch zusätzliche Mitarbeiter einhergeht.

Dies spiegelt oft auch das Kompetenzniveau wider. Das bedeutet jedoch nicht, dass die Menschen schlecht qualifiziert sind – ganz im Gegenteil. Es zeigt vielmehr, wo sich mein Unternehmen derzeit auf der Cloud-native-Roadmap befindet (verwenden wir Git, Container, CI/CD, haben wir IaC und CaC, etc.).

Ich habe versucht, dies darzustellen, und ich glaube, viele werden es nachvollziehen können. Schauen wir uns zunächst einige wichtige Kompetenzpunkte auf der Cloud-native-Roadmap an. Niedrig ist schlecht, und hoch ist gut.

Nun versuchen wir, diese Punkte auf der Automatisierungsebene zu identifizieren.

Imperativ bezieht sich auf eine Anweisung oder einen Befehl, der jemanden dazu auffordert, eine spezifische Aktion oder Aufgabe auszuführen.

Containerisierung ist der Prozess, bei dem Anwendungen und ihre Abhängigkeiten in Containern gebündelt werden, sodass sie konsistent in verschiedenen Computerumgebungen ausgeführt werden können.

Deklarativ bezieht sich auf einen Programmieransatz, bei dem das gewünschte Ergebnis spezifiziert wird, ohne die Schritte zur Erreichung dieses Ergebnisses explizit vorzugeben. Das System übernimmt automatisch die Details der Implementierung.

API-Driven bezieht sich auf einen Designansatz, der die Nutzung von Programmierschnittstellen (APIs) als primäre Methode der Interaktion zwischen verschiedenen Softwarekomponenten priorisiert und so eine nahtlose Kommunikation und Integration zwischen Systemen ermöglicht.

Package-Management ist der Prozess der Automatisierung von Installation, Aktualisierung, Konfiguration und Entfernung von Softwarepaketen, um sicherzustellen, dass Softwareabhängigkeiten korrekt verwaltet und in verschiedenen Umgebungen aufrechterhalten werden (z. B. Helm-Charts, APT).

Orchestrierung bezieht sich auf die automatisierte Koordination und Verwaltung komplexer Prozesse oder Workflows, die häufig mehrere Dienste und Systeme umfassen, um sicherzustellen, dass sie effizient und effektiv zusammenarbeiten (z. B. Kubernetes).

Wie Sie sehen, gibt es eine Korrelation, die wie folgt zusammengefasst werden kann:

• Level 0–1: Überwiegend imperative Ansätze, ohne Containerisierung oder Orchestrierung.
• Level 2–3: Übergang von imperativen zu deklarativen Ansätzen, erste Schritte in Richtung Containerisierung und API-Integration.
• Level 4–5: Starke Ausrichtung auf deklarative Ansätze, umfassende Nutzung von Containerisierung, Orchestrierung und API-getriebenen Umgebungen sowie Paketverwaltung.

3. Wie IDPs passen und was sie bieten

Die meisten Lösungen, die ich gesehen habe, sind logisch ähnlich strukturiert. Ein Portal wird bereitgestellt, typischerweise basierend auf einer internen Entwicklerplattform (IDP), die in der Regel durch einen Operator zusammengehalten wird. Das bedeutet, dass es eine Möglichkeit gibt, Infrastruktur in eine Vorlage umzuwandeln, um sie nutzbar zu machen. Mit anderen Worten, es gibt eine Abstraktionsebene, die die Nutzung vereinfacht.

Es sind also normalerweise mindestens zwei Seiten beteiligt. Beispielsweise gibt es ein Plattform-Team, das Vorlagen definiert, damit Entwickler diese einfacher verwenden können. Die Entwickler wiederum werden zu Nutzern dieser Vorlagen oder können dieselben Werkzeuge nutzen, um ihre eigenen Anwendungen zu abstrahieren. Aber was bedeutet Abstraktion in diesem Zusammenhang?

Werfen wir einen Blick auf das folgende Diagramm:

Es wird deutlich, dass das Plattform-Team alles abstrahiert und definiert, was für die Bereitstellung eines Webanwendungsdienstes erforderlich ist. Der Entwickler muss nur 2–3 Werte festlegen, anstatt sich mit den gesamten Kubernetes-Manifests auseinanderzusetzen, und ein Operator übernimmt die Bereitstellung der Webanwendung.

Dies wurde in vereinfachter Form dargestellt, aber ein Portal, das auf einer IDP basiert, macht im Wesentlichen nichts anderes — nur komplexer. Wenn Sie das einfache Diagramm oben durch den Orchestrator von Humanitec ersetzen, werden Sie eine gewisse Ähnlichkeit in der Logik erkennen:

4. Für wen ist die Nutzung einer IDP geeignet?

Bevor ich versuche, diese Frage zu beantworten, möchte ich Ihnen das folgende Diagramm zeigen. Nehmen Sie sich bitte eine Minute Zeit, um darüber nachzudenken:

Ich persönlich glaube, dass man, bevor man sich mit dem Thema interner Entwicklerplattformen (IDP) und Portale beschäftigt, zunächst den Automatisierungsgrad bewerten sollte. Der Begriff „Automatisierungsgrad“ sollte hier nicht wörtlich genommen werden, sondern vielmehr als Synonym dafür, zu verstehen, wo man aktuell steht und warum.

Wenn Sie sich auf den Levels 0–1 befinden, frage ich mich persönlich, was Sie in das Portal integrieren möchten – Skripte? Wenn Sie sich auf Levels 2–3 befinden, sollten Sie vielleicht mehr investieren, um zunächst Levels 3–4 zu erreichen, bevor Sie das Thema IDP angehen. Es ist besser, Lücken, auch Kompetenzlücken, zu schließen, um eine solide Grundlage für eine IDP mit Portal zu schaffen.

Die meisten Unternehmen, die ich gesehen habe und die eine IDP aufgebaut haben, beispielsweise basierend auf Backstage, befanden sich auf Levels 4–5. Für sie sind Docker, CI/CD, IaC, Kubernetes usw. zu grundlegenden Fähigkeiten geworden, wodurch sie sich mit anderen Themen weiterentwickeln konnten.

Wenn Sie beginnen, Mathematik zu lernen, starten Sie mit den Grundrechenarten und springen nicht direkt in die fortgeschrittene Mathematik auf Universitätsniveau. Dasselbe gilt meiner Meinung nach für eine IDP + Portal. Es ist besser, eine solide Grundlage im Unternehmen zu schaffen, anstatt Trends zu folgen, die Sie sich nicht leisten können.

5. Selber machen oder kaufen?

Die meisten Unternehmen, mit denen ich gesprochen habe, insbesondere diejenigen, die unten als Nicht-Anbieter aufgeführt sind, bevorzugen SaaS-Lösungen oder selbst gehostete Optionen, wobei SaaS die bevorzugte Wahl ist. Viele Unternehmen zögern, eine IDP zu nutzen, weil sie die menschliche Komponente des Platform Engineering nicht ersetzen möchten.

Die häufigsten Aussagen (gegen MAKE OR BUY), die ich gehört habe, lauteten:

• Anbieter bieten Managed Services, und deren interne Teams oder externe Kunden haben kleinere Teams, wodurch sich der Aufwand für die Implementierung einer IDP nicht lohnt.
• Viele Unternehmen bevorzugen es, zunächst ihre verschiedenen Schichten zu professionalisieren, bevor sie mit dem Aufbau einer IDP beginnen, um eine solide Grundlage zu schaffen.
• Einige Unternehmen sagen, dass sie mit Platform Engineering und der menschlichen Komponente, die das Portal ersetzt, viel schneller sind. Sie brauchen keine MAKE OR BUY-Entscheidung für eine IDP/Portal.
• Die Komplexität ist bereits hoch, und eine weitere Ebene würde das Unternehmen nicht voranbringen.

Persönliche Einschätzung zu MAKE OR BUY:

• Unternehmen auf Level 0–3 haben andere Herausforderungen als die Einführung einer IDP/Portal. ❌
• Dienstanbieter sollten → BUY oder MAKE (Innovation, neues Produkt, etc.).
• Inhouse-IT-Unternehmen mit weniger Experten, aber auf Levels 4–5 → BUY.
• Unternehmen mit wenigen Platform Engineers und kleinen Entwicklerteams sollten → BUY oder Platform Engineering betreiben.
• Unternehmen mit 10–15 Platform Engineers und 500–1000 Entwicklern sollten → BUY.

Es ist keine einfache Entscheidung. Ich versuche immer, in Werten zu denken und mich zu fragen: Welchen Mehrwert bringt es dem Unternehmen?

• Innovation?
• Bessere Time-to-Market?
• Skalierbarkeit durch Self-Service?
• Reduzierung der kognitiven Belastung der Platform Engineers?
• etc.

Ein Punkt beschäftigt mich bei all diesen Themen jedoch sehr, den ich im nächsten Abschnitt kurz ansprechen werde.

6. Warum liegt der Fokus so stark auf Entwicklern?

Ich verstehe nicht, warum immer von der Befähigung der Entwickler gesprochen wird; manchmal fühlt es sich an, als würde man Entwickler wie kleine Kinder behandeln, die ohne Stützräder Fahrrad fahren lernen. Bestehen IT-Unternehmen wirklich nur aus Entwicklern? Um ehrlich zu sein, stört es mich, dass der Rest der IT-Fachkräfte in Unternehmen oft übersehen wird. Ist das Ziel, die Kultur zu spalten und sie dann durch DevOps 3.0 wieder zusammenzuführen?

Mit DevOps haben wir es nicht geschafft, eine Kultur zwischen Entwicklern, Betrieb und anderen Abteilungen zu schaffen, und jetzt gibt es Platform Engineering.

Um Ihnen meine Frustration zu verdeutlichen, möchte ich eine Entwicklung teilen, die nicht durch Platform Engineering entstanden ist – auch wenn es vielleicht so scheinen mag –, sondern durch GitOps mit Tools wie Argo CD. Dieses Jahr hat sich in einem großen Unternehmen eine neue Kultur entwickelt, und ich war live dabei und involviert.

Früher arbeiteten Platform Engineers/Ops enger mit Entwicklern zusammen als mit anderen Teams.

Jetzt entsteht jedoch eine Form der Zusammenarbeit, von der ich nie gedacht hätte, dass sie jemals passieren würde.

Ich sehe, dass Service-Owner eine aktive Rolle übernehmen, indem sie lernen, wie man Grafana-Dashboards und Prometheus-Alerting als Code verwaltet und diese mithilfe von Argo CD über verschiedene Cluster hinweg bereitstellt. Dies erhöht die Qualität des Service, da sie verstehen, wie der Service betrieben werden sollte. Es verbessert die Zusammenarbeit mit Entwicklern und Operations, da sie plötzlich eine gemeinsame Sprache sprechen (YAML).

Zusätzlich gibt es Service-Provider, die einen Service über mehrere Cluster hinweg bereitstellen und als Produkt-Operatoren nun ihr externes, maßgeschneidertes Alerting mithilfe derselben GitOps-Praktiken (mit Multi-Tenancy-Trennung) bereitstellen.

Wenn IDPs weiterhin mit einem entwicklerzentrierten Fokus aufgebaut werden, befürchte ich, dass die entstehende Kultur zerbröckeln wird und wir in Zukunft DevOps 3.0 benötigen, um sie wieder aufzubauen.

Sie sollten sich unbedingt das Platform Engineering Maturity Model ansehen!

Als Nächstes zeige ich Ihnen die bekanntesten Portal-Anbieter, sowohl als SaaS- als auch als selbst gehostete Lösungen, mit denen ich viele Gespräche geführt oder Input erhalten habe.

Welche Portale gibt es?

Hier ist eine Übersicht der Portale, die ich aus meinem Austausch kenne:

• port
• Mia
• Humanitec (Portal basierend auf eigenem Orchestrator + Score)
• Appsmith
• Mogenius
• Qovery
• OpsVerse
• OpsLevel
• Flanksource
• Portainer
• Kubermatic Developer Platform on KCP
• GiantSwarm (Plattform basierend auf Backstage)
• kubrix (Plattform basierend auf Backstage + Kargo)
• kratix
• Wayfinder
• Backstage.io
• meshStack
• bunnyshell
• choreo
• rely

Wenn etwas fehlt, lasst es uns gerne wissen!

Sie möchten einen Beitrag zu diesem Thema leisten? Dann los! → https://tag-app-delivery.cncf.io/

Kontaktinformationen

Wenn du mehr über IDP erfahren möchtest dann kontaktiere uns hier oder füge mich einfach in dein LinkedIn-Netzwerk hinzu!