Zwei Personen von hinten betrachten an der Wand befestigte Papierentwürfe mit App-Oberflächen und handschriftlichen Notizen

Platform Engineering · Interne Entwicklerplattform

Platform Engineering für moderne Entwicklungsteams

Neue Umgebung, neue Datenbank, neuer Dienst: Ihre Teams bestellen per Self-Service statt per Ticket, und die Plattform setzt Sicherheits- und Betriebsvorgaben dabei von selbst durch.

  • Golden Paths als Angebot, nicht als Pflicht
  • Backstage, Crossplane, Argo CD, OpenTofu
  • Richtlinien als Code

01Ausgangslage

Wenn jedes Team dieselben Probleme einzeln löst

SKAFFON berät und baut interne Entwicklerplattformen (Internal Developer Platforms) für Unternehmen, in denen mehrere Teams auf derselben Infrastruktur arbeiten. Entwicklerinnen und Entwickler bekommen Umgebungen, Pipelines und Datenbanken über abgestimmte Standardpfade („Golden Paths“), und die Plattform erzwingt Vorgaben automatisch.

Technisch arbeiten wir mit Kubernetes und Werkzeugen wie Backstage, Crossplane, Argo CD und OpenTofu. Das Thema ist verwandt mit, aber größer als DevOps und Automatisierung.

02Symptome

Woran Sie merken, dass eine Plattform fällig ist

Eine interne Plattform ist kein Selbstzweck. Sie lohnt sich typischerweise, wenn mehrere Teams dieselben Probleme getrennt lösen und die Kosten dafür sichtbar werden:

  • Neue Umgebungen entstehen über Tickets und dauern entsprechend.
  • Jedes Team pflegt eigene Pipelines, eigene Cluster-Konfiguration, eigene Sicherheitsregeln.
  • Betrieb und Sicherheit können Vorgaben nicht durchsetzen, weil sie nur beraten.
  • Neue Mitarbeitende brauchen lange, bis sie produktiv deployen können.

03Leistungsbausteine

Sechs Bausteine von der Strategie bis zum laufenden Betrieb

  1. 01

    Plattformstrategie

    Ergebnis: schmaler Startumfang

    Wer sind die Nutzer, welche Aufgaben sollen einfacher werden, was gehört zur Plattform und was nicht. Ergebnis ist ein schmaler Startumfang statt einer großen Plattform auf Vorrat.

  2. 02

    Golden Paths

    Angebot statt Pflicht

    Standardisierte Wege für die häufigsten Aufgaben, etwa „neuen Dienst anlegen“, „Datenbank bestellen“, „Umgebung bereitstellen“. Teams können begründet abweichen.

  3. 03

    Self-Service

    Portal oder Schnittstelle

    Teams nutzen diese Pfade ohne Ticket. Der Katalog zeigt auch, welche Dienste es gibt und wem sie gehören.

  4. 04

    Developer Experience

    Messen statt vermuten

    Dokumentation, Vorlagen, Rückmeldungen bei Fehlern und die Messung, ob die Plattform genutzt wird und wo Teams scheitern.

  5. 05

    Governance

    Richtlinien als Code

    Rechte, Netzwerkregeln, Ressourcenlimits und zulässige Images werden automatisch durchgesetzt; dazu kommt die Kostenzuordnung je Team.

  6. 06

    Betrieb der Plattform

    Übergabe oder Betrieb

    Updates, Support-Prozess und Weiterentwicklung. Übergabe an Ihr Plattformteam oder Betrieb durch SKAFFON, siehe Managed Kubernetes.

04Beispiel

Neuer Dienst mit PostgreSQL, ohne Ticket

Als Beispiel dient ein Golden Path für „neuer Dienst mit Datenbank“. Die Werkzeuge sind austauschbar: Die Datenbank-Ressource kann statt über Crossplane auch über ein OpenTofu-Modul entstehen. Die Entscheidung hängt davon ab, ob Sie Ressourcen als Kubernetes-Objekte verwalten wollen; wir begründen sie im Assessment.

Das Diagramm zeigt, wer in welchem Schritt beteiligt ist; die Liste darunter beschreibt, was in jedem Schritt technisch passiert.

Nahaufnahme eines Code-Editors mit dunklem Theme und Konfigurationscode auf einem Monitor

05

Wer wann beteiligt ist: vier Spuren

Self-Service-Anfrage: Dienst mit PostgreSQL Golden Path von der Anfrage bis zur Rückmeldung (Werkzeuge austauschbar) Entwickler Portal (Backstage) Plattform-Steuerung (Crossplane / OpenTofu) GitOps (Argo CD) + Zielumgebung 1 Anfrage stellen 2 Repo + Pipeline + Katalogeintrag 3 Merge Request im Manifest-Repo 4 Policy-Prüfung 5 Freigabe (wo verlangt) 6 Bereitstellung (Dienst + Datenbank) 7 Health-Check 8 Rückmeldung Status, Logs, Doku Prüfpunkt (Policy-Prüfung, Health-Check)
Prüfpunkte: Policy-Prüfung (Schritt 4) und Health-Check (Schritt 7).
Self-Service-Anfrage: Dienst mit PostgreSQL Werkzeuge austauschbar Entwickler 1 Anfrage stellen Portal (Backstage) 2 Repo + Pipeline + Katalogeintrag Portal (Backstage) 3 Merge Request im Manifest-Repo Plattform-Steuerung 4 Policy-Prüfung Plattform-Steuerung 5 Freigabe (wo verlangt) GitOps (Argo CD) 6 Bereitstellung (Dienst + Datenbank) GitOps + Zielumgebung 7 Health-Check Entwickler 8 Rückmeldung: Status, Logs, Doku Prüfpunkt (Policy-Prüfung, Health-Check)
Prüfpunkte: Policy-Prüfung (Schritt 4) und Health-Check (Schritt 7).

06Schritt für Schritt

Was in jedem der acht Schritte technisch passiert

  1. 01

    Anfrage

    Die Entwicklerin wählt im Portal die Vorlage „Dienst mit PostgreSQL“, trägt Namen, Team und Umgebung ein. Ein Backstage-Template stellt nur Felder zur Verfügung, die für die Vorlage zulässig sind.

  2. 02

    Repository und Pipeline

    Das Template legt das Anwendungs-Repository mit Startcode, Pipeline-Vorlage und Katalogeintrag an. Der Dienst erscheint mit Eigentümer im Software-Katalog.

  3. 03

    Manifest-Eintrag

    Das Template schreibt eine Beschreibung des gewünschten Zustands (Namespace, Deployment, Datenbankanforderung) als Merge Request in das Manifest-Repository.

  4. 04

    Policy-Prüfung

    Prüfpunkt

    Automatische Regeln prüfen erlaubte Region und Umgebung, Ressourcenlimits, Pflichtlabel für Kostenstelle und erlaubte Datenbankgröße. Verstöße ergeben eine Fehlermeldung im Merge Request, nicht ein Ticket im Betrieb.

  5. 05

    Freigabe

    Wo Ihre Regeln es verlangen, gibt eine zuständige Person frei; für unkritische Umgebungen kann die Freigabe automatisch erfolgen.

  6. 06

    Bereitstellung

    Argo CD wendet die Beschreibung im Cluster an. Für die Datenbank erzeugt Crossplane (oder ein OpenTofu-Modul) die Ressource beim gewählten Anbieter, etwa als verwaltete PostgreSQL-Instanz, und legt die Zugangsdaten im Secret-Store ab.

  7. 07

    Prüfung

    Prüfpunkt

    Ein Health-Check bestätigt, dass Dienst und Datenbank erreichbar sind; das Ergebnis geht zurück an das Portal.

  8. 08

    Rückmeldung

    Die Entwicklerin sieht im Katalog Status, Links zu Pipeline, Logs und Dokumentation. Rückbau und Änderungen laufen über denselben Weg.

07Grenzen

Was die Plattform durchsetzt und was sie nicht ersetzt

Die Plattform erzwingt Richtlinien technisch; sie ersetzt keine Rechts- oder Compliance-Prüfung. Siehe Cloud Security und DevSecOps.

  • Teams erhalten nur Rechte in ihrem Zuständigkeitsbereich (Namensräume, Projekte, Konten).
  • Geheimnisse liegen in einem Secret-Store und werden nicht durch das Portal geleitet.
  • Die Plattform läuft in Ihrer Zielumgebung, nicht in einer fremden Sammelumgebung.
Hand legt den Finger auf einen Fingerabdruckscanner mit Ziffernblock an einer Wand

08Vorbereitung

Was wir von Ihnen für das Assessment brauchen

Je klarer diese sechs Punkte vorliegen, desto genauer wird der Zuschnitt des ersten Golden Path:

  • Zahl und Struktur der Entwicklungsteams
  • Die heutigen Auslieferungswege
  • Die Zielinfrastruktur (Kubernetes bei STACKIT, Hyperscaler oder eigene Plattform)
  • Ihre Sicherheits- und Compliance-Vorgaben
  • Die Identitätsverwaltung
  • Einen Verantwortlichen für das Plattformprodukt

09Passung

Für wen sich eine eigene Plattform eignet und für wen noch nicht

Bei einem oder zwei Teams ist der Aufwand oft größer als der Nutzen. Das sagen wir im Assessment offen.

Das passt

  • Mehrere Teams lösen dieselben Probleme getrennt und die Kosten werden sichtbar.
  • Es gibt einen Verantwortlichen für die Plattform als Produkt.
  • Sie starten schmal mit einem Golden Path und erweitern anhand der Nutzung.

Das passt (noch) nicht

  • Sie haben wenige Teams und wollen zuerst Pipelines stabilisieren. Dann beginnen wir bei DevOps und Automatisierung.
  • Die Plattform soll alles auf einmal können und Teams zwingen. Dann fehlt oft die Akzeptanz; wir empfehlen einen schmalen Start.
  • Sie suchen einzelne Freelancer ohne konzeptionelle Verantwortung.

10Angebot

Wovon der Aufwand eines Plattformprojekts abhängt

Der Aufwand richtet sich nach den unten genannten Einflussfaktoren; nach ihnen richten sich Umfang und Preis des Angebots. Wir empfehlen einen Start mit einem Golden Path und erweitern anhand der Nutzung.

Wo bremst Sie das Bereitstellen von Umgebungen am meisten?

Schildern Sie Teamstruktur und größte Reibung beim Bereitstellen von Umgebungen. Mehr zum Umfeld finden Sie unter Leistungen.