1 
2Ahogy a szoftverrendszerek egyre összetettebbé válnak  -  mikroszolgáltatások, Kubernetes, multi-cloud, CI/CD pipeline-ok, megfigyel hetőségi veremek  -  a fejlesztők egyre több időt töltenek az infrastruktúrával és kevesebbet a termékek építésével. A **Platform Engineering** ezt úgy oldja meg, hogy létrehoz egy belső platformot, amely elvonatkoztat a bonyolultságtól, és önkiszolgáló eszközöket biztosít a fejlesztőknek a gyorsabb szállításhoz.
3 
4A Gartner azt jósolja, hogy 2027-re a **szoftvermérnöki szervezetek 80%-a** platformcsapatokat hoz létre. Ebben az útmutatóban megvizsgáljuk, mi a Platform Engineering, miért fontos, és hogyan építsünk Internal Developer Platformot a nulláról.
5 
6## Mi az a Platform Engineering?
7 
8A Platform Engineering az eszközláncok és munkafolyamatok tervezésének és építésének tudományága, amelyek önkiszolgáló képességeket tesznek lehetővé szoftvermérnöki szervezetek számára. Az eredmény egy **Internal Developer Platform (IDP)**  -  egy réteg, amely a fejlesztők és az infrastruktúra között helyezkedik el.
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 
46A Platform Engineering nem a DevOps helyettesítője  -  hanem a következő evolúció. A DevOps azt mondta: „te építed, te üzemelteted." A Platform Engineering azt mondja: „az építést és üzemeltetést könnyűvé tesszük."
47 
48| Szempont | DevOps | Platform Engineering |
49|----------|--------|---------------------|
50| **Fókusz** | Kultúra és gyakorlatok | Termékek és önkiszolgálás |
51| **Megközelítés** | Minden csapat kezeli az infrastruktúrát | A platformcsapat elvonatkoztatja az infrastruktúrát |
52| **Kognitív terhelés** | Magas (minden csapat mindent megtanul) | Alacsony (arany utak biztosítva) |
53| **Eredmény** | CI/CD pipeline-ok, IaC szkriptek | Internal Developer Platform |
54| **Felhasználók** | Az összes mérnöki terület | A platformcsapat szolgálja a mérnöki területet |
55 
56## Miért Fontos a Platform Engineering
57 
58### A Kognitív Terhelés Problémája
59 
60Egy tipikus modern szervezetben a fejlesztőnek értenie kell:
61 
62- Git munkafolyamatok és elágazási stratégiák
63- CI/CD pipeline konfiguráció
64- Konténer építés és registry kezelés
65- Kubernetes manifestek és Helm Charts
66- Felhőszolgáltató szolgáltatások (AWS/GCP/Azure)
67- Hálózat, DNS, TLS tanúsítványok
68- Monitorozás, naplózás, riasztás beállítása
69- Adatbázis kiépítés és migrációk
70- Biztonsági politikák és megfelelőség
71 
72Ez hatalmas kognitív teher, amely elvonja a figyelmet a tényleges termékről.
73 
74### Az Arany Út
75 
76A Platform Engineering bevezeti az **arany utak** fogalmát  -  véleményes, jól támogatott és dokumentált utak a gyakori feladatokhoz. Az arany út nem kötelező; a fejlesztők *eltérhetnek*, de a platform a helyes dolgot könnyűvé teszi.
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**Arany út példa új mikroszolgáltatás létrehozásához:**
901. A fejlesztő kiválasztja az „Új Backend Szolgáltatás"-t a portálon
912. Nyelvet/keretrendszert választ (Node.js, Go, Python)
923. A platform automatikusan létrehozza: Git repository, CI/CD pipeline, Kubernetes namespace, monitorozási dashboard-ok és riasztási szabályok
934. A fejlesztő klónozza a repository-t és azonnal elkezd kódolni
94 
95## Internal Developer Platform Építése
96 
97### Réteg 1: Developer Portal
98 
99A portál az egyetlen belépési pont a fejlesztők számára. A legnépszerűbb nyílt forráskódú lehetőség a **Backstage** (a Spotify készítette, most CNCF projekt).
100 
101Kulcsfontosságú funkciók:
102- **Szolgáltatáskatalógus**: Minden szolgáltatás, tulajdonosa, dokumentációja és függőségei
103- **Szoftversablonok**: Scaffolding új szolgáltatásokhoz beépített legjobb gyakorlatokkal
104- **Technikai dokumentáció**: Dokumentáció mint kód, renderelt és kereshető
105- **Plugin ökoszisztéma**: Egyéni funkcionalitással bővíthető
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### Réteg 2: Infrastruktúra Absztrakció
129 
130A fejlesztőknek nem kellene közvetlenül Terraform-ot vagy Kubernetes YAML-t írniuk. A platformnak absztrakciókat kell biztosítania.
131 
132**Eszközök:**
133- **Crossplane**: Kubernetes-natív infrastruktúra kiépítés
134- **Terraform modulokkal**: Előre elkészített, tesztelt infrastruktúra modulok
135- **Pulumi**: Infrastruktúra mint valódi 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 
150Az RDS paraméterek, VPC alhálózatok, biztonsági csoportok és mentési politikák konfigurálása helyett a fejlesztő egyszerűen megadja: `size: small` és `backup: daily`. A platform intézi a többit.
151 
152### Réteg 3: CI/CD Szabványosítás
153 
154Szabványosítsa a CI/CD-t, hogy a csapatok ne építsék mindegyik a saját pipeline-jukat.
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**Kulcsfontosságú gyakorlatok:**
174- Megosztott CI/CD sablonok, amelyeket a csapatok beillesztenek (nem másolnak)
175- Automatikus biztonsági vizsgálat (SAST, függőség audit)
176- Szabványosított telepítési stratégiák (canary, blue/green)
177- Automatikus visszaállítás sikertelen health check-ek esetén
178 
179### Réteg 4: Megfigyelhetőség
180 
181Előre konfigurált monitorozás, hogy a fejlesztők azonnal megkapják a dashboard-okat és riasztásokat.
182 
183- **Metrikák**: Prometheus + Grafana szabványos dashboard-okkal szolgáltatásonként
184- **Naplózás**: Strukturált naplózás központosított gyűjtéssel (Loki, ELK)
185- **Nyomkövetés**: Elosztott nyomkövetés OpenTelemetry-vel
186- **Riasztás**: PagerDuty/Opsgenie integráció ésszerű alapértelmezésekkel
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## A Siker Mérése
201 
202Honnan tudja, hogy platformja működik? Kövesse ezeket a metrikákat:
203 
204### DORA Metrikák
205- **Telepítés gyakorisága**: Milyen gyakran jut el a kód a produkcióba
206- **Változtatások átfutási ideje**: Idő a commit-tól a produkcióig
207- **Változtatások hibaaránya**: A hibákat okozó telepítések százaléka
208- **Átlagos helyreállítási idő**: A szolgáltatás helyreállítási ideje incidens után
209 
210### Platform-specifikus Metrikák
211- **Első telepítésig eltelt idő**: Mennyi idő az „új szolgáltatás"-tól az első produkciós telepítésig
212- **Fejlesztői elégedettség (NPS)**: Rendszeresen kérdezze meg felhasználóit
213- **Önkiszolgálási arány**: Az infrastruktúra kérések %-a jegyek nélkül kezelve
214- **Arany út elfogadása**: Az ajánlott utat követő szolgáltatások %-a
215 
216## Gyakori Hibák
217 
218### 1. Túl Sokat Építeni, Túl Korán
219Kezdje a legnagyobb fájdalomponttal, ne egy nagy vízióval. Ha a telepítések fájdalmasak, onnan kezdje. Ha a kiépítés hetekig tart, onnan kezdje.
220 
221### 2. A Platformot Nem Termékként Kezelni
222A platformcsapatnak szüksége van termékmenedzserre, felhasználói kutatásra és visszacsatolási hurkokra. A fejlesztők az ügyfelek  -  értse meg szükségleteiket.
223 
224### 3. Előírni Vonzás Helyett
225A legjobb platformokat önkéntesen fogadják el, mert könnyebbé teszik a fejlesztők életét. Ha kötelezővé kell tennie a használatot, platformja nem elég jó.
226 
227### 4. A Fejlesztői Élmény Figyelmen Kívül Hagyása
228A szörnyű UX-el rendelkező platformot nem fogják használni. Fektessen be világos dokumentációba, hasznos hibaüzenetekbe és gyors visszacsatolási hurkokba.
229 
230## Első Lépések
231 
232Gyakorlati ütemterv első IDP-je felépítéséhez:
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álisan Életképes Platform
258 
2591. **Szolgáltatáskatalógus** (Backstage)  -  tudja, mi létezik és ki a tulajdonos
2602. **Egy szolgáltatássablon**  -  arany út a leggyakoribb szolgáltatástípushoz
2613. **Szabványosított CI/CD**  -  megosztott pipeline, amelyet a csapatok beillesztenek
2624. **Alap dokumentáció**  -  hogyan használja a platformot, hol kérjen segítséget
263 
264Ezt az MVP-t 2-3 hónap alatt felépítheti 2-3 mérnökből álló csapattal.
265 
266## Összefoglalás
267 
268A Platform Engineering nem arról szól, hogy az első naptól tökéletes platformot építünk. Arról szól, hogy fokozatosan csökkentjük a fejlesztők kognitív terhelését, hogy a termékek építésére koncentrálhassanak. Kezdjen kicsiben, mérje a hatást, és iteráljon a fejlesztői visszajelzések alapján.
269 
270A Platform Engineering-be befektető szervezetek jelentős versenyelőnnyel rendelkeznek majd: gyorsabb szállítás, boldogabb fejlesztők és megbízhatóbb rendszerek.
271 
272**Források:**
273- [Team Topologies](https://teamtopologies.com/)  -  a könyv, amely népszerűvé tette a platformcsapatokat
274- [Backstage](https://backstage.io/)  -  a Spotify nyílt forráskódú fejlesztői portálja
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  közösségi definíció és legjobb gyakorlatok
276- [platformengineering.org](https://platformengineering.org/)  -  közösség, események és források
277