Håll dig konkurrenskraftig: anamma platform engineering

Platform engineering är en uppsättning verktyg och metoder kring utvecklingsverktygskedjor som gör det enklare för en utvecklare att skapa bra programvara. Det skapar en intern utvecklingsplattform (IDP), som hjälper till att stödja team inom molnbaserade företag och omfattar plattformens design, implementering och operativa aspekter under hela tjänstens livscykel. Det har nyligen blivit mycket populärt på grund av den växande efterfrågan på förbättrade metoder för utvecklare och drift.

platform engineering kan erbjuda "gyllene stigar" eller "asfalterade vägar" som utvecklare snabbt kan ta till sig om de hanteras på rätt sätt. Termerna används ofta om vartannat, men i grund och botten handlar det om samma behov - att plattformar ska erbjuda ett enklare sätt för utvecklare att bygga, leverera och köra sin programvara. Plattformen tillhandahåller automatisering och olika abstraktionsnivåer för att stödja mjukvaruutvecklingsprocessen i enlighet med ett företags styrning.

Mjukvaruutveckling fortsätter att vinna mark i dagens affärslandskap, oavsett sektor. Företag måste prioritera att investera i en väl utformad IDP för att uppnå högre produktivitet, effektivitet och motivation.

Här är en lista över hur en IDP kan hjälpa ditt företag:

Accelerera "time to value"

Det handlar inte bara om att snabbt kunna driftsätta programvara, utan om den bredare effekt som en ny programvarulösning har på användarupplevelsen och företagets tillväxt. En robust plattform fungerar som en katalysator och kan skydda utvecklarna från de invecklade detaljerna i infrastrukturhanteringen - vilket gör att de kan fokusera på att skapa de funktioner och egenskaper som är viktigast för användarna och verksamheten.

Öka kostnadseffektiviteten

En enhetlig plattform fungerar som en katalysator för strategisk ekonomisk förvaltning. Att centralisera infrastruktur och verktyg via en plattform ökar kostnadstransparensen och ger serviceägarna mer inflytande. Med denna insyn kan teamen tryggt mäta och balansera sina utgifter och anpassa dem sömlöst till de intäkter och det affärsvärde som de ger. Denna konvergens mellan kostnadsmedvetenhet och affärsdrivet beslutsfattande främjar en kultur där IT-investeringar fokuserar på värdeskapande precis som de gör med kostnadsbegränsning.

Förbättra utvecklarnas upplevelse och attrahera nya talanger

Att attrahera och behålla talangfulla utvecklare är nyckeln till alla programvarudrivna organisationer. Genom att investera i plattformar för att förenhetliga och effektivisera programvaruleveransen lägger en organisation ut tydliga, säkra spår för sina utvecklare att tävla på. En plattform ger en välkomnande miljö för att starta projekt och trygghet för att experimentera. Tack vare en robust teknisk stack kan plattformsteamet göra det möjligt för utvecklare att producera meningsfullt arbete utan friktion.

Säkerställ compliance och säkerhet

Eftersom det digitala landskapet är så sårbart som det är, är skärpt säkerhet och integritet inte längre bara alternativ, det är en nödvändighet. Skyddsmekanismer som automatiserade verifieringskedjor, policy som kod, säkrad självbetjäning och konsekventa miljökonfigurationer kan integreras i din plattform. En framgångsrik plattform integrerar efterlevnad och säkerhet i arbetsflödet på ett sömlöst sätt. På så sätt kan utvecklarna fokusera på innovation utan att behöva tänka på säkerhet och regler.

Kolla in podcastavsnittet "Platform engineering done right" om kapaciteten hos en IDP i en portugisisk bank, Millenium BCP.

IDP:er erbjuder självbetjäning för utvecklare, vilket gör att de kan fokusera på sitt viktigaste arbete. Många företag känner till fördelarna med att använda IDP:er, men det är en utmaning att hitta rätt kompetens och strategi för att bygga en övertygande plattform.

Hur man kommer igång med platform engineering

Det finns många faktorer att ta hänsyn till. Tekniska team måste samarbeta med intressenter i organisationen för att få det stöd för den digitala plattformen och de resurser som krävs för projektet. Att få hjälp av ledningen är avgörande, eftersom det krävs betydande resurser för att bygga en IDP på egen hand och det handlar inte bara om tekniska utmaningar.

Detta åtagande kan bli kostsamt, särskilt för större organisationer. Här är några steg som en CTO kan ta för att komma igång:

1) Få ledningens stöd och låt dem ta ansvar för den övergripande visionen

2) Etablera ett team och låt dem definiera sin stadga och sitt uppdrag

3) Upptäck möjligheter som ger ett bra värde för applikationsutvecklingsteam

4) Fastställ mått för att mäta framgång

5) Prioritera, fokusera och leverera (programvara och dokument)

6) Fånga upp feedback och resultat

7) Kommunicera prestationer och utmaningar till sponsorer och intressenter

8) Se över teamets stadgar (uppdrag)

9) Iterera från steg 3

Läs mer om varje steg i vår bloggserie "Om jag var en CTO skulle jag närma mig platform engineering så här." (eller hoppa direkt till del två: Etablera en organisation för platform engineering).

Hör hur TV2, en dansk nationell TV-station och streamingplattform, kom igång med platform engineering.

Bygg inte på antaganden - experimentera och förbättra

Att falla i kaninhålet och bygga på grundläggande lager är vanligt. Innan vi välkomnar vårt första team till plattformen vill vi att allt ska vara på plats. Vi vill ju att utvecklarna ska få en bra upplevelse, så vi måste "ha det färdigt" så att de kan köra sina tjänster.

Men saker och ting är aldrig klara när det gäller programvara. Redan från början måste vi arbeta med stegvisa förbättringar med faktiska utvecklare så tidigt som möjligt. Annars bygger vi på antaganden, och de tenderar att svika oss. När allt kommer omkring har vi inte bevisat att vi har rätt att spela som ett plattformsteam.

Kanske kommer detta anti-mönster från ordet "plattform". Vi tror att den ska stödja hela programvaruleveransen, säkerheten, kvaliteten, övervakningen och driften på förhand. Det är okej att tänka på den större bilden, men börja i liten skala och bygg den tunnaste livskraftiga plattformen iterativt (ett koncept från boken Team Topologies). Så ta reda på det minsta möjliga användningsfallet som ger värde för utvecklare och bygg just det. Mät resultatet och lär dig vad du ska bygga härnäst.

Om du är rädd för att gå i produktion (vilket vi alla är) och bara behöver göra lite mer arbete, motstå denna uppmaning och kontakta dina mest öppna kollegor som vill att du ska lyckas och erbjuda sin hjälp för att testa plattformen.

Om du vill lära dig mer om utmaningarna och fallgroparna med Platform Engineering kan du kolla in föredraget "Platform Engineering is Hard, and We are Doing it Wrong" på DevOpsDays Denmark 2023.

Dokumentera din IDP

Börja med att skapa en dokumentationsplan och förutse vad som är viktigt baserat på utvecklarnas behov, beroende på de utmaningar de står inför för närvarande. Om du inte gör det kommer du sannolikt att ställas inför de problem som anges nedan:

• Utvecklare kommer att behöva hjälp med att komma igång med att använda din plattform och dess tjänster.
• Du kommer att behöva förklara hur vissa koncept och idéer fungerar upprepade gånger.
• Utvecklare kommer att påpeka att de försökte följa din dokumentation men misslyckades med ett av stegen eftersom de inte hade rätt version av specifik programvara installerad.
• Utvecklare kommer att vända sig till dig för felsökning när de stöter på hinder i stället för att hänvisa till dokumentationen.
• Du kommer hela tiden att hänvisa samma personer till samma dokumentation, med små resultat varje gång.

Målet är att ge en tydlig översikt över dina användare och hur de kan dra nytta av den. Spara den detaljerade tekniska dokumentationen till senare. Utvecklare letar efter plattformar som är lätta att förstå och använda. Genom att ta hänsyn till deras behov och tillhandahålla bra dokumentation kan du locka fler utvecklare att använda din plattform.

Läs vårt blogginlägg om bättre dokumentation för en bättre upplevelse för platform engineers om du vill ha mer information.

Att välja verktyg för platform engineering

Backstage? Crossplane? Argo CD? GitLab? Låt oss spola tillbaka lite här. Varje organisation kommer att behöva olika verktyg som fungerar för dem.

Teknik och verktyg är avgörande för att en plattform ska kunna leverera värde till sina användare. Vissa val måste göras tidigt, medan andra kan göras längs vägen. Vilken infrastruktur plattformen ska köras på bör naturligtvis också bestämmas i ett tidigt skede. Ska den byggas på en molnplattform, on-prem eller en hybrid?

Precis som med alla andra kritiska beslut bör det fattas med rätt intressenter i åtanke. Det är därför du bör involvera shared services (ekonomi, upphandling, säkerhet etc.) när du fattar beslut.

Här är några saker att komma ihåg:

• Undvik snäva kopplingar: Överväg att använda programvara och verktyg med öppen källkod som erbjuder ett brett utbud av tredjepartsintegrationer i stället för en lösning som passar alla. På så sätt undviker du att bli låst till en viss leverantör (eller teknik) i framtiden.

• Acceptera att saker och ting kommer att förändras: Oavsett vilket beslut du fattar kommer du sannolikt att vilja migrera inom 2-3 år.

Andra verktygsval är enklare och bör göras först när du är redo att ta dem i bruk. Undvik att i förväg göra åtaganden för verktyg som du inte planerar att använda inom den närmaste framtiden. Eftersom verktyg och teknik förändras snabbt bör du följa Lean-metoden och vänta med att göra åtaganden till sista ansvarsfulla ögonblicket (som beskrivs i boken Lean Software Development).

Det är också värt att fundera över hur många innovationstokens du har råd att lägga på nya verktyg. Plattformsteam är inte undantagna från att utsättas för kognitiv överbelastning. Hur tråkigt det än låter är det ibland bättre att börja med verktyg som man redan har erfarenhet av och tillgång till och sedan gradvis undersöka om de fortfarande är lämpliga för ändamålet.

De flesta alternativ för att utvärdera programvaruutveckling fokuserar på lokal produktivitet, kvalitet och konsekvens i leveransprocessen. När det gäller DevOps finns det väletablerade mätvärden tack vare DORA-programmet (DevOps Research Assessment):

• Frekvens för driftsättning
• Ledtid för förändringar
• Genomsnittlig tid för återhämtning
• Felprocent för förändringar
• Tillförlitlighet

Dessa mått gör det möjligt för oss att fånga effekterna av DevOps-kulturen och -metoderna i kvantitativa termer relaterade till IT-prestanda och -kvalitet. På senare tid har uppmärksamheten flyttats mot att utvärdera hur utvecklare känner för och värdesätter sitt arbete genom att använda ett DevX-centrerat tillvägagångssätt för att mäta framgång.

Mätning av utvecklarnas upplevelse (DevEx)

Att mäta DevEx är dock en skrämmande uppgift, eftersom själva konceptet är mycket brett. Det är bra att börja med ett ramverk som identifierar de tre kärndimensionerna i DevEx: feedbackloopar, kognitiv belastning och flödestillstånd. Dessa dimensioner understryker att DevEx inte bara är en teknisk fråga - verktyg eller arbetsflöden - utan också i första hand handlar om utvecklarnas uppfattningar.

Utvecklare är trots allt människor och det finns inget kvantitativt mått som på ett korrekt sätt kan fånga DevEx. Därför är det viktigt att samla in kvalitativ feedback från utvecklare genom enkäter. Den här typen av feedback beskriver bland annat den upplevda komplexiteten och tillfredsställelsen med att distribuera kod och använda en plattform. Ett exempel:

• Lättanvända verktyg hjälper utvecklare att effektivisera utveckling och driftsättning snabbt och utan krångel.
• Självbetjäningsmöjligheter stöder utvecklarens oberoende och kontroll.
• Högkvalitativ dokumentation gör det möjligt för utvecklare att navigera i komplexa infrastrukturer.
• Plattformen gör det möjligt att samla in olika mätvärden relaterade till DevEx.
• Den snabba installationen av en utvecklingsmiljö främjar produktivitet och kreativitet när det gäller att förverkliga minimalt genomförbara produkter.

I slutändan är platform engineering en insats som går utöver att förbättra produktiviteten och leda till snabbare innovation. Genom att förbättra DevEx gör en plattform i slutändan utvecklare lyckligare, vilket förbättrar kvarhållande, talangförvärv och framgång i att förverkliga affärsmål.

Titta på Nicole Forsgrens föredrag "Varför till och med DevOps gör våra dagar bättre" för mer information.