Vad är platform engineering – en utvecklares ärlig guide

Vad är platform engineering - en utvecklares ärlig guide

Det är 22:10 och en nyanställd utvecklare har försökt få en staging-miljö i två dagar. Hon har öppnat tre ärenden, klistrat in samma Terraform-fel i Slack två gånger, och vet fortfarande inte vilket av de fyra CI-mallarna som är den rätta. Den scenen är hela svaret på "vad är platform engineering": det är arbetet med att bygga den interna vägen så att ingen måste hacka sig genom skogen ensam, och att behandla den vägen som en produkt med användare.

I praktiken bygger ett platform-team en intern utvecklarplattform (IDP): självbetjäningsverktyg som gör att andra utvecklare kan skapa tjänster, deploya och se vad som körs utan att vänta på en människa. Här är vad som går fel när du hoppas över det: varje team uppfinner sitt eget deployment, och kunskapen bor i tre personers huvuden.

Vad platform engineering egentligen är, utan buzzwords

Den renaste definitionen jag känner till kommer från platformengineering.org-communityn: att designa och bygga plattformar som ger team självbetjäningsförmåga för den återkommande delen av sitt arbete. Minska på vokabulären och du får tre delar som rör sig.

För det första en intern utvecklarplattform. Det är inte en produkt du köper. Det är ett tunt lager av mallar, pipelines, API:er och dokumentation som sitter ovanpå verktygen du redan kör (molnkonto, Kubernetes, CI, hemligheter, övervakning) och döljer de vassa kanterna.

För det andra ett platform-team. En liten grupp ingenjörer vars kunder är andra ingenjörer. Deras output är inte features för slutanvändare. Deras output är hur snabbt alla andra kan leverera.

För det tredje ett produkttänkande. Plattformen har användare, en backlog, adoptionssiffror och ett on-call-schema. Om ingen använder den misslyckades den, oavsett hur elegant arkitekturen är.

Gartner förutsade att 2026 skulle 80% av stora mjukvaruutvecklingsorganisationer ha platform-team, upp från 45% 2022. Behandla det som en trendmarkör, inte ett löfte. Samma industrichat säger att en stor andel av dessa team kämpar för att visa påverkan, vilket är exakt varför resten av den här artikeln ägnar tid åt vad som går fel.

Hur skiljer det sig från DevOps och SRE?

Kort version: DevOps är en kultur, SRE är en tillförlitlighetsdisciplin, platform engineering är en teamform som produktifierar båda.

DevOps sa att utvecklare och drift borde dela ägandet av att köra mjukvara. Bra idé. I ett 15-personersföretag fungerar det för att alla kan se allt. I ett 300-personersföretag blir det tyst "varje squad måste också bli Kubernetes-expert", vilket inte är vad någon skrev upp sig för.

SRE fokuserar på tillförliglighetsmål: felbudget, incidenthantering, kapacitet. Ett platform-team bryr sig om tillförlitlighet också, men dess huvudmått är annorlunda. Det mäter hur länge en dev väntar mellan "jag har en idé för en tjänst" och "den körs i produktion med loggar och alerter".

Platform engineering är svaret på den kognitiva belastning som DevOps lämnade efter sig. Istället för att fråga varje dev att lära sig hela verktygskedjan, ger du dem en stödd standard och håller expertkunskapen inuti plattformen. Tre skäl att göra det, ett skäl att inte: det lönar sig bara när antalet team eller tjänster är tillräckligt stort att duplicering skadar. Vi kommer till det tröskelvärdet nedan.

Vad levererar ett platform-team egentligen?

Glöm arkitekturdiagrammen. Här är vad ett fungerande platform-teams backlog ser ut på en vanlig tisdag.

En servicemal. Ett kommando, eller en knapp i en portal, skapar ett repo med en fungerande pipeline, en Dockerfile, hälsokontroller, en loggning-setup och en grundläggande instrumentpanel. Utvecklaren ändrar affärslogiken, inte rörlägningen.

En deployväg. Push till main, tester körs, artefakten byggs och marknadsförs genom miljöer med samma steg varje gång. Inga per-team-snöflingor.

Miljö på begäran. En förhandsgransknings-miljö per pull-request, automatiskt rivs. Det här är funktionen utvecklare egentligen tackar dig för.

Hemligheter och åtkomst. Kortlivade credentials, en plats att begära dem, en granskningslogg. Trist, och det som räddar dig vid en säkerhetsgranskning.

Observerbarhet som standard. Varje tjänst skapad från mallen levererar mätvärden, loggar och spårning utan att någon kopplar in dem. En stack som Grafana brukar sitta bakom det här lagret, och dess gratisnivå och open-source-alternativ passar ett litet team.

Märk vad som saknas från listan: en skräddarsydd portal med en tre-månaders roadmap. Portalen är det sista du lägger till, inte det första.

Gyllne vägar: idén som gör resten möjlig

En gyllne väg är det stödda, åsiktsbaserade sättet att göra en vanlig uppgift. Det är snabbare än att göra det manuellt och säkrare än att improvisera, och avgörande är det valfritt. Utvecklare kan lämna vägen när de har en riktig anledning. De tar bara på sig ansvaret som kommer med det.

Det finns en användbar skillnad i Octopus-skrivningen om vägar kontra gyllne vägar: en väg är den breda, väl-underhållen ytan, medan en gyllne väg är den specifika rekommenderade rutten för ett givet jobb. Enligt min erfarenhet spelar skillnaden mindre roll än principen därinne. Du vinner genom att göra det rätta sättet till det enkla sättet, inte genom att förbjuda de andra sätten.

Här är vad den minsta möjliga gyllne vägen ser ut. Det är ett enda scaffold-kommando som en dev kör en gång:

platform new service payments-api \
  --template node-api \
  --env preview,staging,prod \
  --owner team-checkout

Bakom den ena linjen sitter ett repo, en pipeline, DNS, en databasstöd, alerter och en äganderecord. Kommandot är trivialt. Den hårda delen är de sex månaderna att komma överens om vad "node-api" betyder, och att hålla det aktuellt när Node, din basavbildning eller din molnleverantör ändras.

Testad, inte optimal, och här är varför vi gör det ändå: en medelmåttig gyllne väg som 80% av teamen använder slår en perfekt som 10% antar, för den första ger dig spaken att förbättra allt på en gång.

När lönar det sig, och när är det en distraktion?

Det här är den sektion de flesta inläggen hoppas över. Platform engineering är inte gratis, och för många team är det fel drag.

Översikten på platformengineering.org föreslår att organisationer typiskt börjar gynnas när de passerar ungefär 20 till 30 platform-användare. Jag skulle läsa det som ett grovt golv, inte en regel. Under det räcker en delad README, en bra CI-mall och en person som bryr sig att göra mer än ett formellt platform-team.

Värt det när:

Du har mer än en handfull team, och varje har byggt sin egen deploy-pipeline.

Nya utvecklare tar veckor, inte dagar, att leverera sin första ändring.

Samma incidenttyp upprepas för att varje tjänst kopplade sin egen alerting.

Säkerhet eller compliance frågar om konsekvens du inte kan leverera genom att fråga snällt.

Hoppa över det när:

Du är ett team på fem. Skriv ett script, inte en plattform.

Du vet ännu inte vad dina tjänster ser ut. Standardisering för tidigt fryser fel beslut.

Förslaget är "bygg en portal" utan listan med smärtpunkter den tar bort.

För solobyggare och små side-project-crew är den ärliga slutsatsen enklare. Du behöver inte ett platform-team, men du behöver vanorna: ett repeaterbart deploy-script, en mall för nya projekt, en instrumentpanel du kollar. Det är en plattform för en, och det sparar dig en helg varje månad.

Verktygen folk faktiskt kombinerar

Det finns ingen enskild "platform engineering-produkt". Team sätter ihop en stack, och bitarna faller in i några buckets.

För portalen och katalogen använder många team Backstage eller ett hosted-alternativ, som ger en sökbar lista över tjänster, ägare och docs. För provisioning använder Terraform eller OpenTofu plus ett GitOps-verktyg som Argo CD eller Flux. För CI och delivery, vad du redan har, lindad i delade mallar.

Två buckets förtjänar en närmare titt, för de avgör om plattformen känns pålitlig.

Observerbarhet. Om utvecklare inte kan se vad deras tjänst gör kommer de inte att lita på plattformen som deployade den. Datadog ger dig en polerad enda ruta över infra, APM och loggar, till ett per-host-pris som växer snabbt. Grafanas open-source-stack kostar dig driftstid istället för licensavgifter. Välj baserat på om din knappa resurs är pengar eller uppmärksamhet.

Docs och kvalitet. En plattform utan bra docs är en ticket-kö i förklädnad. Docs-as-code-verktyg håller guider bredvid det repo de beskriver, och kodkvalitets-portar i CI håller mallarna ärliga.

Inget av detta är nödvändigt. De är exempel på lagret där ett platform-team spenderar sin tid: välja en standard, koppla in den i mallen, och äga uppgraderingsvägen.

Hur börjar man utan att bygga fel sak

De flesta misslyckade platform-insatser delar samma mönster. De börjar för stort, bygger i månader innan ett enda team rör det, och optimerar för roadmap-bilden istället för adoption. Fixet är ointressant.

Välj en smärtfylld, frekventa uppgift. "Skapa en ny tjänst" och "få en förhandsgransknings-miljö" är de vanliga vinnarna. Intervjua tre utvecklare och titta på dem göra det. Räkna stegen och minuterna.

Bygg den tunnaste versionen som tar bort mest av smärtan. Ett template-repo och en delad pipeline-fil räknas. Ge det till ett vänligt team och sitt bredvid dem medan de använder det. Fixa vad som brister, bjud sedan på ett andra team.

Spåra två siffror: hur länge från "ny tjänst" till "körs i produktion", och hur många team använder vägen frivilligt. Om den andra siffran är platt är plattformen ett mandat, och mandat förmultnar.

Bemanna det som ett produktteam. Platform-ingenjörer är inte DevOps med en ny titel. platformengineering.org-materialet noterar att platform-ingenjörer tjänar omkring 27% mer än DevOps-proffs, vilket säger dig att marknaden ser produkt-och-teknik-mixen som ett distinkt, svårare jobb.

En mer anledning att göra det nu: det nyaste snåret är att "användaren" av en plattform inte längre bara är en människa. Kodande agenter öppnar pull-requests, kör tester och frågar om miljöer. En plattform med rena mallar, klara behörigheter och maskinläsbara docs är en mycket säkrare plats för en agent att jobba än en hög med snöfling-repos.

Kortlivade credentials, förhandsgransknings-miljöer och en konsekvent pipeline är det som håller en agents misstag begränsade till en kastbar gren. Om din plattform inte kan säga en mänsklig deploy från en automatiserad, lägg till det innan du lägger till något annat.

Vad ska du bygga härnäst?

Om du leder ett team på 30 utvecklare och varje squad har sin egen pipeline är ett litet platform-team med en gyllne väg förmodligen din högsta spakarhyrning. Om du är en solodev med tre side-projekt, kopiera din bästa projekts pipeline till ett template-repo den här helgen och ring det klart.

Oavsett, frågan värd att ta till ditt nästa planeringsseminarium är konkret: vilken enskild uppgift upprepar dina utvecklare mest, och vad skulle det ta för att göra den ett enkommando-jobb?