1~
2Da Softwaresysteme immer komplexer werden  -  Microservices, Kubernetes, Multi-Cloud, CI/CD-Pipelines, Observability-Stacks  -  verbringen Entwickler mehr Zeit mit Infrastruktur und weniger Zeit mit der Entwicklung von Produkten. **Platform Engineering** löst dieses Problem, indem eine interne Plattform geschaffen wird, die Komplexität abstrahiert und Entwicklern Self-Service-Tools bietet, um schneller zu liefern.
3~
4Gartner prognostiziert, dass bis 2027 **80 % der Software-Engineering-Organisationen** Plattformteams einrichten werden. In diesem Leitfaden werden wir untersuchen, was Platform Engineering ist, warum es wichtig ist und wie man eine Internal Developer Platform von Grund auf aufbaut.
5~
6## Was ist Platform Engineering?
7~
8Platform Engineering ist die Disziplin des Entwerfens und Aufbauens von Toolchains und Workflows, die Self-Service-Fähigkeiten für Software-Engineering-Organisationen ermöglichen. Das Ergebnis ist eine **Internal Developer Platform (IDP)**  -  eine Schicht, die zwischen Entwicklern und Infrastruktur liegt.
9~
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17~
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24~
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31~
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43~
44### Platform Engineering vs DevOps
45~
46Platform Engineering ist kein Ersatz für DevOps  -  es ist die nächste Evolution. DevOps sagte: „Du baust es, du betreibst es." Platform Engineering sagt: „Wir machen das Bauen und Betreiben mühelos."
47~
48| Aspekt | DevOps | Platform Engineering |
49|--------|--------|---------------------|
50| **Fokus** | Kultur und Praktiken | Produkte und Self-Service |
51| **Ansatz** | Jedes Team verwaltet Infrastruktur | Plattformteam abstrahiert Infrastruktur |
52| **Kognitive Belastung** | Hoch (jedes Team lernt alles) | Niedrig (Golden Paths bereitgestellt) |
53| **Output** | CI/CD-Pipelines, IaC-Skripte | Internal Developer Platform |
54| **Nutzer** | Gesamtes Engineering | Plattformteam dient dem Engineering |
55~
56## Warum Platform Engineering wichtig ist
57~
58### Das Problem der kognitiven Belastung
59~
60In einer typischen modernen Organisation muss ein Entwickler verstehen:
61~
62- Git-Workflows und Branching-Strategien
63- CI/CD-Pipeline-Konfiguration
64- Container-Erstellung und Registry-Verwaltung
65- Kubernetes-Manifeste und Helm Charts
66- Cloud-Provider-Dienste (AWS/GCP/Azure)
67- Networking, DNS, TLS-Zertifikate
68- Monitoring-, Logging- und Alerting-Einrichtung
69- Datenbankbereitstellung und -migrationen
70- Sicherheitsrichtlinien und Compliance
71~
72Das ist eine enorme kognitive Belastung, die den Fokus vom eigentlichen Produkt ablenkt.
73~
74### Der Golden Path
75~
76Platform Engineering führt das Konzept der **Golden Paths** ein  -  meinungsstarke, gut unterstützte und dokumentierte Pfade für gängige Aufgaben. Ein Golden Path ist kein Zwang; Entwickler *können* abweichen, aber die Plattform macht das Richtige zum Einfachen.
77~
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88~
89**Beispiel-Golden-Path für die Erstellung eines neuen Microservices:**
901. Der Entwickler wählt „Neuer Backend-Service" im Portal
912. Wählt Sprache/Framework (Node.js, Go, Python)
923. Die Plattform erstellt automatisch: Git-Repository, CI/CD-Pipeline, Kubernetes-Namespace, Monitoring-Dashboards und Alerting-Regeln
934. Der Entwickler klont das Repository und beginnt sofort mit dem Programmieren
94~
95## Aufbau einer Internal Developer Platform
96~
97### Schicht 1: Developer Portal
98~
99Das Portal ist der zentrale Einstiegspunkt für Entwickler. Die beliebteste Open-Source-Option ist **Backstage** (von Spotify entwickelt, jetzt ein CNCF-Projekt).
100~
101Kernfunktionen:
102- **Service-Katalog**: Jeder Service, sein Besitzer, Dokumentation und Abhängigkeiten
103- **Software-Templates**: Scaffolding für neue Services mit integrierten Best Practices
104- **Technische Dokumentation**: Dokumentation als Code, gerendert und durchsuchbar
105- **Plugin-Ökosystem**: Erweiterbar mit individueller Funktionalität
106~
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127~
128### Schicht 2: Infrastruktur-Abstraktion
129~
130Entwickler sollten Terraform oder Kubernetes-YAML nicht direkt schreiben. Die Plattform sollte Abstraktionen bereitstellen.
131~
132**Werkzeuge:**
133- **Crossplane**: Kubernetes-native Infrastrukturbereitstellung
134- **Terraform mit Modulen**: Vorgefertigte, getestete Infrastrukturmodule
135- **Pulumi**: Infrastruktur als echter Code (TypeScript, Python, Go)
136~
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149~
150Anstatt RDS-Parameter, VPC-Subnetze, Sicherheitsgruppen und Backup-Richtlinien zu konfigurieren, gibt der Entwickler einfach `size: small` und `backup: daily` an. Die Plattform erledigt den Rest.
151~
152### Schicht 3: CI/CD-Standardisierung
153~
154Standardisiere CI/CD, damit Teams nicht jeweils eigene Pipelines bauen.
155~
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163~
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172~
173**Wichtige Praktiken:**
174- Gemeinsame CI/CD-Templates, die Teams einbinden (nicht kopieren)
175- Automatische Sicherheitsscans (SAST, Dependency-Audit)
176- Standardisierte Deployment-Strategien (Canary, Blue/Green)
177- Automatisches Rollback bei fehlgeschlagenen Health Checks
178~
179### Schicht 4: Observability
180~
181Vorkonfiguriertes Monitoring, damit Entwickler Dashboards und Alerts sofort einsatzbereit erhalten.
182~
183- **Metriken**: Prometheus + Grafana mit Standard-Dashboards pro Service
184- **Logging**: Strukturiertes Logging mit zentraler Sammlung (Loki, ELK)
185- **Tracing**: Verteiltes Tracing mit OpenTelemetry
186- **Alerting**: PagerDuty/Opsgenie-Integration mit sinnvollen Standardeinstellungen
187~
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199~
200## Erfolg messen
201~
202Woher wissen Sie, ob Ihre Plattform funktioniert? Verfolgen Sie diese Metriken:
203~
204### DORA-Metriken
205- **Deployment-Frequenz**: Wie oft Code die Produktion erreicht
206- **Lead Time für Änderungen**: Zeit vom Commit bis zur Produktion
207- **Änderungs-Fehlerrate**: Prozentsatz der Deployments, die Ausfälle verursachen
208- **Mittlere Wiederherstellungszeit**: Zeit zur Wiederherstellung des Dienstes nach einem Vorfall
209~
210### Plattformspezifische Metriken
211- **Zeit bis zum ersten Deploy**: Wie lange vom „neuen Service" bis zum ersten Produktions-Deploy
212- **Entwicklerzufriedenheit (NPS)**: Befragen Sie Ihre Nutzer regelmäßig
213- **Self-Service-Quote**: % der Infrastrukturanfragen, die ohne Tickets bearbeitet werden
214- **Golden-Path-Adoption**: % der Services, die dem empfohlenen Pfad folgen
215~
216## Häufige Fehler
217~
218### 1. Zu viel zu früh bauen
219Beginnen Sie mit dem größten Schmerzpunkt, nicht mit einer großen Vision. Wenn Deployments schmerzhaft sind, fangen Sie dort an. Wenn Provisioning Wochen dauert, fangen Sie dort an.
220~
221### 2. Die Plattform nicht als Produkt behandeln
222Das Plattformteam braucht einen Product Manager, Nutzerforschung und Feedback-Schleifen. Entwickler sind Ihre Kunden  -  verstehen Sie ihre Bedürfnisse.
223~
224### 3. Vorschreiben statt anziehen
225Die besten Plattformen werden freiwillig adoptiert, weil sie das Leben der Entwickler einfacher machen. Wenn Sie die Nutzung vorschreiben müssen, ist Ihre Plattform nicht gut genug.
226~
227### 4. Developer Experience ignorieren
228Eine Plattform mit schlechter UX wird nicht genutzt. Investieren Sie in klare Dokumentation, hilfreiche Fehlermeldungen und schnelle Feedback-Schleifen.
229~
230## Erste Schritte
231~
232Eine praktische Roadmap zum Aufbau Ihrer ersten IDP:
233~
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239~
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243~
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247~
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251~
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256~
257### Minimum Viable Platform
258~
2591. **Service-Katalog** (Backstage)  -  wissen, was existiert und wem es gehört
2602. **Ein Service-Template**  -  Golden Path für Ihren häufigsten Service-Typ
2613. **Standardisierte CI/CD**  -  gemeinsame Pipeline, die Teams einbinden
2624. **Grundlegende Dokumentation**  -  wie man die Plattform nutzt, wo man Hilfe bekommt
263~
264Sie können dieses MVP in 2-3 Monaten mit einem Team von 2-3 Ingenieuren aufbauen.
265~
266## Fazit
267~
268Platform Engineering bedeutet nicht, am ersten Tag die perfekte Plattform zu bauen. Es geht darum, die kognitive Belastung der Entwickler schrittweise zu reduzieren, damit sie sich auf die Produktentwicklung konzentrieren können. Fangen Sie klein an, messen Sie die Wirkung und iterieren Sie basierend auf dem Feedback der Entwickler.
269~
270Organisationen, die in Platform Engineering investieren, werden einen erheblichen Wettbewerbsvorteil haben: schnellere Lieferung, zufriedenere Entwickler und zuverlässigere Systeme.
271~
272**Ressourcen:**
273- [Team Topologies](https://teamtopologies.com/)  -  das Buch, das Plattformteams populär gemacht hat
274- [Backstage](https://backstage.io/)  -  Spotifys Open-Source-Entwicklerportal
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  Community-Definition und Best Practices
276- [platformengineering.org](https://platformengineering.org/)  -  Community, Events und Ressourcen
277~