Platform Engineering: Ihr internes Developer-Platform aufbauen

Der Aufstieg von Platform Engineering

Platform Engineering hat sich als natürliche Weiterentwicklung von DevOps etabliert. Während DevOps Silos zwischen Entwicklung und Betrieb eingerissen hat, entdeckten viele Organisationen, dass es ein anderes Problem erzeugt, von jedem Entwickler zu verlangen, Kubernetes, Terraform und CI/CD-Pipelines zu beherrschen: kognitive Überlastung.

Platform Engineering adressiert dies durch den Aufbau einer Internal Developer Platform (IDP) – einer Self-Service-Schicht, die Infrastruktur-Komplexität abstrahiert und es Entwicklern ermöglicht, sich auf das Schreiben von Code zu konzentrieren. Laut Gartner werden bis 2026 80 % der Software-Engineering-Organisationen Plattform-Teams als interne Anbieter wiederverwendbarer Services, Komponenten und Werkzeuge etabliert haben.

Was eine gute Internal Developer Platform ausmacht

Eine gut gestaltete IDP bietet fünf Kernfähigkeiten:

• Infrastructure Provisioning – Entwickler fordern Umgebungen über ein Portal oder CLI an, nicht über Jira-Tickets
• Application Configuration Management – Standardisierte Deployment-Konfigurationen mit sinnvollen Defaults
• Environment Management – Konsistente Dev-, Staging- und Produktionsumgebungen
• Observability-Integration – Eingebautes Logging, Metriken und Tracing ab Tag eins
• Security-Guardrails – Policy-as-Code, transparent erzwungen, nicht als Blocker

Das Schlüsselprinzip sind Golden Paths – meinungsstarke, aber flexible Workflows, die das Richtige zum Einfachen machen.

Architektur einer modernen IDP

Eine typische Internal Developer Platform besteht aus diesen Schichten:

┌─────────────────────────────────────────────────┐
│              Developer Interface                 │
│   (Portal UI / CLI / API / IDE Plugins)         │
├─────────────────────────────────────────────────┤
│            Service Catalog & Docs                │
│   (Backstage / Port / Cortex)                   │
├─────────────────────────────────────────────────┤
│           Orchestration Layer                    │
│   (Crossplane / Terraform / Pulumi)             │
├─────────────────────────────────────────────────┤
│         Infrastructure Resources                 │
│   (Kubernetes / Cloud Services / Databases)      │
└─────────────────────────────────────────────────┘

Jede Schicht erfüllt einen klaren Zweck: Die Interface-Schicht bietet Self-Service-Zugang, der Katalog organisiert, was vorhanden ist, die Orchestrierungs-Schicht provisioniert, was benötigt wird, und die Infrastruktur-Schicht betreibt Ihre Workloads.

Schritt 1: Mit einem Service-Katalog über Backstage beginnen

Spotifys Backstage ist zum De-facto-Standard für Developer-Portale geworden. Es bietet eine einheitliche Sicht auf alle Services, Dokumentation und Infrastruktur in Ihrer Organisation.

Installieren Sie Backstage mit einem einzigen Befehl:

npx @backstage/create-app@latest
cd my-backstage-app
yarn dev

Definieren Sie Ihre Services über catalog-info.yaml-Dateien, die neben Ihrem Anwendungscode abgelegt sind:

# catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Handles payment processing and billing
  annotations:
    github.com/project-slug: myorg/payment-service
    backstage.io/techdocs-ref: dir:.
    pagerduty.com/service-id: P1234ABC
  tags:
    - python
    - grpc
    - tier-1
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: billing-platform
  dependsOn:
    - component:user-service
    - resource:payments-db
  providesApis:
    - payments-api

Diese eine Datei verschafft Ihrer Organisation Sichtbarkeit über Service-Ownership, Abhängigkeiten, Dokumentations-Links und On-Call-Informationen.

Schritt 2: Self-Service-Infrastruktur mit Crossplane umsetzen

Crossplane erweitert Kubernetes um die Möglichkeit, Cloud-Infrastruktur über standardisierte Kubernetes-Manifests zu provisionieren und zu verwalten. Das bedeutet, Entwickler nutzen dieselben kubectl-Workflows, die sie bereits kennen.

Definieren Sie eine wiederverwendbare Infrastruktur-Komposition für eine Datenbank:

# composition.yaml
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: postgres-standard
  labels:
    provider: aws
    database: postgresql
spec:
  compositeTypeRef:
    apiVersion: database.platform.io/v1alpha1
    kind: PostgreSQLInstance
  resources:
    - name: rds-instance
      base:
        apiVersion: rds.aws.upbound.io/v1beta1
        kind: Instance
        spec:
          forProvider:
            region: us-east-1
            instanceClass: db.t3.medium
            engine: postgres
            engineVersion: "15"
            allocatedStorage: 20
            publiclyAccessible: false
            storageEncrypted: true
            skipFinalSnapshot: false
            masterUsername: admin
          providerConfigRef:
            name: aws-provider
      patches:
        - fromFieldPath: "spec.parameters.storageGB"
          toFieldPath: "spec.forProvider.allocatedStorage"
        - fromFieldPath: "spec.parameters.size"
          toFieldPath: "spec.forProvider.instanceClass"
          transforms:
            - type: map
              map:
                small: db.t3.micro
                medium: db.t3.medium
                large: db.r6g.large

Entwickler fordern nun eine Datenbank über einen einfachen Claim an:

# database-claim.yaml
apiVersion: database.platform.io/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: my-app-db
  namespace: team-payments
spec:
  parameters:
    storageGB: 50
    size: medium
  compositionSelector:
    matchLabels:
      provider: aws
      database: postgresql

Kein Cloud-Konsolen-Zugriff nötig. Keine Terraform-Expertise erforderlich. Das Plattform-Team definiert die Guardrails, und die Entwickler bedienen sich selbst innerhalb dieser Grenzen.

Schritt 3: Software-Templates für neue Services erstellen

Backstage Software Templates erlauben es Entwicklern, neue Services aufzusetzen – mit den Best Practices Ihrer Organisation bereits eingebaut. Hier ein Template, das einen neuen Microservice inklusive CI/CD, Monitoring und Dokumentation vorkonfiguriert erstellt:

# template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: microservice-template
  title: Production Microservice
  description: Creates a new microservice with CI/CD, monitoring, and docs
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service Details
      required:
        - name
        - owner
        - language
      properties:
        name:
          title: Service Name
          type: string
          pattern: '^[a-z][a-z0-9-]*$'
        owner:
          title: Owner Team
          type: string
          ui:field: OwnerPicker
        language:
          title: Language
          type: string
          enum: [go, python, typescript]
  steps:
    - id: fetch-template
      name: Fetch Template
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      name: Create Repository
      action: publish:github
      input:
        repoUrl: github.com?owner=myorg&repo=${{ parameters.name }}
        defaultBranch: main
    - id: register
      name: Register in Catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml

Wenn ein Entwickler im Backstage-Portal auf „Create" klickt, erhält er in weniger als 60 Sekunden ein voll funktionsfähiges Repository mit Dockerfile, Helm-Charts, GitHub-Actions-Workflows, Prometheus-Metrics-Endpunkten und Katalog-Registrierung.

Schritt 4: Policies mit Open Policy Agent erzwingen

Ihre Plattform sollte Sicherheit und Compliance automatisch machen. Verwenden Sie Open Policy Agent (OPA) zusammen mit Gatekeeper, um organisatorische Policies auf Kubernetes-Admission-Ebene zu erzwingen:

# policy: require resource limits on all containers
package kubernetes.admission

deny[msg] {
  container := input.review.object.spec.containers[_]
  not container.resources.limits.memory
  msg := sprintf("Container '%v' must have memory limits set", [container.name])
}

deny[msg] {
  container := input.review.object.spec.containers[_]
  not container.resources.limits.cpu
  msg := sprintf("Container '%v' must have CPU limits set", [container.name])
}

deny[msg] {
  input.review.object.spec.containers[_].securityContext.runAsRoot == true
  msg := "Containers must not run as root"
}

Diese Policies sind für Entwickler unsichtbar, solange sie Golden Paths folgen – Verstöße tauchen nur auf, wenn jemand von den Standard-Templates abweicht, und die Fehlermeldungen führen ihn zurück.

Schritt 5: Plattform-Adoption und Entwicklerzufriedenheit messen

Eine Plattform zu bauen, ohne ihre Wirkung zu messen, ist Blindflug. Tracken Sie diese Metriken:

• Time to First Deploy – Wie lange es von „Ich habe eine Idee" bis zum Betrieb in Produktion dauert
• Deployment-Frequenz pro Team – Liefern Teams nach Einführung der Plattform schneller?
• Self-Service-Ratio – Anteil der Infrastruktur-Anfragen, die ohne Ticket erfüllt werden
• Developer-NPS – Regelmäßige Umfragen zur Entwicklerzufriedenheit mit der Plattform
• Mean Time to Onboard – Wie schnell neue Engineers produktiv werden

Nutzen Sie das eingebaute TechInsights-Plugin von Backstage oder bauen Sie Custom-Dashboards mit Prometheus und Grafana, um diese Metriken über die Zeit zu verfolgen.

Häufige Fallstricke, die es zu vermeiden gilt

Zu viel zu früh bauen. Beginnen Sie mit den schmerzhaftesten Workflows – typischerweise Environment-Provisioning und CI/CD – und erweitern Sie von dort. Eine minimale Plattform, die Entwickler tatsächlich nutzen, schlägt eine umfassende, die sie ignorieren.

Sie als reines Infrastruktur-Projekt zu behandeln. Platform Engineering dreht sich fundamental um Developer Experience. Wenn Ihr Plattform-Team nie mit Entwicklern spricht, bauen Sie das Falsche.

Die Plattform verpflichtend machen. Golden Paths sollten attraktiv sein, nicht durch Mandate erzwungen. Wenn Entwickler Ihre Plattform aktiv meiden, ist das Feedback, das Sie hören müssen.

Dokumentation vernachlässigen. Jedes Template, jede API, jeder Workflow braucht klare Dokumentation. Backstages TechDocs-Feature erlaubt es, Docs als Markdown neben dem Code zu schreiben.

Empfohlener Tool-Stack

Schicht	Empfohlene Tools
Portal	Backstage, Port, Cortex
Infrastructure	Crossplane, Terraform, Pulumi
Orchestration	Argo Workflows, Tekton
Policy	OPA/Gatekeeper, Kyverno
Secrets	HashiCorp Vault, External Secrets Operator
Observability	Prometheus, Grafana, OpenTelemetry
GitOps	ArgoCD, Flux

Fazit

Platform Engineering bedeutet nicht, ein weiteres Tool zu bauen – es bedeutet, ein Produkt für Ihre Entwickler zu bauen. Die erfolgreichsten Plattform-Teams agieren wie interne Start-ups: Sie sprechen mit ihren Nutzern, iterieren auf Basis von Feedback und messen Outcomes konsequent.

Bei DevOpsVibe helfen wir Organisationen, Internal Developer Platforms zu designen und umzusetzen, die auf ihre Engineering-Kultur und ihren Technologie-Stack zugeschnitten sind. Ob Sie bei null anfangen oder eine bestehende Plattform skalieren – unser Team bringt praktische Erfahrung mit Backstage, Crossplane und dem gesamten Cloud-Native-Ökosystem mit. Nehmen Sie Kontakt auf, um Ihre Platform-Engineering-Reise zu beschleunigen.