1 
2Jak se softwarové systémy stávají složitějšími  -  mikroslužby, Kubernetes, multi-cloud, pipeline CI/CD, observability stacky  -  vývojáři tráví více času infrastrukturou a méně času budováním produktů. **Platform Engineering** to řeší vytvořením interní platformy, která abstrahuje složitost a poskytuje vývojářům samoobslužné nástroje pro rychlejší dodávání.
3 
4Gartner předpovídá, že do roku 2027 **80 % organizací softwarového inženýrství** zřídí platformové týmy. V tomto průvodci prozkoumáme, co je Platform Engineering, proč je důležitý a jak vybudovat Internal Developer Platform od nuly.
5 
6## Co je Platform Engineering?
7 
8Platform Engineering je disciplína navrhování a budování řetězců nástrojů a pracovních postupů, které umožňují samoobslužné schopnosti pro organizace softwarového inženýrství. Výstupem je **Internal Developer Platform (IDP)**  -  vrstva, která se nachází mezi vývojáři a infrastrukturou.
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 není náhradou DevOps  -  je to další evoluce. DevOps řekl „ty to stavíš, ty to provozuješ." Platform Engineering říká „stavění a provoz uděláme snadným."
47 
48| Aspekt | DevOps | Platform Engineering |
49|--------|--------|---------------------|
50| **Zaměření** | Kultura a praktiky | Produkty a samoobsluha |
51| **Přístup** | Každý tým spravuje infra | Platformový tým abstrahuje infra |
52| **Kognitivní zátěž** | Vysoká (každý tým se učí vše) | Nízká (zlaté cesty poskytnuty) |
53| **Výstup** | Pipeline CI/CD, IaC skripty | Internal Developer Platform |
54| **Uživatelé** | Celé inženýrství | Platformový tým slouží inženýrství |
55 
56## Proč je Platform Engineering důležitý
57 
58### Problém kognitivní zátěže
59 
60V typické moderní organizaci musí vývojář rozumět:
61 
62- Git workflow a strategie větvení
63- Konfigurace pipeline CI/CD
64- Sestavování kontejnerů a správa registrů
65- Manifesty Kubernetes a Helm Charts
66- Služby poskytovatele cloudu (AWS/GCP/Azure)
67- Sítě, DNS, TLS certifikáty
68- Nastavení monitoringu, logování, alertingu
69- Provisioning a migrace databází
70- Bezpečnostní politiky a compliance
71 
72To je obrovská kognitivní zátěž, která odvádí pozornost od skutečného produktu.
73 
74### Zlatá cesta
75 
76Platform Engineering zavádí koncept **zlatých cest**  -  názorových, dobře podporovaných a zdokumentovaných cest pro běžné úkoly. Zlatá cesta není příkaz; vývojáři se *mohou* odchýlit, ale platforma dělá správnou věc snadnou.
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**Příklad zlaté cesty pro vytvoření nové mikroslužby:**
901. Vývojář vybere „Nová Backend služba" na portálu
912. Zvolí jazyk/framework (Node.js, Go, Python)
923. Platforma automaticky vytvoří: Git repozitář, pipeline CI/CD, Kubernetes namespace, monitorovací dashboardy a pravidla alertů
934. Vývojář naklonuje repozitář a okamžitě začne kódovat
94 
95## Budování Internal Developer Platform
96 
97### Vrstva 1: Developer Portal
98 
99Portál je jednotný vstupní bod pro vývojáře. Nejpopulárnější open-source možností je **Backstage** (vytvořen Spotify, nyní CNCF projekt).
100 
101Klíčové funkce:
102- **Katalog služeb**: Každá služba, její vlastník, dokumentace a závislosti
103- **Softwarové šablony**: Scaffolding pro nové služby s vestavěnými best practices
104- **Technická dokumentace**: Dokumentace jako kód, vyrenderovaná a prohledávatelná
105- **Ekosystém pluginů**: Rozšiřitelný o vlastní funkcionalitu
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### Vrstva 2: Abstrakce infrastruktury
129 
130Vývojáři by neměli psát přímo Terraform nebo Kubernetes YAML. Platforma by měla poskytovat abstrakce.
131 
132**Nástroje:**
133- **Crossplane**: Kubernetes-nativní provisioning infrastruktury
134- **Terraform s moduly**: Předpřipravené, otestované moduly infrastruktury
135- **Pulumi**: Infrastruktura jako skutečný kód (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 
150Místo konfigurace RDS parametrů, VPC subnetů, bezpečnostních skupin a zálohovacích politik vývojář jednoduše zadá `size: small` a `backup: daily`. Platforma se postará o zbytek.
151 
152### Vrstva 3: Standardizace CI/CD
153 
154Standardizujte CI/CD, aby si týmy nestavěly každý vlastní pipeline.
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**Klíčové praktiky:**
174- Sdílené CI/CD šablony, které týmy includují (nekopírují)
175- Automatické bezpečnostní skenování (SAST, audit závislostí)
176- Standardizované strategie nasazení (canary, blue/green)
177- Automatický rollback při selhání health checků
178 
179### Vrstva 4: Observabilita
180 
181Předkonfigurovaný monitoring, aby vývojáři dostali dashboardy a alerty ihned k dispozici.
182 
183- **Metriky**: Prometheus + Grafana se standardními dashboardy na službu
184- **Logování**: Strukturované logování s centralizovaným sběrem (Loki, ELK)
185- **Tracing**: Distribuovaný tracing s OpenTelemetry
186- **Alerting**: Integrace PagerDuty/Opsgenie s rozumnými výchozími hodnotami
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## Měření úspěchu
201 
202Jak poznáte, že vaše platforma funguje? Sledujte tyto metriky:
203 
204### Metriky DORA
205- **Frekvence nasazení**: Jak často se kód dostane do produkce
206- **Doba dodání změn**: Čas od commitu do produkce
207- **Míra selhání změn**: Procento nasazení způsobujících výpadky
208- **Střední doba obnovy**: Čas na obnovení služby po incidentu
209 
210### Metriky specifické pro platformu
211- **Čas do prvního nasazení**: Jak dlouho od „nové služby" do prvního produkčního nasazení
212- **Spokojenost vývojářů (NPS)**: Pravidelně dotazujte uživatele
213- **Poměr samoobsluhy**: % požadavků na infrastrukturu vyřízených bez ticketů
214- **Adopce zlaté cesty**: % služeb následujících doporučenou cestu
215 
216## Časté chyby
217 
218### 1. Budovat příliš mnoho, příliš brzy
219Začněte s největším bolestivým bodem, ne s velkou vizí. Pokud jsou nasazení bolestivá, začněte tam. Pokud provisioning trvá týdny, začněte tam.
220 
221### 2. Nepřistupovat k platformě jako k produktu
222Platformový tým potřebuje produktového manažera, výzkum uživatelů a smyčky zpětné vazby. Vývojáři jsou vaši zákazníci  -  pochopte jejich potřeby.
223 
224### 3. Nařizovat místo přitahovat
225Nejlepší platformy jsou přijímány dobrovolně, protože usnadňují život vývojářům. Pokud musíte nařizovat používání, vaše platforma není dostatečně dobrá.
226 
227### 4. Ignorovat vývojářský zážitek
228Platforma s hrozným UX nebude používána. Investujte do jasné dokumentace, užitečných chybových zpráv a rychlých smyček zpětné vazby.
229 
230## Jak začít
231 
232Praktický plán pro budování vaší první 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### Minimální životaschopná platforma
258 
2591. **Katalog služeb** (Backstage)  -  vědět, co existuje a kdo to vlastní
2602. **Jedna šablona služby**  -  zlatá cesta pro váš nejběžnější typ služby
2613. **Standardizovaný CI/CD**  -  sdílený pipeline, který týmy includují
2624. **Základní dokumentace**  -  jak platformu používat, kde získat pomoc
263 
264Toto MVP můžete vybudovat za 2-3 měsíce s týmem 2-3 inženýrů.
265 
266## Závěr
267 
268Platform Engineering není o budování dokonalé platformy od prvního dne. Je to o postupném snižování kognitivní zátěže vývojářů, aby se mohli soustředit na budování produktů. Začněte v malém, měřte dopad a iterujte na základě zpětné vazby vývojářů.
269 
270Organizace, které investují do Platform Engineering, budou mít významnou konkurenční výhodu: rychlejší dodávání, šťastnější vývojáři a spolehlivější systémy.
271 
272**Zdroje:**
273- [Team Topologies](https://teamtopologies.com/)  -  kniha, která zpopularizovala platformové týmy
274- [Backstage](https://backstage.io/)  -  open-source vývojářský portál od Spotify
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  komunitní definice a best practices
276- [platformengineering.org](https://platformengineering.org/)  -  komunita, akce a zdroje
277