Skip to main content

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:

Interne Entwicklerplattform auf Basis von Dokumenten

Platform Engineer:
Der Platform Engineer erstellt und definiert die Struktur, Werkzeuge und Prozesse für die Plattform.

Dokumentation/Blueprint:
Diese Informationen werden in Dokumentationen oder als Blueprint festgehalten, der anschließend an Entwickler weitergegeben wird.

Entwickler:
Entwickler kopieren die Informationen aus der Dokumentation oder dem Blueprint in ihre Arbeitsumgebung.
Sie führen Aufgaben wie search, replace, test (Suchen, Ersetzen, Testen) durch, bevor sie den Code auf der Plattform ausführen.
Bei Fehlern erfolgt eine Rückkopplung an den Entwickler.

Plattform:
Die Plattform ist das Ziel, auf dem der Code letztendlich ausgeführt wird.
Interne Entwicklerplattform auf Basis von Dokumenten

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:

Interne Entwicklerplattform auf Basis von Terraform-Modulen

Platform Engineer:
Der Platform Engineer stellt Terraform-Module bereit, die als Bausteine für die Plattform dienen.

Terraform-Module:
Diese Module sind vorkonfigurierte Vorlagen, die Entwicklern zur Verfügung gestellt werden, um Infrastruktur oder Plattform-Komponenten aufzubauen.
Sie sind im Bild als rote Bausteine dargestellt, mit dem Terraform-Logo gekennzeichnet.

Entwickler:
Entwickler nutzen diese Terraform-Module, um Infrastruktur lokal zu konfigurieren und aufzubauen.
Sie integrieren die Module in ihre Arbeitsabläufe und bauen darauf auf.

Plattform:
Die kombinierte Nutzung der Terraform-Module führt zur Erstellung der Plattform, dargestellt als eine Pyramide aus Bausteinen mit Kubernetes als Spitze.
Dies symbolisiert die erfolgreiche Implementierung einer Infrastruktur oder eines Systems auf Basis der bereitgestellten Terraform-Module.
Interne Entwicklerplattform auf Basis von Terraform-Modulen

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:

Portal auf Basis der internen Entwicklerplattform

Platform Engineer:
Der Platform Engineer erstellt und pflegt das Portal. Dieses Portal ist ein zentraler Ort, an dem Vorlagen und Services zugänglich gemacht werden.

Portal:
Das Portal stellt die Automatisierungslogik und die Infrastruktur-Vorlagen bereit.
Es erlaubt den Entwicklern, spezifische Konfigurationen (z. B. „T-Shirt-Größen“) auszuwählen, um eine skalierbare Plattform zu erstellen.

Entwickler:
Der Entwickler interagiert mit dem Portal, wählt die passende „T-Shirt-Größe“ (eine standardisierte Vorlage oder Konfiguration) und startet die Bereitstellung.

Plattform:
Nach der Auswahl wird die Plattform automatisch bereitgestellt.
Dies ist im Diagramm durch das Kubernetes-Symbol repräsentiert, das die Zielplattform darstellt.
Portal auf Basis der internen Entwicklerplattform

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:

1. Produkt- und Anwendungsteams (Oberste Ebene)
Diese Teams sind die Endnutzer der Plattform und arbeiten direkt mit den bereitgestellten Tools und Services.
Ihr Fokus liegt auf der Entwicklung und Bereitstellung von Produkten und Anwendungen.

2. Plattform-Interfaces (Mittel-Ebene)
Diese Ebene stellt die Schnittstellen zwischen den Produktteams und den Plattform-Fähigkeiten bereit:

Dokumentation und Suche: Ermöglicht den Zugang zu Informationen und Anleitungen.
Benutzeroberflächen (Webportale): Interaktive Oberflächen für die Interaktion mit der Plattform.
Projekt- und Umgebungs-Vorlagen: Vorgefertigte Templates, die Entwickler verwenden können.
APIs und CLIs: Programmierschnittstellen und Kommandozeilen-Tools für Automatisierung und direkte Integration.

3. Plattform-Fähigkeiten (Kern der Plattform)
Diese Ebene bietet die Kernservices der Plattform, die verschiedene Aufgaben und Automatisierungen unterstützen:

Bereitstellung von Umgebungen und Ressourcen:
Infrastruktur: Ressourcen wie Compute, Netzwerk und Speicher.
Daten: Datenbanken, Caches, Buckets.
Messaging: Nachrichtenwarteschlangen und Broker.
Identifikation und Autorisierung: Kontrolle von Benutzern und Diensten.
Scanning und Richtlinien: Überprüfung von Artefakten und Einhaltung von Richtlinien.
Automatisierung: Automatisierter Build, Test und Auslieferung.
Artefakte speichern: Speicherung in Registern und Repositories.
Services binden: Verknüpfung von Services mit Workloads (z. B. via Secrets).
Workloads beobachten: Überwachung von Anwendungen und Diensten.

4. Fähigkeiten- und Serviceanbieter (Unterste Ebene)
Diese Ebene repräsentiert die Infrastruktur- und Serviceanbieter, die die Grundlage für alle Plattform-Dienste bilden.
Dazu zählen Cloud-Anbieter, Datenbanken, Netzwerke und andere zugrunde liegende Technologien.
Capabilities of platforms

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.

Reifegrad der Automatisierung

Level 5: IDP + Porta
Level 4: Modules, Charts
Level 3: IaC + Pipelines
Level 2: IaC, CaC
Level 1: Scripting
Level 0: ClickOps
Reifegrad der Automatisierung

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.

Wo stehst du?

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.

Fertigkeiten: Cloud Native Roadmap

Imperative
Containerization
Deklarative Ansätze
API-driven
Package Management
Orchestration
Fertigkeiten: Cloud Native Roadmap

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.

Imperativ

Level 5: IDP + Portal
Level 4: Modules, Charts
Level 3: IaC + Pipelines
Level 2: IaC, CaC
Level 1: Scripting
Level 0: ClickOps
Imperative (rot markiert)
Imperativ

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.

Containerisierung wie mit Docker

Level 5: IDP + Portal
Level 4: Modules, Charts
Level 3: IaC + Pipelines
Level 2: IaC, CaC
Level 1: Scripting
Level 0: ClickOps
Containerisierung (rot markiert)
Containerisierung wie mit Docker

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.

Deklarativ


Level 5: IDP + Portal
Level 4: Modules, Charts
Level 3: IaC + Pipelines
Level 2: IaC, CaC
Level 1: Scripting
Level 0: ClickOps
Deklarativ (rot markiert)
Deklarativ

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.

API-getrieben

Level 5: IDP + Portal
Level 4: Modules, Charts
Level 3: IaC + Pipelines
Level 2: IaC, CaC
Level 1: Scripting
Level 0: ClickOps
Containerisierung (rot markiert)
API-driven

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).

Paket-Management wie Helm Charts

Level 5: IDP + Portal
Level 4: Modules, Charts
Level 3: IaC + Pipelines
Level 2: IaC, CaC
Level 1: Scripting
Level 0: ClickOps
Paket Management (rot markiert)
Paket-Management wie Helm Charts

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).

Orchestrierung wie Kubernetes

Level 5: IDP + Portal
Level 4: Modules, Charts
Level 3: IaC + Pipelines
Level 2: IaC, CaC
Level 1: Scripting
Level 0: ClickOps
Orchestrierung (rot markiert)
Orchestrierung wie 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:

Platform Engineer:
Definiert die Komponenten einer Webanwendung (Deployment, Service, Ingress, ServiceAccount).

Magic Operator:
Übersetzt die Abstraktion (Webapp) in konkrete Ressourcen und führt die Bereitstellung aus.

Developer:
Konfiguriert nur die notwendigen Parameter (z. B. image, hostName) über eine benutzerdefinierte Ressource (CR), ohne sich mit den Details zu beschäftigen.

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:

Humanitec Score

Developer: Definiert Anwendung in score.yaml (z. B. product-service, Ressourcen wie PostgreSQL, DNS).

Infrastructure & Operations: Legt Ressourcen je Kontext (z. B.
Humanitec Score

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:

Fertigkeiten: Cloud Native Roadmap

Skala: Low → High

Stufen:
Imperative
Containerization
Deklarative
Package Management
API-driven
Orchestration

Markierung:

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.

PLATFORM: Plattform-Team liefert Services.

Kubernetes-Container-Schiff: Infrastruktur/Plattform.

FEATURES: Plattform ermöglicht Entwicklern die Erstellung von Features.

DEVELOPER: Entwickler nutzt bereitgestellte Features und Services.

Pfeile: Veranschaulichen den Fluss von Services (Plattform → Infrastruktur) und Features (Infrastruktur → Entwickler).

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

Akteure:
Service Owner: Verwendet Dashboards.
Platform: Liefert Services.
Developer: Nutzt Features.
Provider: Verantwortlich für Alerting.

Kubernetes-Container-Schiff: Plattform-Infrastruktur.

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:

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!