Plattformsteknik

Plattformsteknik, eller Platform EngineeringPlatform engineeringPlatform engineering, eller plattformsteknik, är disciplinen att bygga interna plattformar, verktyg och arbetsflöden som gör det enkelt för utvecklingsteam att leverera mjukvara säkert, snabbt och konsekvent.Läs mer i ordlistan →, handlar om att bygga interna plattformar, verktyg och workflows som gör det enklare för utvecklingsteam att leverera mjukvara på ett säkert, snabbt och konsekvent sätt.

Det kan inkludera molninfrastruktur, CI/CDCI/CDCI/CD står för continuous integration och continuous delivery/deployment: automatiserade flöden där kod byggs, testas och levereras till produktion i små, täta steg i stället för stora, riskfyllda releaser.Läs mer i ordlistan →, Kubernetes, containerplattformar, infrastruktur som kod, observability, IAM, säkerhet, självservice, developer portals, templates och stöd för moderna AI-workloads.

Målet är inte att centralisera allt eller skapa ännu ett lager av processer. Målet är att skapa tydliga standarder och smart automation som gör att team kan arbeta autonomt utan att uppfinna samma lösningar om och om igen.

Ett starkt plattformsteamPlattformsteamEtt plattformsteam bygger och driver den interna plattform andra team levererar på, så att de slipper lösa infrastruktur, CI/CD och drift var för sig. I Team Topologies är det en av fyra teamtyper, jämte stream-aligned, enabling och complicated-subsystem.Läs mer i ordlistan → bygger därför inte bara infrastruktur. Det bygger utvecklarupplevelser.

Molnplattformar som AWS, Google Cloud och Microsoft Azure har gjort det möjligt att skala system snabbare än någonsin tidigare. Men de har också introducerat enorm komplexitet.

Många utvecklare känner igen situationen: "cloud native" betyder plötsligt flera repositories, olika CI-system, hundratals Terraform-resurser, Kubernetes-manifest ingen vågar röra och IAM-policyer som bara en person i organisationen förstår.

Det är inte där värdet ligger.

Rätt byggd molninfrastruktur ska göra det enkelt att deploya, skala och drifta applikationer utan att varje team behöver bli experter på alla underliggande detaljer. Plattformen ska ge trygghet genom standardiserade mönster för säkerhet, nätverk, kostnadskontroll, logging, övervakning och tillgänglighet.

Vi bygger och optimerar plattformar på AWS, Google Cloud och Azure med fokus på skalbarhet, säkerhet, kostnadseffektivitet, automatisering och hög tillgänglighet. Men framför allt med fokus på verklig användbarhet.

För en plattform som ingen vill använda skapar inget värde, oavsett hur tekniskt avancerad den är.

Terraform har blivit en standard för Infrastructure as CodeInfrastructure as Code (IaC)Infrastructure as Code innebär att miljöer, nätverk, behörigheter och resurser definieras i versionshanterad kod i stället för att klickas fram manuellt — vilket gör infrastrukturen spårbar, testbar och repeterbar.Läs mer i ordlistan → av goda skäl. När infrastruktur definieras deklarativt får team versionshantering, code review, reproducerbara miljöer, tydligare förändringshantering och mindre beroende av manuella ingrepp.

Det skapar också en gemensam modell där infrastruktur hanteras med samma kvalitet och kontroll som applikationskod.

Men Terraform kan användas på bra och dåliga sätt.

En vanlig fälla är att bygga enorma monolitiska Terraform-projekt som med tiden blir svåra att förstå, testa och förändra. En annan är att skapa moduler som försöker lösa allt och till slut kräver specialistkunskap bara för att användas.

Vår erfarenhet är att bra Terraform bygger på små, tydliga moduler med ett avgränsat ansvar. De ska exponera få inputs, vara enkla att förstå och göra rätt väg till den enkla vägen.

Miljöer bör också separeras tydligt. Hellre explicita state-filer, tydliga pipelines och kontrollerade flöden än "workspace magic", manuella overrides och copy-paste-konfiguration som ingen längre vågar ändra.

Terraform utan automation blir snabbt riskfyllt. Därför bör plattformen stötta pull request-planer, policy checks, drift detection och automatisk dokumentation. Då blir Infrastructure as Code inte bara ett sätt att skapa resurser, utan ett arbetssätt som ger tryggare förändringar och snabbare onboarding.

Kubernetes är ett av de mest kraftfulla verktygen i modern infrastruktur. Det är också ett av de mest överanvända.

Många organisationer adopterar Kubernetes innan de faktiskt behöver det. Resultatet blir ofta en plattform som kräver mer energi än den ger tillbaka. Det är sällan Kubernetes i sig som är problemet. Det är allt runt omkring: för många operators, för många speciallösningar, för många sätt att deploya och för få gemensamma standarder.

När Kubernetes används rätt kan det däremot ge stor effekt. Det möjliggör skalbarhet, workload-isolering, standardiserade deploymentstrategier, effektiv resursanvändning och bättre förutsättningar för både multi-cloud och moderna applikationsarkitekturer.

Nyckeln är att inte låta varje team göra allt på sitt eget sätt.

En bra Kubernetes-plattform bör erbjuda golden pathsGolden pathEn golden path är en färdig, rekommenderad och självbetjänad väg genom ett vanligt utvecklarflöde — till exempel från nytt repo till tjänst i produktion — med standarder, säkerhet och automation inbyggda.Läs mer i ordlistan →, standardtemplates, säkra defaults, rekommenderade CI/CD-flöden, observability från start och tydliga ramar för hur applikationer byggs, deployas och driftas.

Då blir Kubernetes inte något utvecklare behöver kämpa med. Det blir en stabil grund som hjälper dem att leverera.

CI/CD ska minska ledtid, inte skapa byråkrati.

En bra pipeline ger snabb feedback, få manuella steg och en tydlig väg från kod till produktion. En dålig pipeline gör utvecklare osäkra, långsamma och rädda för releaser.

Med verktyg som GitHub Actions, GitLab CI/CD och Argo CD bygger vi automatiserade leveransflöden som ger kortare ledtider, säkrare releaser, enklare rollback och högre utvecklarproduktivitet.

Det viktigaste är ofta inte vilket verktyg man väljer, utan hur flödet känns i praktiken.

Builds bör vara snabba. Tester bör köras parallellt där det är möjligt. Caching bör användas aggressivt. Feedback bör komma inom minuter, inte efter lunch.

Vi ser också att trunk-based developmentTrunk-based developmentTrunk-based development är ett arbetssätt där alla utvecklare integrerar små ändringar mot en gemensam huvudgren (trunk/main) flera gånger om dagen, i stället för att arbeta länge i separata feature branches.Läs mer i ordlistan → och små, frekventa deployer nästan alltid fungerar bättre än långa feature branches och stora releasepaket. Kortare feedbackloopar minskar merge-konflikter, integrationsproblem och releaseångest.

GitOpsGitOpsGitOps är ett arbetssätt där Git är källan till sanning för både infrastruktur och applikationskonfiguration: önskat tillstånd beskrivs i kod, granskas i pull requests och rullas ut automatiskt av verktyg som håller verkligheten i synk.Läs mer i ordlistan → med exempelvis Argo CD kan skapa bättre spårbarhet, deklarativa deployer och enklare rollback. Men det behöver inte användas överallt. Enkelhet vinner ofta. Rätt nivå av automation är den som gör leveransprocessen snabb, stabil och förutsägbar utan att skapa onödig komplexitet.

Loggar räcker inte längre.

Moderna system kräver observability över metrics, logs, traces, events och ibland även profiling. Verktyg som Prometheus, Grafana, OpenTelemetry och Datadog kan ge enormt värde, men bara om de används för att besvara verkliga frågor.

Observability handlar inte främst om snygga dashboards. Det handlar om att snabbt förstå vad som händer i systemet.

Varför blev svarstiderna sämre? Vilken tjänst orsakar felet? Är problemet kopplat till en deployment, en specifik kund, en databasfråga eller en extern integration? Hur påverkar det användarna?

Bra tracing kan spara timmar eller dagar av felsökning. Rätt metrics kan minska MTTR och göra incidenter mindre dramatiska. Tydliga alerts kan hjälpa team att agera innan kunder påverkas.

Men observability skapar också produktvärde. När team förstår systembeteende bättre kan de fatta bättre tekniska och affärsmässiga beslut.

Developer ExperienceDeveloper experience (DX)Developer experience (DX) är summan av hur det känns och hur lång tid det tar för utvecklare att göra sitt jobb: starta en tjänst, hitta dokumentation, få feedback från tester och deploya till produktion.Läs mer i ordlistan → är ofta skillnaden mellan en plattform som används och en plattform som kringgås.

Dålig DX visar sig snabbt: lång onboarding, lokala miljöer som aldrig fungerar, deployprocesser folk är rädda för, intern dokumentation ingen hittar och tribal knowledge som bara finns i huvudet på några få personer.

Bra DX innebär standardiserade workflows, självservice, tydliga templates, fungerande dokumentation, snabb feedback och genomtänkta defaults.

De bästa interna plattformarna känns nästan osynliga. Utvecklaren behöver inte förstå hela Kubernetes-klustret, konfigurera IAM manuellt, skriva deployment-YAML från scratch eller memorera interna scripts. Plattformen tar bort repetitivt arbete och gör rätt sak enkel att göra.

Det här är inte bara en teknisk förbättring. Det är en konkurrensfördel.

När utvecklare slipper lägga tid på manuella, repetitiva och osäkra moment kan de fokusera på att skapa affärsvärde. Onboarding går snabbare. Leveranser blir jämnare. Drift blir tryggare. Team blir mer självständiga.

AI förändrar snabbt kraven på modern infrastruktur.

Det handlar inte längre bara om webbappar, API:er och databaser. Fler organisationer behöver nu hantera GPU-workloads, model serving, embeddings, vektor-databaser, batch inference och realtidsinference.

Det ställer nya krav på plattformen.

GPU-resurser behöver schemaläggas effektivt. Modeller behöver kunna deployas, övervakas och uppdateras. Dataflöden behöver vara robusta. Kostnader behöver kontrolleras. Latens, skalning och säkerhet blir centrala frågor.

Vi arbetar med moderna lösningar för GPU-workloads, modellhosting, batch inference, real-time inference, embeddings och semantic search med tekniker som NVIDIA CUDA, Ray, Kubeflow och relevanta molntjänster.

För AI-applikationer bygger vi även lösningar med vektor-databaser som Pinecone, Weaviate och Qdrant. Det möjliggör semantic search, Retrieval-Augmented Generation, intelligenta AI-assistenter och skalbar hantering av embeddings.

Men precis som med Kubernetes gäller samma princip här: tekniken ska lösa ett verkligt problem. Inte införas för att den är trendig.

Vi tror på pragmatiska lösningar framför överarkitektur.

Det betyder enkelhet där det är möjligt, automation där det skapar värde och standardisering utan att begränsa team i onödan. Det betyder också att plattformen måste byggas med respekt för organisationens verklighet: befintliga system, teamens kompetens, säkerhetskrav, budget, leveranstakt och affärsmål.

En bra plattform är inte den som har flest komponenter. Det är den som gör det lättare att leverera.

I praktiken innebär det att vi hjälper organisationer att:

• bygga stabil och skalbar molninfrastruktur
• införa eller förbättra Infrastructure as Code
• skapa Kubernetes- och containerplattformar som utvecklare faktiskt kan använda
• automatisera CI/CD-flöden
• förbättra observability och incidenthantering
• skapa självservice och bättre developer experience
• bygga infrastruktur för AI-workloads och semantic search
• minska operativ komplexitet utan att tappa kontroll

Rätt plattform handlar inte bara om teknik. Den skapar förutsättningar för snabbare time-to-market, tryggare drift, bättre utvecklarupplevelse och hållbar skalning.

När plattformsteknik fungerar bra får organisationen kortare utvecklingscykler, högre leveranskapacitet, stabilare system och mindre beroende av manuella processer. Team kan röra sig snabbare utan att tumma på säkerhet, kvalitet eller kontroll.

Det är där modern plattformsteknik gör verklig skillnad.

Inte genom fler lager av abstraktion för abstraktionens skull. Inte genom att göra infrastrukturen mer imponerande än den behöver vara. Utan genom genomtänkta standarder, smart automation och verktyg som hjälper utvecklare att fokusera på rätt problem.

De bästa plattformarna är sällan de mest komplexa.

De bästa plattformarna är de som låter team leverera utan att behöva tänka på infrastrukturen hela tiden.