Guide
Platform engineering: vad det är, när det lönar sig och hur ni börjar
Platform engineering är arbetet med att bygga och driva en intern plattform som låter utvecklare få ut kod i produktion utan att lösa infrastruktur, pipelines och behörigheter på nytt varje gång. Guiden är skriven av Vynatix, ett mjukvarukonsultbolag i Göteborg som bygger och driver molnplattformar för reglerade branscher, och den säger också när en snabbare byggpipeline räcker.
Platform engineering lönar sig när väntan på byggen, miljöer och driftsättningar kostar mer än de personer som skulle sköta en gemensam plattform. Innan ni är där räcker ofta en snabbare byggpipeline och några gemensamma mallar, och det är där de flesta bör börja.
Vad är platform engineering?
Platform engineering, ibland kallat plattformsteknik på svenska, är att behandla utvecklarnas verktyg och infrastruktur som en intern produkt, med ett team som ansvarar för den och utvecklarna som användare. Målet är att det vanligaste arbetet ska gå att göra på egen hand, utan att skicka ett ärende till ett annat team. En plattform innehåller oftast:
- byggpipelines som bygger och testar varje ändring
- miljöer för test och produktion som skapas på samma sätt varje gång
- mallar för nya tjänster, där det mesta redan är på plats
- behörigheter och hemligheter som hanteras på ett ställe
- loggar, mätvärden och larm (observability) som följer med från början
Vad är en intern utvecklarplattform och en gyllene väg?
En intern utvecklarplattform (internal developer platform, IDP) är summan av de verktyg, tjänster och mallar som plattformsteamet erbjuder, och en gyllene väg (golden path) är en färdig och underhållen väg från ny kod till produktion för en vanlig typ av tjänst. Den gyllene vägen är det enklaste alternativet, inte ett tvång.
Vissa plattformar har en utvecklarportal ovanpå, byggd med verktyg som Backstage, och driftsättningen sker ofta med GitOps-verktyg som Argo CD eller Flux. Det är exempel på vanliga verktyg i kategorin, inte en lista över vad ni behöver.
Vad är skillnaden mellan platform engineering och DevOps?
DevOps är ett arbetssätt där utveckling och drift hänger ihop, ofta så att samma team bygger och driver sin programvara, medan platform engineering är ett sätt att få det arbetssättet att hålla när organisationen växer. När varje team själv ska sköta pipelines, Kubernetes, behörigheter och övervakning blir bördan stor och lösningarna spretiga. Ett plattformsteam tar hand om det gemensamma, så att produktteamen kan fortsätta äga sina tjänster. Plattformen ersätter alltså inte DevOps utan gör det lättare att arbeta så.
När lönar sig platform engineering, och när räcker en bättre pipeline?
Platform engineering lönar sig när flera team gör samma infrastrukturarbete om och om igen, och när väntan och manuella steg kostar mer än ett team som sköter en gemensam plattform. Typiska tecken är att en ny tjänst tar veckor att sätta upp, att varje team har sin egen variant av samma pipeline och att utvecklare väntar på andra team för att få en miljö eller en behörighet.
Har ni ett fåtal team räcker det ofta med en snabbare byggpipeline och några gemensamma mallar. Det finns ingen gräns i antal utvecklare som passar alla organisationer. Räkna hellre på väntetiden: de minuter som varje utvecklare förlorar per dag på byggen, köer och manuella steg, gånger antalet utvecklare.
Vad ska ni mäta?
Mät hur snabbt och hur säkert ändringar når produktion, och börja mäta innan ni ändrar något så att ni har något att jämföra med. De fyra nyckeltal som de flesta utgår från kommer från forskningsprogrammet DORA (DevOps Research and Assessment) (öppnas i en ny flik):
- Ledtid för ändringar: tiden från commit till att ändringen körs i produktion.
- Driftsättningsfrekvens: hur ofta ni driftsätter till produktion.
- Andel misslyckade ändringar: hur stor del av driftsättningarna som leder till ett fel som måste åtgärdas.
- Tid till återställning: hur lång tid det tar att få tjänsten att fungera igen efter ett fel.
Lägg till byggtiden per commit, som är det utvecklarna märker först. Följ siffrorna över tid i stället för att jämföra team med varandra: det är trenden som visar om plattformen gör nytta.
Hur blir ni snabbare i en reglerad bransch utan att tappa spårbarheten?
Ni blir snabbare utan att tappa spårbarheten genom att korta väntetiden i pipelinen och automatisera de manuella steg som inte behöver göras för hand, medan granskningen, loggarna och kopplingen mellan ändring och leverans ligger kvar. Ofta sitter väntetiden i en reglerad verksamhet inte i reglerna utan i långa byggen, testköer och manuella steg som ingen har ifrågasatt på länge.
GitOps passar bra här. När driftmiljöns önskade tillstånd beskrivs i ett versionshanterat repo blir varje ändring en commit: den har en författare, kan granskas innan den går ut och finns kvar i historiken. Det som behöver finnas kvar efter en snabbare pipeline är detsamma som före:
- kodgranskning innan en ändring går vidare
- en tydlig koppling mellan ändring, testresultat och det som driftsattes
- loggar som visar vem som ändrade vad och när
- kontroll över vem som får driftsätta till produktion
Kraven kan också betyda att system och data måste stanna on-prem eller i en hybrid med molnet. Det påverkar verktygsvalet, men principerna är desamma.
Volvo Cars ·
Vad kan en snabbare byggpipeline betyda i praktiken?
Hos Volvo Cars betydde det att en byggpipeline gick från 47 minuter till 6, alltså 87 procent kortare, vid varje commit och för hela teamet. Vynatix gjorde arbetet 2025, med samma tester och samma täckning som tidigare.
Gränsen. Uppdraget gällde pipelinen, inte byggmålen, och den gränsen kom vi överens om innan vi började.
Exemplet visar varför byggpipelinen ofta är rätt första steg: den berör varje utvecklare vid varje ändring, och den går att förbättra utan att ändra vad som byggs eller testas.
Läs om uppdraget (på engelska)Byggtid
−87 %
Vid varje commit, för hela teamet.
Minuter per bygge
6
Tidigare 47.
Hur börjar ni utan att bygga en plattform som ingen använder?
Börja med det som bromsar flest utvecklare i dag, oftast den långsammaste byggpipelinen, och bygg sedan en gyllene väg för er vanligaste typ av tjänst tillsammans med ett team som ska använda den. En portal kommer i så fall sist, om teamen fortfarande saknar en.
- Mät nuläget: byggtid, ledtid och de manuella stegen mellan commit och produktion.
- Skriv ner gränsen för arbetet: vad som ingår och vad som inte gör det.
- Gör den långsammaste pipelinen snabb och stabil, med samma tester och samma täckning.
- Bygg en gyllene väg för den vanligaste typen av tjänst: mall, pipeline och driftsättning.
- Låt ett team använda den på riktigt och ändra efter det ni lär er, innan fler går över.
- Behandla plattformen som en produkt, med en ägare och en plan som utgår från vad teamen behöver.
Hur arbetar Vynatix med platform engineering?
Vynatix arbetar med platform engineering inne i ert befintliga team, tillsammans med era utvecklare och inte vid sidan av dem. Arbetet är en del av det vi gör inom molnplattformar för reglerade branscher: GCP, AWS och hybrider med on-prem, Kubernetes och GitOps, FinOps och kostnadskontroll samt migrering från äldre system.
Vi är seniora utvecklare och bemannar inte ett stort plattformsteam. Gränsen för uppdraget kommer vi överens om innan vi börjar, vi redovisar timmarna varje vecka och vi tackar nej till arbete vi inte kan göra bra. Målet är tråkig infrastruktur: pipelines som förblir gröna och driftsättningar som går att förstå. Mer om molnplattformar (på engelska).
Vanliga frågor
Behöver ett litet utvecklingsteam platform engineering?
Ett litet utvecklingsteam behöver oftast inte platform engineering som en egen funktion. Det får mer ut av en snabb och stabil byggpipeline och några gemensamma mallar, som också är den bästa grunden om en plattform behövs senare.
Måste en intern utvecklarplattform bygga på Kubernetes?
Nej, en intern utvecklarplattform behöver inte bygga på Kubernetes. Kubernetes är vanligt i plattformar med många tjänster, men en plattform kan lika gärna bygga på en molnleverantörs hanterade tjänster eller på virtuella maskiner. Välj det som era team kan driva.
Behöver vi en utvecklarportal som Backstage?
Ni behöver sällan en utvecklarportal från början. En portal samlar dokumentation, mallar och en katalog över tjänster, men den gör nytta först när det finns en fungerande pipeline och en gyllene väg att visa upp.
Vilka nyckeltal ska vi använda för att mäta en plattform?
Börja med de fyra nyckeltalen från DORA: ledtid för ändringar, driftsättningsfrekvens, andel misslyckade ändringar och tid till återställning. Lägg till byggtiden per commit och följ trenden över tid.
Betyder en snabbare pipeline att man testar mindre?
En snabbare pipeline behöver inte betyda att man testar mindre. Hos Volvo Cars tog Vynatix en byggpipeline från 47 minuter till 6 med samma tester och samma täckning.
Om Vynatix
Vynatix AB är ett mjukvarukonsultbolag i Göteborg, grundat 2023 och en del av Ultra Group. Våra seniora utvecklare arbetar som en del av kundernas organisationer inom Android Automotive, AI och molnplattformar, med Volvo Trucks och Volvo Cars bland kunderna. Vi svarar på förfrågningar inom en arbetsdag.
I guiden om hur ni väljer konsultbolag för mjukvaruutveckling går vi igenom vad ni bör fråga innan ni anlitar någon, oss inräknade. Fler guider på svenska finns på vår svenska startsida.
Nästa steg
En pipeline som bromsar teamet? Börja med att mäta den.
Berätta var väntetiden sitter och vilka krav ni måste uppfylla. Vi svarar inom en arbetsdag.
Kontakta oss