Den ultimata guiden till Platform Engineering

Platform Engineering missförstås ofta som något mycket tekniskt och tidskrävande att bygga upp och driva. Men med rätt utformning behöver det inte vara så. Så vad är Platform Engineering? I grunden är Platform Engineering en uppsättning verktyg och metoder kring verktygskedjor för utveckling som gör det enklare för utvecklare att skapa bra mjukvara och skydda tid, pengar och konkurrenskraft.

Det innebär att skapa nya eller förbättra befintliga Internal Developer Platforms (IDP:er). Genom att fokusera på IDP:er skapas effektivitetsvinster som ger utvecklare mer utrymme att tänka innovativt. En välstrukturerad IDP stöttar teamen och säkerställer att alla delar av mjukvaruutvecklingens livscykel håller ihop, från idé till produktion.

Platform Engineering med smart strukturerade IDP:er ger i slutändan "golden paths" som utvecklare snabbt kan använda. Begreppet IDP har ofta flera betydelser och används till och med som ett samlingsbegrepp. På Eficode utgår vi från den klassiska definitionen, som tar hänsyn till dess positionering, dem som använder den och den teknik den omfattar. För oss är det ett extra lager som förenklar driften och gör det möjligt för utvecklare att hjälpa sig själva med befintlig teknik och befintliga verktyg.

I takt med att AI fortsätter att bli allt vanligare kan Platform Engineering hjälpa din organisation att stärka sin konkurrenskraft på flera sätt, oavsett om det handlar om att bygga en egen modell, lagra organisationsspecifik kontext, bygga stödjande modeller eller köra AI-arbetslaster.

Vad är en Internal Developer Platform? Läs mer i vårt blogginlägg "Internal developer platforms: What they are and why you need one." Klicka på länken nedan

Platform Engineering jämfört med DevOps

Vad är DevOps? definierar DevOps som produktledning, driftsäkerhet, teknisk kvalitet och en sund företagskultur. Genom att bryta ner silos mellan mjukvaruutveckling och drift kopplar DevOps samman återkoppling från slutanvändare i produktionsmiljöer med utvecklingsteamen, så att de kan reagera på marknadsförhållanden och lära sig snabbare än konkurrenterna. Detta har en dokumenterat god effekt på Business Agility och prestanda.

Vi hjälper hundratals organisationer att utveckla sin DevOps och tror på vikten av att få arkitekturen rätt. Därför ser vi Platform Engineering som en vidareutveckling av DevOps. Platform Engineering är ett fokuserat angreppssätt och en filosofi som tillämpas strategiskt och taktiskt för att uppnå flera resultat samtidigt.

Vissa säger: ”DevOps är dött, leve Platform Engineering!” eller söker online efter ”DevOps vs Platform Engineering”, men de två angreppssätten kompletterar varandra. Platform Engineering använder DevOps-metoder samtidigt som det minskar den kognitiva belastningen och ger utvecklare möjlighet till självbetjäning.

Applikationsutveckling blir allt mer komplex i takt med att DevOps fortsätter att växa. Utvecklare behöver lära sig nya verktyg för digitala plattformar, hantera infrastruktur och prioritera driftuppgifter samtidigt som de kodar nya funktioner. Dessa krav minskar produktiviteten, ökar risken för utbrändhet och leder till arbetsrelaterad trötthet.

Platform Engineers är avgörande för att förenkla standardiserade DevOps-processer

Tänk dig ett företag som skapar webbapplikationer med en enhetlig struktur: en databas, en backend som tillhandahåller RESTful API:er och ett webbaserat frontend. Moderna mjukvaruverktyg och mallar har visserligen införts, men utvecklingsprocessen är fortfarande starkt beroende av manuellt arbete. DevOps Engineers ansvarar för att skapa Docker-filer, skriva Terraform-skript, konfigurera projektspecifika build-pipelines och hantera uppdateringar av miljöer.

Vanligtvis fungerar en Platform Engineer som expert och samarbetar nära med utvecklarna. De vägleder och styr konfigureringen och driften av systemet för att möta utvecklarnas behov, samtidigt som de hanterar övervakning och larm samt hjälper utvecklarna att uppfylla sina Service Level Agreements (SLA:er). I en miljö med DevOps-team skulle detta skapa kritiska flaskhalsar, förlänga utvecklarnas ledtider och belasta DevOps Engineers avsevärt.

Platform Engineers förenklar detta med hjälp av en Internal Developer Platform (IDP) för att automatisera uppgifter, med självbetjäning som utgångspunkt. Utvecklare behöver inte konfigurera Git-repositorier manuellt, eftersom användare snabbt kan begära att en IDP skapar användargrupper och automatiskt integrerar rätt CI/CD-mall.

Vissa Platform Engineers samarbetar till och med med ledningen för att integrera långsiktiga mål och företagets vision i utvecklingslivscykeln. Många företag har antingen egna ingenjörer eller behöver konsulter. Det är här Eficode kommer in.

Platform Engineering ersätter inte DevOps-metoder – det bygger vidare på dem

Platform Engineering ger team ett enkelt sätt att starta projekt med standardiserade mönster. Dessa mönster är inbyggda i en IDP med funktioner för självbetjäning, vilket gör att teamen kan börja skapa värde direkt i stället för att lägga veckor på projektkonfigurering och problemlösning.

Självbetjäning gör det möjligt för utvecklare att arbeta självständigt och samtidigt följa regelverk utan att bli överbelastade. Därför kan Platform Engineers fokusera på större arkitekturutmaningar, förbättra befintliga funktioner och anpassa systemet till förändrade behov.

Lyssna på poddavsnittet ”Platform engineering done right” om möjligheterna med en IDP på den portugisiska banken Millenium BCP.

Platform Engineering omfattar Site Reliability Engineering som en beprövad metod

Google var först med Site Reliability Engineering (SRE), som fokuserar på att drifta och förbättra mjukvaruapplikationer i stor skala. Trots att de låter lika är Platform Engineering och Site Reliability Engineering olika saker. SRE handlar främst om drift: att köra en tjänst och säkerställa att den är kontinuerligt tillgänglig och uppdaterad. SRE erbjuder dock också en modell för tjänstehantering som kan tillämpas på IDP:er. Tillvägagångssättet som beskrivs i "Site Reliability Engineering - How Google Runs Production Systems" är särskilt relevant. Platform Engineering omfattar däremot SRE-tänkande och har ett mer holistiskt mål: att förstå samspelet mellan processer, människor och teknik.

Tillförlitlighet inom Platform Engineering

En mjukvaruapplikation kan inte erbjuda ett högre Service Level Agreement (SLA) än de lägre lagren i stacken. För att en applikation ska kunna garantera 99,9 % tillgänglighet måste alla dess infrastrukturkomponenter erbjuda samma nivå. SLA:er är viktiga mellan ett plattformsteam och de utvecklingsteam som använder plattformen. De utgör ett löfte om övergripande SLA:er och ger därmed utvecklingsteamen en förväntad nivå av tillförlitlighet.

Ett Service Level Objective (SLO) anger en målnivå för en tjänst, som mäts med en Service Level Indicator (SLI). Att välja rätt SLO:er är utmanande men avgörande för plattformsteamets resultatmätning och verksamhetens framgång. Det hjälper plattformsteam att balansera innovation och tillförlitlighet med hjälp av en felbudget och marginalen mellan SLI och SLO.

Obs: SLO:er och felbudgetar bör också publiceras för att tydliggöra förväntningarna för intressenter.

Plattformsteam och incidenthantering

Plattformsteam är avgörande för tillförlitligheten hos de mjukvaruapplikationer som körs på deras plattform och infrastruktur. De måste också ta ansvar för problem med de delar som tillhör plattformsteamet vid driftstopp eller andra problem.

Teamens samarbetsformer

Site Reliability Engineering-team (SRE-team) arbetar nära utvecklingsteamen, och samarbetet förändras i takt med att applikationen utvecklas. Ett SRE-team kan bestå av både möjliggörande team och driftsteam och ge stöd kring skalning och utveckling av tillförlitliga tjänster fram till en viss punkt. SRE-teamet bör ta fullt ansvar för tillförlitligheten hos en eller flera digitala plattformstjänster. Detta skiljer sig från ett plattformsteam, som förväntas leverera självbetjäningsgränssnitt som utvecklingsteamen kan använda. Plattformsteamet behöver ett produkttänk och en nära återkopplingsloop med utvecklingsteamen för att bygga rätt saker.

Olika typer av organisationer har olika utmaningar, men en sak är säker: Plattformen behöver vara flexibel och anpassningsbar och utformas med framtida behov i åtanke. Det innebär bland annat att bedöma AI-beredskapen och förstå hur AI kan bidra till effektiviseringar och kostnadsbesparingar. Tre aspekter är särskilt viktiga, oavsett bransch.

Kortare time to market

Det handlar inte bara om att snabbt driftsätta mjukvara, utan också om vilken bredare effekt nya mjukvarulösningar har på användarupplevelsen och verksamhetens tillväxt. En robust plattform fungerar som en katalysator och kan skydda utvecklare från komplexiteten i att hantera infrastrukturen, så att de kan fokusera på att skapa de funktioner som är viktigast för användarna och verksamheten.

Ökad kostnadseffektivitet

En enhetlig plattform fungerar som en katalysator för strategisk ekonomistyrning. Genom att centralisera infrastruktur och verktyg i en plattform ökar kostnadstransparensen och tjänsteägarna får bättre förutsättningar. Med denna insyn kan team tryggt bedöma och balansera sina utgifter mot de intäkter och det affärsvärde de skapar. När kostnadsmedvetenhet kombineras med affärsdrivet beslutsfattande skapas en kultur där IT-investeringar fokuserar lika mycket på att skapa värde som på att begränsa kostnader.

Använd AI där det passar

AI har utan tvekan blivit ett stort ämne i alla organisationer i dag, vilket ofta leder till fragmenterade implementationer och olika typer av stödmaterial anpassat till olika sammanhang. Innovation är avgörande, men när det blir dags att skala upp behövs en stödjande plattform.

Se AI i praktiken. Titta när Kalle Mäkelä, Lead Digital Solutions and AI på Eficode, berättar om AI:s praktiska användningsområden. Klicka på länken nedan.

Förbättrad Developer Experience

Att attrahera och behålla duktiga utvecklare är avgörande för alla organisationer som drivs av mjukvara. Genom att investera i plattformar som samlar och effektiviserar mjukvaruleveransen skapar organisationen tydliga och säkra spår för utvecklarna att köra på. En bra plattform erbjuder en välkomnande miljö för att starta projekt och trygghet att experimentera.

Med en robust teknikstack kan Platform Engineering-teamet hjälpa utvecklare att skapa meningsfullt arbete utan friktion och krångel. Utvecklare kan ofta uppleva hinder för sin kreativitet när de ska säkerställa konsekventa arbetssätt, säkerhet och dokumentation i olika team och system – något som ofta kallas ”kognitiv belastning”.

Läs mer i Henrik Høeghs föredrag på The DEVOPS Conference Stockholm 2023.

Hur ser det ut i din bransch?

Ingen organisation är den andra lik, men generella behov och förutsättningar beror på organisationens bransch och det aktuella affärsklimatet.

Reglerade organisationer: Konkurrera med Platform Engineering

Företag med omfattande compliance- och regulatoriska krav, såsom finansinstitut, läkemedelsföretag och myndigheter, behöver lösningar för Platform Engineering som uppfyller deras krav på skyddsräcken och skapar effekt utan att kompromissa med verksamhetens konkurrenskraft.

Dessa organisationer kan uppleva att deras innovationsförmåga och möjlighet att attrahera talanger ofta hämmas av att nödvändiga, grundliga processer och dokumentation kan vara långsamma och ibland byråkratiska. De behöver ett modernt plattformsupplägg som erbjuder funktioner som automatisk compliance med policy as code, spårbarhet, software bill of materials, AI-stödd granskning och konsekventa miljöer. Ett sådant upplägg, utformat med en responsiv och flexibel plattform samt smart engineering i åtanke, gör det möjligt för reglerade organisationer att få:

• Enklare utvecklingscykler överlag.

• Bättre beslutsunderlag för ledningen.

• Kortare tid till värde för kunderna.

• Minskad kognitiv belastning för utvecklare.

Embedded-organisationer: Nytänkande inom Platform Engineering

Företag som tillverkar produkter som bygger på eller förbättras av teknik behöver lösningar för Platform Engineering som stödjer deras ambitioner. Från organisationer som tillverkar smartklockor till de som levererar bilar – alla är beroende av embedded-teknik. För dessa embedded-organisationer är det avgörande att minska tiden till marknaden och hålla sina erbjudanden uppdaterade. Utmaningar uppstår när programvara och processer samt plattformar för mjukvaruutveckling är föråldrade eller åldras och behandlas som mindre viktiga.

Att bygga plattformslösningar kräver bred kunskap hos dessa produktfokuserade och driftinriktade organisationer, men kunskapen är ofta isolerad inom deras utvecklingsteam och teknikavdelningar. Därför behöver de ett modernt plattformsupplägg som går bortom funktionalitet och tar hänsyn till stabilitet och snabbhet vid uppdateringar – ett upplägg som effektiviserar arbetsflöden, ger datadrivna insikter, höjer kvaliteten, säkerställer säkra uppdateringar och datahantering samt förbättrar beslutsfattandet överlag. Att tänka om kring vad som är möjligt med Platform Engineering innebär för dessa organisationer inte bara nöjdare kunder, utan även nöjdare utvecklare.

Mjukvaruorganisationer: Innovationsdriven Platform Engineering

Mjukvarufokuserade företag verkar i snabbrörliga och konkurrensutsatta affärsklimat och behöver ofta en mer eller mindre självgående process för mjukvaruutveckling. Teknikverktygen kan vara fragmenterade och utvecklingsprocesserna röriga, vilket ofta bromsar utvecklarnas produktivitet och tiden till marknaden. Det leder till frustration som tar för mycket mental kapacitet i anspråk – kapacitet som i stället borde användas för att säkra innovation. Dessa organisationer behöver ett plattformsupplägg som är lika modernt och anpassningsbart som de själva. Och som ger utvecklarna frihet att följa sina kreativa idéer.

Lösningar för Platform Engineering kan erbjuda funktioner som systematiska sätt att samarbeta, teamanpassade dashboards, mallar för pipelines för kontinuerlig förbättring/Continuous Delivery (CI/CD) samt golden paths för säker, skalbar och snabb mjukvaruutveckling. Resultatet kan bli:

• Konsekventa utvecklingsmiljöer.

• Minskad kognitiv belastning.

• Smidig onboarding för utvecklare.

• Kostnadsoptimering.

• Inbyggd säkerhet och compliance.

Se hur vi hjälpte TV2 Danmark att förnya sin molninfrastruktur och bygga en Internal Developer Platform som stödjer utvecklarnas kreativitet. Klicka på länken nedan.

Eftersom varje plattform har två aspekter – operativa funktioner och Developer Experience – finns det några tumregler som hjälper till att skapa en hållbar och stabil grund för alla organisationer.

Samarbetets kraft

Tekniska team måste samarbeta med organisatoriska intressenter för att få det stöd och de resurser som krävs för att bygga en Internal Developer Platform (IDP). Stöd från ledningen är avgörande, eftersom det krävs betydande resurser för att bygga en IDP och arbetet inte bara handlar om tekniska utmaningar.

Teamledare ansvarar också för att skapa förankring: de måste få utvecklarna att samarbeta. Nyckeln till framgång är en transparent byggprocess med fokus på användning och lättanvända gränssnitt, samtidigt som den stödjer applikationernas operativa behov.

Läs mer i vårt blogginlägg om ”Att etablera en Platform Engineering-organisation”.

Välj verktyg med omsorg

Att bygga en framgångsrik IDP handlar om mycket mer än vilka verktyg du använder, men det går inte att förneka att rätt verktygsval också spelar roll. Ska du välja det ena eller det andra? Bygga själv, köpa eller införa en befintlig lösning? Det är några av de viktigaste frågorna att ställa. Varje organisation har sina egna behov, processer, principer och budgetar – det handlar om att bygga något som passar just din organisation.

Länkar: utvärdering av verktygskedjan eller en teknikspecifik utvärdering.

Oavsett om du väljer mellan virtuella maskiner eller Kubernetes, on-premise eller molnet, eller ett driftsättningsverktyg framför ett annat, handlar rätt val om att tänka på vad verktyget tillför – både för dig som bygger plattformen och för dig som använder den. Ofta behöver du överväga om valet är svårt att ändra senare eller om du enkelt kan byta till något annat när tekniker och arbetsflöden förändras.

Större beslut kan kräva ytterligare samarbete eftersom många intressenter är involverade. Tekniska möjligheter, policyer, säkerhet och juridiska krav behöver vägas samman med inköp, ekonomi och andra funktioner i organisationen. Som tur är är inte alla beslut lika komplexa när du bygger en IDP. Det finns en rad branschstandarder och beprövade metoder som vägleder dig, och många open source-verktyg har mognat. Detsamma gäller standarder som många kommersiella produkter har valt att följa. I många fall kan du då byta ut flera delar av din lösning eller skjuta upp ett något svårare beslut till senare i processen, så länge du följer en standard.

Oavsett vad du väljer kan du alltid komma i gång utan att bygga en helt skräddarsydd lösning. Se bara till att anpassa de verktyg som finns på marknaden, så att du frigör tid för att möta plattformsanvändarnas behov i stället för att kämpa med alltför komplexa implementationer. Vi uppskattar den kreativa processen i implementationer, men det finns gränser för hur mycket vi kan och bör investera i att bygga allt själva.

Läs mer i det här inlägget om ”Välja med omsorg: en konsults modell för att välja developer portal”.

Var nyfiken: Experimentera och förbättra

Det är lätt att fastna i kaninhålet med att bygga ett stabilt grundlager. Vi vill ha allt på plats innan det första teamet börjar använda plattformen. Vi vill också att våra utvecklare ska få en bra upplevelse, så vi känner att vi måste ”ha allt färdigt” innan de kan köra sina tjänster.

I verkligheten blir vi aldrig klara med grundlagret. Vi kan fokusera på den minsta möjliga fungerande plattformen och ändra vårt tankesätt till stegvisa förbättringar. Då kan vi bygga mindre delar (och vara mer Agile) samt validera med våra utvecklare oftare. Annars skulle vi lägga mycket tid på att bygga det vi tror att utvecklarna vill ha utan att få det validerat.

Även om vi vill bygga i små steg bör vi alltid lyfta blicken, se framåt och tänka på en roadmap, eftersom modern mjukvaruutveckling har många krav. Ibland finns det krav som inte går att förhandla bort och som vi måste ta med från början, men vi bör kunna lösa dem utan att fördröja de första användarna.

Om du tvekar inför att gå till produktion och behöver göra lite mer arbete, kontakta dina kollegor. De vill att du ska lyckas och kan hjälpa till att testa plattformen.

Vill du veta mer om utmaningarna och fallgroparna inom Platform Engineering? Se Dan Grøndahl Glavinds föredrag ”Platform Engineering is Hard, and We are Doing it Wrong” från DevOpsDays Denmark 2023.

De flesta sätt att utvärdera mjukvaruutveckling fokuserar på lokal produktivitet, kvalitet och konsekvens i leveransprocessen. För DevOps finns väletablerade mätvärden tack vare programmet DevOps Research Assessment (DORA):

• Driftsättningsfrekvens.

• Ledtid för ändringar.

• Genomsnittlig återställningstid.

• Andel misslyckade ändringar.

• Tillförlitlighet.

Med dessa mätvärden kan vi kvantifiera effekten av DevOps-kultur och -metoder utifrån IT-prestanda och kvalitet. På senare tid har fokus skiftat mot att utvärdera hur utvecklare upplever och värdesätter sitt arbete, med ett DevX-centrerat synsätt på hur framgång mäts.

Att mäta Developer Experience

Att mäta DevEx kan kännas överväldigande eftersom begreppet i sig är mycket brett. Därför är det bra att börja med ett ramverk som identifierar de tre kärndimensionerna inom DevEx: återkopplingsloopar, kognitiv belastning och flowtillstånd. Dessa dimensioner betonar att DevEx inte bara är en teknisk fråga, utan framför allt handlar om utvecklarnas upplevelser. Insikter är en bra början, men glöm inte värdet av informella samtal mellan kollegor och team.

Utvecklare är människor, och inget enskilt kvantitativt mätvärde kan fånga DevEx på ett korrekt sätt. Därför är det avgörande att samla in kvalitativ återkoppling från utvecklare genom enkäter. Återkopplingen beskriver bland annat den upplevda komplexiteten och nöjdheten med att driftsätta kod och använda en plattform. Till exempel:

• Användarvänliga verktyg hjälper utvecklare att snabbt effektivisera utveckling och driftsättning utan krångel.

• Självbetjäningsfunktioner ger utvecklare större självständighet och kontroll.

• Dokumentation av hög kvalitet hjälper utvecklare att navigera i komplexa infrastrukturer.

• Plattformen gör det möjligt att samla in olika mätvärden kopplade till DevEx.

• En snabb uppsättning av utvecklingsmiljön främjar produktivitet och kreativitet när minimiprodukter (MVP:er) ska tas fram.

Platform Engineering handlar om mer än att förbättra produktiviteten och möjliggöra snabbare innovation. Genom att förbättra DevEx gör en bra plattform utvecklarna mer nöjda, vilket stärker möjligheterna att behålla medarbetare, attrahera talanger och nå verksamhetens mål.