Was ist eine Interne Entwicklungsplattform

  • Veröffentlicht

Internal Developer Platforms (IDPs) stehen im Mittelpunkt von Platform-Engineering.

Die grundlegenden Konzepte sind:

  • Sie sollten wie ein Produkt betrachtet und behandelt werden. Das heißt, dass eine IDP einen Release , einen Product-Owner und eine Produkt-Roadmap hat, ein Prozess um Bugs zu reporten vorhanden ist und diese Bugs auch gefixt werden müssen. Eine IDP wird mit der Intention entwickelt, um Mehrwert für die Kernnutzer zu bringen: Softwareentwickler:innen.
  • Eine IDP wird von Platform-Engineers aufgebaut und gewartet. Dieser Job ist relative neu. Platform-Engineers waren oftmals DevOps-Engineers, Systemadministratoren oder Operations- oder Deployment-Specialists. Platform-Engineers sind für die IDP – als internes Produkt – verantwortlich. Einige Verantwortungsbereiche überlappen mit DevOps-Aufgaben, aber das Mindset ist anders: Platform-Engineers sind kein Service-Team, dass “Dinge für Entwickler:innen tut”, sondern sind ein Produkt-Team, dass “Dinge für Entwickler:innen baut” (Ich weiß, dass der Begriff “Dinge tun” nicht beschreibt, wie “richtiges DevOps” funktionieren sollte, aber ist nun mal die Realität in den meisten Unternehmen, die DevOps als Funktion haben).
  • Die Kernnutzer sind Software–Developer
  • Sie nutzen die Plattform im Self-Service
  • IDPs bieten Funktionen als sogenannte “Golden Paths” an. Entwickler:innen können diesen Golden Paths folgen, oder davon abweichen.
  • IDPs bevorzugen in der Regel „as-code“-Ansätze, sowohl für die Automatisierung als auch für die (automatisch generierte) Dokumentation.

IDPs stellen Funktionen bereit, die zentral für die tägliche Arbeit von Sofware-Entwickler:innen sind, wie zum Beispiel:

  • Dokumentation und Information über Komponenten / Software, an denen Entwickler:innen arbeiten:
    • Welche Komponenten / Software es gibt
    • Wie sie heißen
    • Wie sie miteinander verbunden sind
    • Welche Teams welche Komponenten ownen und wie ich mit ihnen in Kontakt treten kann
    • Links zur Dokumentation und den Repositories, die zu einer Komponente gehören.
    • Etc.
  • Ein Überblick über aktuelle Umgebungen: Was ist wo deployed und in welcher Version. Zum Beispiel, welche Test-Umgebung existiert und welche Komponenten in welcher Version und in welcher Konfiguration dort laufen.
  • Die Möglichkeit, mit Umgebungen zu interagieren:
    • Deployen von neuen Umgebungen (Feature-Branch-Environments, Test- oder Development-Environments)
    • Änderung der Konfiguration von bestehenden Umgebungen
    • Update von Umgebungen
    • Löschen von Umgebungen
    • Etc.
  • Den aktuellen Status und möglicherweise Statistiken über CI/CD-Pipeline(s) erhalten:
    • Welche Builds aktuellen laufen
    • Welche Builds erfolgreich / nicht erfolgreich waren
    • Welcher Commit einen Build getriggert hat
    • Etc.
  • Dokumentation von
    • Best-practices in der Entwicklung
    • Tools und Prozesse, die für die Softwareentwicklung verwendet werden
    • Etc.

Da sind nur Beispiele, welche Funktionen eine IDP haben kann. IDPs sind aber immer einzigartig. Sie werden oft von Grund auf selbst entwickelt oder stark angepasst, indem ein oder mehrere der Plattformprodukte verwendet werden. Viele Unternehmen verwenden möglicherweise etwas, das als IDP bezeichnet werden könnte, ohne es überhaupt zu merken (oder es so zu nennen) – während andere Unternehmen eine einfache Dokumentationsplattform haben, die sie als IDP bezeichnen. Das ist in Ordnung. IDPs sind keine homogene Produktkategorie, sondern ein Konzept, das in jedem Team und Unternehmen unterschiedlich umgesetzt wird.

Durch all dies zielen IDPs darauf ab, den ewigen Knoten zu lösen, der alle Softwareentwickler:innen plagt: Software ist enorm komplex, und niemand kann alles wissen, was notwendig ist, um ein vollständiges Software-Produkt zu entwickeln. Aber es ist äußerst schwierig, die Verantwortlichkeiten zwischen den Entwicklungsteams sinnvoll zu teilen. Besonders zwischen Entwicklungs- und Operations-Teams gibt es enorme und komplexe Abhängigkeiten, die zu vielen Konflikten und starken Ineffizienzen führen können. Viele Ansätze haben versucht, dies zu lösen, angefangen bei…

  • agilen Teams, die versuchen, ein breites Fachwissen innerhalb kleiner Teams zu bündeln, mit minimalen Abhängigkeiten zu anderen Teams,
  • die gesamte Idee von Microservices, die erneut darauf abzielt, Abhängigkeiten zwischen Personen und Teams zu verringern, indem kleine Teams jeweils einen Microservice unabhängig verwalten,
  • bis hin zu DevOps, das ebenfalls versucht, Development und Operations näher zusammenzubringen, um Reibungsverluste und Ineffizienzen im Informationsfluss zu beseitigen,
  • bis hin zur Idee des Plattform-Engineerings, das darauf abzielt, einige Aspekte von Operations- und Development-Tools in ein separates Team auszulagern, mit einer ausreichend flexiblen und dennoch standardisierten Schnittstelle (der IDP) für die Development-Teams.

Alles mit dem Ziel, Spezialisierung und tiefes Fachwissen zu ermöglichen, indem die Breite an Wissen, das für die Softwareentwicklung erforderlich ist, zu reduzieren. Letztlich geht es bei IDPs darum, die Komplexität der Softwareentwicklung zu verringern.

Dieser Blogpost erklärt gut und etwas ausführlicher, was Plattform-Engineering ist und wie es entstanden ist: Link zum Blogpost.

Disclaimer: platformengineering.org und internaldeveloperplatform.or

Platformengineering.org und internaldeveloperplatform.org sind scheinbar harmlose Community-Websites, die bei Google zu allen Themen rund um IDPs und Plattform-Engineering hoch gerankt werden. Ich verweise mehrmals auf sie, da sie solide Inhalte zu grundlegenden Themen in diesem Bereich bieten.

Aber: Beide Websites gehören und werden betrieben von PlatCo GmbH, dem Unternehmen hinter der Humanitec-Produktpalette. Humanitec ist äußerst dominant in der Gestaltung der Terminologie und des Diskurses rund um Plattform-Engineering und verdient Anerkennung dafür, einige der grundlegenden Konzepte des Plattform-Engineerings eingeführt zu haben.

Obwohl ich glaube, dass sie wirklich leidenschaftlich und sehr sachkundig in Bezug auf Plattform-Engineering als Disziplin und die globale Community der Plattform-Ingenieure sind, ist es wichtig zu wissen, dass es sich um ein kommerzielles Unternehmen mit kommerziellen Interessen handelt.

Daher erwähnen beide Websites Humanitec als Marktführer, Plattform-Orchestrierung als einen Kernbestandteil jeder internen Entwicklerplattform und präsentieren das Thema Plattform-Engineering und IDPs allgemein auf eine Weise, die die Positionierung ihrer Produkte unterstützt.

IDP: Interne Entwicklerplattform oder Internes Entwicklerportal?

IDP bezieht sich meist auf Interne Entwicklerplattform, aber es gibt auch viele Inhalte, die sich mit Internen Entwicklerportalen beschäftigen. Was ist der Unterschied?

  • Interne Entwicklerplattform (IDP):
    • Bezieht sich auf den gesamten Stack, der vom Plattform-Engineering-Team den Developern zur Verfügung gestellt wird. Dieser umfasst in der Regel:
      • Eine Benutzeroberfläche, oft als „Portal“ bezeichnet, die als grafische Benutzeroberfläche (GUI), Web-App, Command Line Interface (CLI) und/oder API(s) bereitgestellt wird.
      • Eine Orchestrierungs-Komponente oder ein dediziertes IDP-Backend, das eine native Automatisierung bereitstellt und zusätzlich mehrere Dienste orchestriert, wie z.B. CI/CD-Pipelines und Infrastrukturautomatisierung.
  • Internes Entwicklerportal:
    • Bezieht sich nur auf den Frontend-Teil oder die Benutzeroberfläche der Internen Entwicklerplattform. Das Portal ermöglicht es Developern, mit der IDP zu interagieren und sie zu nutzen. Häufig umfasst es:
      • Eine grafische Benutzeroberfläche, API und manchmal ein CLI.
      • Oft sind dedizierte Portal-Lösungen Frameworks, die stark angepasst und mit benutzerdefinierten Plugins erweitert werden können.
      • Das Portal dient hauptsächlich der Anzeige von Dokumentation und der Verlinkung zu anderen Tools wie Git-Repositories.
      • Wichtig: Ein Portal allein hat keine Automatisierungsfähigkeiten und orchestriert keine anderen Dienste. Es muss mit anderen Tools integriert werden, um Mehrwert zu bieten.

Wie funktionieren IDPs?

Mehr dazu können Sie hier nachlesen. 

Fazit

IDPs sind Self-Service-Plattformen, die von Platform-Engineers entwickelt werden, um die Softwareentwicklung durch Automatisierung von Deployments, Konfigurationen und Environment-Management zu optimieren. Sie fungieren als produktisierte interne Tools mit strukturierten Workflows (goldene Pfade) und as-code Automatisierung, um die Komplexität zu reduzieren.

Kurz und knapp: IDPs verringern die Komplexität und verbessern die Effizienz von Developern, indem sie Development und Operations mit standardisierten, flexiblen Tools verknüpfen.