Platform engineering — jak jsme vybudovali interní developer platformu

„Potřebuju nové prostředí.” Dřív to znamenalo ticket, dva týdny čekání a frustrovaného vývojáře. Dnes to znamená klik v portálu a za 10 minut má běžící Kubernetes namespace s databází, monitoring a CI/CD pipeline. Takhle vypadá naše interní developer platforma — a tady je, jak jsme ji vybudovali.

Proč platform engineering¶

S 30+ microservices a 5 vývojovými týmy jsme narazili na scaling problém. Ne technický — organizační. Každý tým řešil deployment jinak. Infrastructure knowledge byla u 2 lidí. Onboarding nového vývojáře trval týden jen na nastavení prostředí.

Platform engineering = dedicated tým buduje interní platformu, která odstiňuje infrastrukturní komplexitu. Vývojáři se soustředí na business logiku, platforma řeší deployment, monitoring, scaling, security.

Golden paths — ne zlatá klec¶

Golden path = doporučená cesta, jak dělat věci. Chceš nový service? Tady je template (Spring Boot + Dockerfile + Helm chart + CI pipeline). Chceš databázi? Tady je provisioner (PostgreSQL na Kubernetes s backupem).

Klíčové: golden paths jsou doporučení, ne mandáty. Tým může jít mimo cestu, ale pak si řeší infrastrukturu sám. 95 % týmů zůstává na golden path, protože je to jednodušší.

Backstage — developer portál¶

Spotify’s Backstage jako self-service portál. Katalog všech služeb (ownership, dependencies, API docs, runbooks). Templates pro vytvoření nového service (cookiecutter + Backstage scaffolder). Integrace s Kubernetes, ArgoCD, Grafana, PagerDuty.

Vývojář vidí na jednom místě: své služby, jejich health, deployment historii, metriky, otevřené incidenty. Žádné přepínání mezi 10 nástroji.

Self-service infrastruktura¶

Crossplane pro infrastructure provisioning přes Kubernetes CRDs. Vývojář vytvoří YAML manifest „chci PostgreSQL databázi, 10 GB, v staging namespace” → Crossplane provisionuje Azure Database for PostgreSQL → connection string se objeví v Kubernetes Secret.

Stejný přístup pro Redis, Kafka topics, Azure Blob containers. Infra tým definuje „nabídku” (co je dostupné a s jakými parametry), vývojáři konzumují přes self-service.

CI/CD standardizace¶

Shared GitHub Actions workflows. Každý service má .github/workflows/ci.yml který volá reusable workflow z platform-workflows repozitáře. Build, test, scan (Trivy), push image, deploy přes ArgoCD — standardně pro všechny služby. Custom kroky přes extensible hooks.

Měříme developer experience¶

DORA metriky + developer satisfaction survey (čtvrtletně):

• Time to first deployment (nový service): z 5 dní na 2 hodiny
• Onboarding nového vývojáře: z 5 dní na 1 den
• Cognitive load score (survey): z 7.2 na 4.1 (z 10)
• Developer satisfaction: z 3.2 na 4.1 (z 5)

Lekce¶

Platforma je produkt. Má zákazníky (vývojáře), product ownera, roadmap, feedback loop. Budujte ji jako produkt, ne jako projekt.

Začněte malým. Nestavějte celou platformu najednou. Začněte s tím, co nejvíc bolí (u nás: environment provisioning).

Dokumentace > automatizace. Někdy stačí dobrý runbook místo plné automatizace. Automatizujte, až když je proces stabilní.

Platforma jako multiplikátor¶

Platform engineering není overhead — je to investice do rychlosti celé organizace. 3 lidi v platform týmu zrychlují 30 vývojářů. To je multiplikátor, který se vyplatí.