1 
2Naarmate softwaresystemen complexer worden  -  microservices, Kubernetes, multi-cloud, CI/CD-pipelines, observability-stacks  -  besteden ontwikkelaars meer tijd aan infrastructuur en minder tijd aan het bouwen van producten. **Platform Engineering** lost dit op door een intern platform te creëren dat complexiteit abstraheert en ontwikkelaars selfservice-tools biedt om sneller te leveren.
3 
4Gartner voorspelt dat tegen 2027 **80% van de software-engineeringorganisaties** platformteams zullen oprichten. In deze gids verkennen we wat Platform Engineering is, waarom het ertoe doet en hoe je een Internal Developer Platform vanaf nul bouwt.
5 
6## Wat is Platform Engineering?
7 
8Platform Engineering is de discipline van het ontwerpen en bouwen van toolchains en workflows die selfservice-mogelijkheden voor software-engineeringorganisaties mogelijk maken. Het resultaat is een **Internal Developer Platform (IDP)**  -  een laag die tussen ontwikkelaars en infrastructuur zit.
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 is geen vervanging voor DevOps  -  het is de volgende evolutie. DevOps zei "jij bouwt het, jij draait het." Platform Engineering zegt "wij maken bouwen en draaien moeiteloos."
47 
48| Aspect | DevOps | Platform Engineering |
49|--------|--------|---------------------|
50| **Focus** | Cultuur en praktijken | Producten en selfservice |
51| **Aanpak** | Elk team beheert infra | Platformteam abstraheert infra |
52| **Cognitieve belasting** | Hoog (elk team leert alles) | Laag (golden paths aangeboden) |
53| **Resultaat** | CI/CD-pipelines, IaC-scripts | Internal Developer Platform |
54| **Gebruikers** | Alle engineering | Platformteam bedient engineering |
55 
56## Waarom Platform Engineering Ertoe Doet
57 
58### Het Cognitieve Belastingsprobleem
59 
60In een typische moderne organisatie moet een ontwikkelaar begrijpen:
61 
62- Git-workflows en branchstrategieën
63- CI/CD-pipeline configuratie
64- Container building en registry management
65- Kubernetes manifesten en Helm Charts
66- Cloud provider diensten (AWS/GCP/Azure)
67- Netwerken, DNS, TLS-certificaten
68- Monitoring, logging, alerting setup
69- Database provisioning en migraties
70- Beveiligingsbeleid en compliance
71 
72Dat is een enorme cognitieve last die de aandacht afleidt van het eigenlijke product.
73 
74### Het Golden Path
75 
76Platform Engineering introduceert het concept van **golden paths**  -  eigenzinnige, goed ondersteunde en gedocumenteerde paden voor veelvoorkomende taken. Een golden path is geen verplichting; ontwikkelaars *kunnen* afwijken, maar het platform maakt het juiste het makkelijke.
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**Voorbeeld golden path voor het aanmaken van een nieuwe microservice:**
901. Ontwikkelaar selecteert "Nieuwe Backend Service" in het portaal
912. Kiest taal/framework (Node.js, Go, Python)
923. Platform maakt automatisch aan: Git-repository, CI/CD-pipeline, Kubernetes namespace, monitoring dashboards en alertregels
934. Ontwikkelaar kloont de repository en begint meteen met coderen
94 
95## Een Internal Developer Platform Bouwen
96 
97### Laag 1: Developer Portal
98 
99Het portaal is het enkele toegangspunt voor ontwikkelaars. De meest populaire open source optie is **Backstage** (gemaakt door Spotify, nu een CNCF-project).
100 
101Belangrijkste functies:
102- **Servicecatalogus**: Elke service, eigenaar, documentatie en afhankelijkheden
103- **Softwaretemplates**: Scaffolding voor nieuwe services met ingebouwde best practices
104- **Technische documentatie**: Documentatie als code, gerenderd en doorzoekbaar
105- **Plugin-ecosysteem**: Uitbreidbaar met aangepaste functionaliteit
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### Laag 2: Infrastructuurabstractie
129 
130Ontwikkelaars zouden niet direct Terraform of Kubernetes YAML moeten schrijven. Het platform moet abstracties bieden.
131 
132**Tools:**
133- **Crossplane**: Kubernetes-native infrastructuur provisioning
134- **Terraform met modules**: Voorgebouwde, geteste infrastructuurmodules
135- **Pulumi**: Infrastructuur als echte 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 
150In plaats van RDS-parameters, VPC-subnetten, beveiligingsgroepen en back-upbeleid te configureren, specificeert de ontwikkelaar gewoon `size: small` en `backup: daily`. Het platform regelt de rest.
151 
152### Laag 3: CI/CD-standaardisatie
153 
154Standaardiseer CI/CD zodat teams niet elk hun eigen pipelines bouwen.
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**Kernpraktijken:**
174- Gedeelde CI/CD-templates die teams includeren (niet kopiëren)
175- Automatische beveiligingsscanning (SAST, dependency audit)
176- Gestandaardiseerde deploymentstrategieën (canary, blue/green)
177- Automatische rollback bij mislukte health checks
178 
179### Laag 4: Observability
180 
181Vooraf geconfigureerde monitoring zodat ontwikkelaars dashboards en alerts out of the box krijgen.
182 
183- **Metrics**: Prometheus + Grafana met standaard dashboards per service
184- **Logging**: Gestructureerde logging met gecentraliseerde collectie (Loki, ELK)
185- **Tracing**: Distributed tracing met OpenTelemetry
186- **Alerting**: PagerDuty/Opsgenie integratie met verstandige defaults
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## Succes Meten
201 
202Hoe weet je of je platform werkt? Volg deze metrics:
203 
204### DORA Metrics
205- **Deploymentfrequentie**: Hoe vaak code productie bereikt
206- **Doorlooptijd voor wijzigingen**: Tijd van commit tot productie
207- **Faalpercentage van wijzigingen**: Percentage deployments dat storingen veroorzaakt
208- **Gemiddelde hersteltijd**: Tijd om service te herstellen na een incident
209 
210### Platformspecifieke Metrics
211- **Tijd tot eerste deploy**: Hoe lang van "nieuwe service" tot eerste productie-deploy
212- **Ontwikkelaarstevredenheid (NPS)**: Enquêteer je gebruikers regelmatig
213- **Selfservice-ratio**: % van infrastructuurverzoeken afgehandeld zonder tickets
214- **Golden path adoptie**: % van services die het aanbevolen pad volgen
215 
216## Veelvoorkomende Fouten
217 
218### 1. Te Veel Bouwen, Te Snel
219Begin met het grootste pijnpunt, niet met een grote visie. Als deployments pijnlijk zijn, begin daar. Als provisioning weken duurt, begin daar.
220 
221### 2. Het Platform Niet als Product Behandelen
222Het platformteam heeft een productmanager, gebruikersonderzoek en feedbackloops nodig. Ontwikkelaars zijn je klanten  -  begrijp hun behoeften.
223 
224### 3. Verplichten in Plaats van Aantrekken
225De beste platforms worden vrijwillig geadopteerd omdat ze het leven van ontwikkelaars makkelijker maken. Als je gebruik moet verplichten, is je platform niet goed genoeg.
226 
227### 4. Developer Experience Negeren
228Een platform met verschrikkelijke UX wordt niet gebruikt. Investeer in duidelijke documentatie, nuttige foutmeldingen en snelle feedbackloops.
229 
230## Aan de Slag
231 
232Een praktische routekaart voor het bouwen van je eerste 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. **Servicecatalogus** (Backstage)  -  weet wat er bestaat en wie eigenaar is
2602. **Eén servicetemplate**  -  golden path voor je meest voorkomende servicetype
2613. **Gestandaardiseerde CI/CD**  -  gedeelde pipeline die teams includeren
2624. **Basisdocumentatie**  -  hoe het platform te gebruiken, waar hulp te krijgen
263 
264Je kunt dit MVP in 2-3 maanden bouwen met een team van 2-3 engineers.
265 
266## Conclusie
267 
268Platform Engineering gaat niet over het bouwen van het perfecte platform vanaf dag één. Het gaat over het stapsgewijs verminderen van de cognitieve belasting van ontwikkelaars zodat ze zich kunnen richten op het bouwen van producten. Begin klein, meet de impact en itereer op basis van feedback van ontwikkelaars.
269 
270Organisaties die investeren in Platform Engineering zullen een significant concurrentievoordeel hebben: snellere levering, gelukkigere ontwikkelaars en betrouwbaardere systemen.
271 
272**Bronnen:**
273- [Team Topologies](https://teamtopologies.com/)  -  het boek dat platformteams populair maakte
274- [Backstage](https://backstage.io/)  -  Spotify's open source developer portal
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  community definitie en best practices
276- [platformengineering.org](https://platformengineering.org/)  -  community, evenementen en bronnen
277