Platform Engineering: Sådan Bygger du en Internal Developer Platform

spinny:~/writing $ vim platform-engineering-internal-developer-platform.md

1~
2Efterhånden som softwaresystemer bliver mere komplekse  -  microservices, Kubernetes, multi-cloud, CI/CD-pipelines, observability-stacks  -  bruger udviklere mere tid på infrastruktur og mindre tid på at bygge produkter. **Platform Engineering** løser dette ved at skabe en intern platform der abstraherer kompleksitet og giver udviklere selvbetjeningsværktøjer til hurtigere levering.
3~
4Gartner forudsiger at inden 2027 vil **80% af softwareingeniørorganisationer** oprette platformteams. I denne guide udforsker vi hvad Platform Engineering er, hvorfor det er vigtigt, og hvordan man bygger en Internal Developer Platform fra bunden.
5~
6## Hvad er Platform Engineering?
7~
8Platform Engineering er disciplinen at designe og bygge toolchains og workflows der muliggør selvbetjeningskapaciteter for softwareingeniørorganisationer. Resultatet er en **Internal Developer Platform (IDP)**  -  et lag der sidder mellem udviklere og infrastruktur.
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 er ikke en erstatning for DevOps  -  det er den næste evolution. DevOps sagde "du bygger det, du kører det." Platform Engineering siger "vi gør bygning og drift ubesværet."
47~
48| Aspekt | DevOps | Platform Engineering |
49|--------|--------|---------------------|
50| **Fokus** | Kultur og praksisser | Produkter og selvbetjening |
51| **Tilgang** | Hvert team styrer infra | Platformteamet abstraherer infra |
52| **Kognitiv belastning** | Høj (hvert team lærer alt) | Lav (golden paths leveret) |
53| **Resultat** | CI/CD-pipelines, IaC-scripts | Internal Developer Platform |
54| **Brugere** | Al engineering | Platformteamet betjener engineering |
55~
56## Hvorfor Platform Engineering er Vigtigt
57~
58### Problemet med Kognitiv Belastning
59~
60I en typisk moderne organisation skal en udvikler forstå:
61~
62- Git-workflows og forgreningsstrategier
63- CI/CD-pipeline-konfiguration
64- Container-bygning og registry-styring
65- Kubernetes-manifester og Helm Charts
66- Cloud-udbydertjenester (AWS/GCP/Azure)
67- Netværk, DNS, TLS-certifikater
68- Opsætning af overvågning, logning, alarmering
69- Database-provisioning og migrationer
70- Sikkerhedspolitikker og compliance
71~
72Det er en enorm kognitiv byrde der tager fokus fra det faktiske produkt.
73~
74### Golden Path
75~
76Platform Engineering introducerer konceptet **golden paths**  -  meningsstærke, velunderstøttede og dokumenterede stier for almindelige opgaver. En golden path er ikke et krav; udviklere *kan* afvige, men platformen gør det rigtige til det nemme.
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**Eksempel på golden path for oprettelse af en ny microservice:**
901. Udvikleren vælger "Ny Backend Service" i portalen
912. Vælger sprog/framework (Node.js, Go, Python)
923. Platformen opretter automatisk: Git-repository, CI/CD-pipeline, Kubernetes namespace, overvågningsdashboards og alarmregler
934. Udvikleren kloner repository'et og begynder at kode med det samme
94~
95## Bygning af en Internal Developer Platform
96~
97### Lag 1: Developer Portal
98~
99Portalen er det enkelte indgangspunkt for udviklere. Den mest populære open source-mulighed er **Backstage** (skabt af Spotify, nu et CNCF-projekt).
100~
101Nøglefunktioner:
102- **Servicekatalog**: Hver service, dens ejer, dokumentation og afhængigheder
103- **Softwareskabeloner**: Scaffolding til nye services med indbyggede best practices
104- **Teknisk dokumentation**: Dokumentation som kode, renderet og søgbar
105- **Plugin-økosystem**: Udvidelig med tilpasset funktionalitet
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### Lag 2: Infrastrukturabstraktion
129~
130Udviklere bør ikke skrive Terraform eller Kubernetes YAML direkte. Platformen bør levere abstraktioner.
131~
132**Værktøjer:**
133- **Crossplane**: Kubernetes-native infrastrukturprovisioning
134- **Terraform med moduler**: Forudbyggede, testede infrastrukturmoduler
135- **Pulumi**: Infrastruktur som rigtig kode (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~
150I stedet for at konfigurere RDS-parametre, VPC-subnets, sikkerhedsgrupper og backup-politikker angiver udvikleren blot `size: small` og `backup: daily`. Platformen håndterer resten.
151~
152### Lag 3: CI/CD-standardisering
153~
154Standardiser CI/CD så teams ikke bygger hver deres egne pipelines.
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**Nøglepraksisser:**
174- Delte CI/CD-skabeloner som teams inkluderer (ikke kopierer)
175- Automatisk sikkerhedsscanning (SAST, afhængighedsaudit)
176- Standardiserede deployment-strategier (canary, blue/green)
177- Automatisk rollback ved fejlede health checks
178~
179### Lag 4: Observability
180~
181Forudkonfigureret overvågning så udviklere får dashboards og alarmer klar til brug.
182~
183- **Metrikker**: Prometheus + Grafana med standarddashboards per service
184- **Logning**: Struktureret logning med centraliseret indsamling (Loki, ELK)
185- **Tracing**: Distribueret tracing med OpenTelemetry
186- **Alarmering**: PagerDuty/Opsgenie-integration med fornuftige standardværdier
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åling af Succes
201~
202Hvordan ved du at din platform virker? Spor disse metrikker:
203~
204### DORA-metrikker
205- **Deployment-frekvens**: Hvor ofte kode når produktion
206- **Gennemløbstid for ændringer**: Tid fra commit til produktion
207- **Fejlrate for ændringer**: Procent af deployments der forårsager fejl
208- **Gennemsnitlig gendannelsestid**: Tid til at gendanne service efter en hændelse
209~
210### Platformspecifikke Metrikker
211- **Tid til første deploy**: Hvor lang tid fra "ny service" til første produktionsdeploy
212- **Udviklertilfredshed (NPS)**: Undersøg dine brugere regelmæssigt
213- **Selvbetjeningsandel**: % af infrastrukturanmodninger håndteret uden tickets
214- **Golden path-adoption**: % af services der følger den anbefalede sti
215~
216## Almindelige Fejl
217~
218### 1. Bygge for Meget, for Tidligt
219Start med det største smertepunkt, ikke en storslået vision. Hvis deployments er smertefulde, start der. Hvis provisioning tager uger, start der.
220~
221### 2. Ikke Behandle Platformen som et Produkt
222Platformteamet har brug for en produktchef, brugerforskning og feedback-loops. Udviklere er dine kunder  -  forstå deres behov.
223~
224### 3. Påtvinge i Stedet for at Tiltrække
225De bedste platforme adopteres frivilligt fordi de gør udvikleres liv lettere. Hvis du skal påtvinge brug, er din platform ikke god nok.
226~
227### 4. Ignorere Udvikleroplevelsen
228En platform med forfærdelig UX vil ikke blive brugt. Invester i klar dokumentation, hjælpsomme fejlmeddelelser og hurtige feedback-loops.
229~
230## Kom i Gang
231~
232En praktisk køreplan for at bygge din første 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. **Servicekatalog** (Backstage)  -  vid hvad der eksisterer og hvem der ejer det
2602. **En serviceskabelon**  -  golden path for din mest almindelige servicetype
2613. **Standardiseret CI/CD**  -  delt pipeline som teams inkluderer
2624. **Grundlæggende dokumentation**  -  hvordan man bruger platformen, hvor man får hjælp
263~
264Du kan bygge dette MVP på 2-3 måneder med et team på 2-3 ingeniører.
265~
266## Konklusion
267~
268Platform Engineering handler ikke om at bygge den perfekte platform fra dag et. Det handler om gradvist at reducere den kognitive belastning på udviklere så de kan fokusere på at bygge produkter. Start småt, mål effekten og iterer baseret på udviklerfeedback.
269~
270Organisationer der investerer i Platform Engineering vil have en betydelig konkurrencefordel: hurtigere levering, gladere udviklere og mere pålidelige systemer.
271~
272**Ressourcer:**
273- [Team Topologies](https://teamtopologies.com/)  -  bogen der populariserede platformteams
274- [Backstage](https://backstage.io/)  -  Spotifys open source-udviklerportal
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  fællesskabsdefinition og best practices
276- [platformengineering.org](https://platformengineering.org/)  -  fællesskab, begivenheder og ressourcer
277~

NORMAL · platform-engineering-internal-developer-platform.md [readonly]277 lines · :q to close

2Efterhånden som softwaresystemer bliver mere komplekse - microservices, Kubernetes, multi-cloud, CI/CD-pipelines, observability-stacks - bruger udviklere mere tid på infrastruktur og mindre tid på at bygge produkter. **Platform Engineering** løser dette ved at skabe en intern platform der abstraherer kompleksitet og giver udviklere selvbetjeningsværktøjer til hurtigere levering.

4Gartner forudsiger at inden 2027 vil **80% af softwareingeniørorganisationer** oprette platformteams. I denne guide udforsker vi hvad Platform Engineering er, hvorfor det er vigtigt, og hvordan man bygger en Internal Developer Platform fra bunden.

6## Hvad er Platform Engineering?

8Platform Engineering er disciplinen at designe og bygge toolchains og workflows der muliggør selvbetjeningskapaciteter for softwareingeniørorganisationer. Resultatet er en **Internal Developer Platform (IDP)** - et lag der sidder mellem udviklere og infrastruktur.

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 er ikke en erstatning for DevOps - det er den næste evolution. DevOps sagde "du bygger det, du kører det." Platform Engineering siger "vi gør bygning og drift ubesværet."

47~

48| Aspekt | DevOps | Platform Engineering |

49|--------|--------|---------------------|

50| **Fokus** | Kultur og praksisser | Produkter og selvbetjening |

51| **Tilgang** | Hvert team styrer infra | Platformteamet abstraherer infra |

52| **Kognitiv belastning** | Høj (hvert team lærer alt) | Lav (golden paths leveret) |

53| **Resultat** | CI/CD-pipelines, IaC-scripts | Internal Developer Platform |

54| **Brugere** | Al engineering | Platformteamet betjener engineering |

55~

56## Hvorfor Platform Engineering er Vigtigt

57~

58### Problemet med Kognitiv Belastning

59~

60I en typisk moderne organisation skal en udvikler forstå:

61~

62- Git-workflows og forgreningsstrategier

63- CI/CD-pipeline-konfiguration

64- Container-bygning og registry-styring

65- Kubernetes-manifester og Helm Charts

66- Cloud-udbydertjenester (AWS/GCP/Azure)

67- Netværk, DNS, TLS-certifikater

68- Opsætning af overvågning, logning, alarmering

69- Database-provisioning og migrationer

70- Sikkerhedspolitikker og compliance

71~

72Det er en enorm kognitiv byrde der tager fokus fra det faktiske produkt.

73~

74### Golden Path

75~

76Platform Engineering introducerer konceptet **golden paths** - meningsstærke, velunderstøttede og dokumenterede stier for almindelige opgaver. En golden path er ikke et krav; udviklere *kan* afvige, men platformen gør det rigtige til det nemme.

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**Eksempel på golden path for oprettelse af en ny microservice:**

901. Udvikleren vælger "Ny Backend Service" i portalen

912. Vælger sprog/framework (Node.js, Go, Python)

923. Platformen opretter automatisk: Git-repository, CI/CD-pipeline, Kubernetes namespace, overvågningsdashboards og alarmregler

934. Udvikleren kloner repository'et og begynder at kode med det samme

94~

95## Bygning af en Internal Developer Platform

96~

97### Lag 1: Developer Portal

98~

99Portalen er det enkelte indgangspunkt for udviklere. Den mest populære open source-mulighed er **Backstage** (skabt af Spotify, nu et CNCF-projekt).

100~

101Nøglefunktioner:

102- **Servicekatalog**: Hver service, dens ejer, dokumentation og afhængigheder

103- **Softwareskabeloner**: Scaffolding til nye services med indbyggede best practices

104- **Teknisk dokumentation**: Dokumentation som kode, renderet og søgbar

105- **Plugin-økosystem**: Udvidelig med tilpasset funktionalitet

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### Lag 2: Infrastrukturabstraktion

129~

130Udviklere bør ikke skrive Terraform eller Kubernetes YAML direkte. Platformen bør levere abstraktioner.

131~

132**Værktøjer:**

133- **Crossplane**: Kubernetes-native infrastrukturprovisioning

134- **Terraform med moduler**: Forudbyggede, testede infrastrukturmoduler

135- **Pulumi**: Infrastruktur som rigtig kode (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~

150I stedet for at konfigurere RDS-parametre, VPC-subnets, sikkerhedsgrupper og backup-politikker angiver udvikleren blot `size: small` og `backup: daily`. Platformen håndterer resten.

151~

152### Lag 3: CI/CD-standardisering

153~

154Standardiser CI/CD så teams ikke bygger hver deres egne pipelines.

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**Nøglepraksisser:**

174- Delte CI/CD-skabeloner som teams inkluderer (ikke kopierer)

175- Automatisk sikkerhedsscanning (SAST, afhængighedsaudit)

176- Standardiserede deployment-strategier (canary, blue/green)

177- Automatisk rollback ved fejlede health checks

178~

179### Lag 4: Observability

180~

181Forudkonfigureret overvågning så udviklere får dashboards og alarmer klar til brug.

182~

183- **Metrikker**: Prometheus + Grafana med standarddashboards per service

184- **Logning**: Struktureret logning med centraliseret indsamling (Loki, ELK)

185- **Tracing**: Distribueret tracing med OpenTelemetry

186- **Alarmering**: PagerDuty/Opsgenie-integration med fornuftige standardværdier

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åling af Succes

201~

202Hvordan ved du at din platform virker? Spor disse metrikker:

203~

204### DORA-metrikker

205- **Deployment-frekvens**: Hvor ofte kode når produktion

206- **Gennemløbstid for ændringer**: Tid fra commit til produktion

207- **Fejlrate for ændringer**: Procent af deployments der forårsager fejl

208- **Gennemsnitlig gendannelsestid**: Tid til at gendanne service efter en hændelse

209~

210### Platformspecifikke Metrikker

211- **Tid til første deploy**: Hvor lang tid fra "ny service" til første produktionsdeploy

212- **Udviklertilfredshed (NPS)**: Undersøg dine brugere regelmæssigt

213- **Selvbetjeningsandel**: % af infrastrukturanmodninger håndteret uden tickets

214- **Golden path-adoption**: % af services der følger den anbefalede sti

215~

216## Almindelige Fejl

217~

218### 1. Bygge for Meget, for Tidligt

219Start med det største smertepunkt, ikke en storslået vision. Hvis deployments er smertefulde, start der. Hvis provisioning tager uger, start der.

220~

221### 2. Ikke Behandle Platformen som et Produkt

222Platformteamet har brug for en produktchef, brugerforskning og feedback-loops. Udviklere er dine kunder - forstå deres behov.

223~

224### 3. Påtvinge i Stedet for at Tiltrække

225De bedste platforme adopteres frivilligt fordi de gør udvikleres liv lettere. Hvis du skal påtvinge brug, er din platform ikke god nok.

226~

227### 4. Ignorere Udvikleroplevelsen

228En platform med forfærdelig UX vil ikke blive brugt. Invester i klar dokumentation, hjælpsomme fejlmeddelelser og hurtige feedback-loops.

229~

230## Kom i Gang

231~

232En praktisk køreplan for at bygge din første 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. **Servicekatalog** (Backstage) - vid hvad der eksisterer og hvem der ejer det

2602. **En serviceskabelon** - golden path for din mest almindelige servicetype

2613. **Standardiseret CI/CD** - delt pipeline som teams inkluderer

2624. **Grundlæggende dokumentation** - hvordan man bruger platformen, hvor man får hjælp

263~

264Du kan bygge dette MVP på 2-3 måneder med et team på 2-3 ingeniører.

265~

266## Konklusion

267~

268Platform Engineering handler ikke om at bygge den perfekte platform fra dag et. Det handler om gradvist at reducere den kognitive belastning på udviklere så de kan fokusere på at bygge produkter. Start småt, mål effekten og iterer baseret på udviklerfeedback.

269~

270Organisationer der investerer i Platform Engineering vil have en betydelig konkurrencefordel: hurtigere levering, gladere udviklere og mere pålidelige systemer.

271~

272**Ressourcer:**

273- [Team Topologies](https://teamtopologies.com/) - bogen der populariserede platformteams

274- [Backstage](https://backstage.io/) - Spotifys open source-udviklerportal

275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) - fællesskabsdefinition og best practices

276- [platformengineering.org](https://platformengineering.org/) - fællesskab, begivenheder og ressourcer

277~