Internal Developer Platforms: Lärdomar från paneldiskussionen på DEVOPS CONFERENCE 2023

I april 2023 medverkade bland andra talare som Kelsey Hightower, Nicole Forsgren, Helen Baal och Dom Price.

Men The DEVOPS Conference är inte bara en plats för föredrag. Det är också en community för kunskapsdelning. En viktig del av evenemanget var den interaktiva delen med samtal vid brasan, öppna diskussioner och livedemonstrationer.

Jag hade förmånen att moderera en panel om DevOps och platform engineering. Hur stöder utvecklingen av Internal Developer Platforms (IDP:er) DevOps? Vilka är fördelarna och utmaningarna med att införa dem? Hur påverkar de kultur och arbetssätt? Det här var de viktigaste frågorna som paneldeltagarna diskuterade:

Bjørn Hald Sørensen (Head of Technology på Lunar)

Tuomas Leppilampi (DevOps-konsult på Eficode)

Dan Grøndahl Glavind (DevOps-konsult på Eficode)

Deltagarna medverkade aktivt i frågestunderna. Vi genomförde också en enkät för att förstå deras bakgrund – mer än 50 % av publiken var obekanta med IDP:er, omkring 30 % hade åtminstone börjat arbeta med dem och resten övervägde att bygga en.

Här är en sammanfattning av paneldiskussionen, uppdelad efter de huvudsakliga teman som framträdde.

Paneldiskussion om DevOps och platform engineering

Behövs IDP:er verkligen?

Mario: Varför behövs dessa Internal Developer Platforms över huvud taget? Eller är det bara en trend vi följer nu, precis som Kubernetes var för några år sedan? Vad tänker ni om det?

Bjorn: Jag tror att det främst handlar om problemet och utvecklingen av hur vi bedriver mjukvaruutveckling. IDP:er, och plattformar generellt, är något som utvecklas. Något som följer med den kognitiva belastning vi lägger på utvecklare.

Hur kan vi organisera oss för att arbeta effektivare? Jag tror att platform engineering definitivt är en av de saker som just nu kan skapa stort värde för utvecklare.

Tuomas: Jag tror att det är en stor konkurrensfördel att kunna säga till dina utvecklare: ”Ni kan faktiskt fokusera på att koda, ni kan faktiskt fokusera på problemlösning och på att göra det ni verkligen tycker om, i stället för att till exempel hantera Jenkins.”

Dan: Jag tycker att vi med DevOps har haft inställningen ”You build it, you run it”, men vad innebär det egentligen? Handlade det om hela stacken, från våra applikationer ner till hårdvaran? Jag tror att det är där komplexiteten uppstår, och att det är ett av löftena med platform engineering: ”Okej, vi behöver inte känna till all den här komplexiteten på djupet.”

Tekniska och kulturella aspekter

Mario: Om man tittar på alla blogginlägg och allt material som finns om IDP:er, får jag känslan av att den tekniska aspekten dominerar. Men handlar det inte egentligen mer om att förbättra Developer Experience? Hur ser ni på potentialen i det tekniska och i Developer Experience? Är det något som är specifikt för IDP:er, eller vad är den viktigaste aspekten här?

Tuomas: Ur ett nyttoperspektiv handlar Developer Experience om att behålla bra utvecklare. Du behåller medarbetarna, och det är en väldigt viktig del av trenden inom platform engineering.

Ur mitt perspektiv handlar det egentligen om DevOps. Det handlar om den typ av DevOps och agilitet som vi försöker uppnå som kultur. Platform engineering och Internal Developer Platforms är bara ett sätt att uppnå och upprätthålla den typen av kultur.

Bjorn: Att under åren förvänta sig att många människor ska kunna mer, till exempel i autonoma team, innebär att många kommer att bli utbrända om de förväntas känna till allt som kan gå fel i komplexa distribuerade system. Det är inte syftet. Det är inte det som kommer att göra våra utvecklare glada. Det är inte det som får dem att vilja skapa värde för verksamheten.

För mig är en IDP inte en enskild sak. Det är inte en plattform. Det är inte en teknisk lösning som du tar från hyllan och gör tillgänglig. Det är snarare ett helhetsperspektiv på allt som gör det möjligt för våra utvecklare att göra det de behöver göra.

Dan: Jag tror att det är en mental modell för att hantera vissa förmågor som vi vill förbättra, både för oss själva och andra utvecklare. Det är något mer holistiskt. Det handlar om hur vi kan skapa förmågor och kompetenser som gör att människor både trivs och är produktiva.

Överhead och tumregel

Mario: En IDP kan alltså skapa mycket värde. Men om den tillhandahåller allt, blir den inte då svår att underhålla och hantera? Och en relaterad fråga: Finns det någon tumregel för hur många utvecklare ett företag vanligtvis bör ha för att det ska vara motiverat att bygga en IDP?

Tuomas: Det kan bara vara en samling dokument eller instruktioner om beprövade metoder. Så det spelar ingen roll om du har fem eller två utvecklare – det bygger upp en mental bild av att skapa en plattform att stå på när du börjar utveckla något nytt, som en funktion, applikation eller tjänst. När du har det blir det enklare för andra att komma in.

Dan: Det var ungefär den frågan jag hade. I vilken utsträckning du som utvecklare får stöd genom funktioner i build-output, CI/CD-verktyg, kanske säkerhet i leveranskedjan och sådana saker, och sedan den förändring vi pratar om kring vilken typ av driftsättningsstrategi.

Och vad som kan täckas när det gäller observability och övervakning, sådana saker. Det kan vara möjligt att täcka alla dessa områden på en gång. Och om du tror det kanske ni helt enkelt växer till fler plattformsteam som samarbetar kring en plattform.

Bjorn: Men det vi gjorde inledningsvis var egentligen precis det du sa – guider för hur man gör saker, hur man sätter upp en ny tjänst, hur man arbetar effektivt med mjukvara, utan att bara börja med grunderna. Och vi byggde långsamt vidare på det. Vid någon punkt växte vi ur det. Det var lite som med DevOps – det växte bortom teamen själva när vi skulle hitta ett bra sätt att arbeta.

Så vi skapade ytterligare två kärnteam för att fundera lite mer på hur vi kan optimera dessa arbetsflöden, vad vi faktiskt kan automatisera och hur vi kan hjälpa utvecklare i deras dagliga arbete. Det har sedan vuxit under åren till där vi är nu, med tre plattformsteam som tillhandahåller Lunars utvecklingsplattform. Vi stöttar olika användargrupper.

Så du bygger upp det från liten skala, eftersom det är enklare att definiera vilket värde du kan skapa när du har ett problem och kan säga: ”Vi vill att ett team löser det här problemet, och vi förstår problemets omfattning.” Det är värdet. Sedan behöver vi tänka på att göra det till en plattform, eftersom vi kan skapa det här lilla verktyget och sedan ett annat, men med tiden behöver vi också se helheten och förstå att utvecklare vet vart de ska vända sig för information.

På Lunar har vi ett förhållande på en till tio, alltså ungefär tio utvecklare per plattformsingenjör, om man vill förenkla det. Olika företag har olika förhållanden, men det beror på hur väl er infrastruktur och era utvecklingsmiljöer är samordnade, samt er teknikhistorik.

Kognitiv belastning

Mario: Hur mycket kognitiv belastning är okej för en utvecklare? En aspekt är att ha en enda plats där utvecklare kan göra det de faktiskt arbetar med. Men hanterar det all kognitiv belastning? Eller handlar det också om automatisering? Hur hänger de två delarna ihop?

Tuomas: Jag tror att det är väldigt personligt, från en junior utvecklare som omarbetar arkitektur och refaktorerar till de så kallade ”UNIX-killarna” som utför mycket specialiserat arbete. Det beror mycket på var ditt intresse ligger. Vilken typ av utvecklare är du?

Bjorn: Jag tror att det är personligt. Definitivt. Standardsvaret är ”det beror på”, men du måste prata med dina utvecklare. Fråga dem: ”Vilka är era problem? Var känner ni att ni slösar tid? Var försvinner ert engagemang?” Därför att ni egentligen inte tycker om att arbeta med det. Det är där gränsen för den kognitiva belastningen går.

Det är som 80-procentsregeln: om du tillhandahåller funktioner som täcker 80 procent av tekniken, till exempel den organisatoriska delen, kanske vi inte lägger tiden på rätt saker.

Om du är den enda som minskar den kognitiva belastningen för ett team, men skulle kunna göra det för alla eftersom det finns större problem att lösa, bör du alltid arbeta med sådant som hjälper fler. Och återigen handlar det om att avgöra hur mycket belastning du kan lägga på teamet.

Dan: Inom teorin om kognitiv belastning finns det olika typer av belastning. Det finns inneboende kognitiv belastning, där själva uppgiften i sig är komplex. Men det vi egentligen vill undvika är extern kognitiv belastning. Något som bara läggs på dig och som du inte bryr dig om över huvud taget, som monotont arbete.

Jag tror att svaret kanske är att om du uppfinner hjulet på nytt gång på gång, och du tror att det är något som någon skulle kunna lösa till nytta för alla, kan det vara ett tecken på att fundera över om det är rimligt att hjälpa fler team. Men det finns ingen exakt siffra för när du ska investera i ett team som löser gemensamma problem.

Platform Engineering och DevOps

Mario: Vad är kopplingen mellan det här plattformsarbetet och DevOps? Hur många team bör det finnas? Eller, för att vara mer provocerande, skulle jag till och med säga att ett plattformsteam är ett anti-DevOps-mönster.

Tuomas: Det finns ungefär tre olika områden. Det ena är utvecklarna som i praktiken driver det de bygger, så att de har bra observability, möjlighet att göra återställningar och kontroll över driften inom de områden som är relevanta för dem. Sedan finns plattformsteamen som faktiskt utvecklar plattformen, konfigurerar den, lyssnar på utvecklarna och lyssnar på den tredje delen, som jag tycker bör vara managed services.

Sedan har vi plattformsteamet som fokuserar på att lyssna på utvecklarna och få ut det bästa av konfigurationen. Och utvecklarna har fortfarande tillräcklig åtkomst till driften, runtime-miljön och allt annat så att de kan köra det de har byggt.

Bjorn: Det är precis där Platform Engineering kommer in i bilden. Du vill säkerställa att du inte tar bort ansvaret från dina utvecklare – du vill ge dem rätt förutsättningar.

Den främsta skillnaden mellan det vi hade före DevOps och det vi har nu med Platform Engineering handlar om mindset, attraktiva interna produkter och förståelsen för att vi finns här för att stötta utvecklarna.

Dan: Om du tar boken Team Topologies (som är en riktigt bra bok om du inte har läst den) handlar den om interaktioner mellan team. När du tittar på plattformsteamet bör det tillhandahålla plattformen som en tjänst eller produkt. Men samarbetet är egentligen den mest intressanta delen. Hur tar vi reda på vad vi ska göra nu och härnäst?

En utvecklarportals roll

Mario: Vi har pratat om att IDP:er eller plattformar har en gemensam ingång där utvecklare kan göra det mesta som rör mjukvaruutvecklingens livscykel. En sådan är utvecklarportalen. Och när vi tittar på IDP-landskapet ser vi att Backstage har blivit de facto-standard. Är Backstage lösningen på allt man behöver när det gäller plattformsanvändning för olika intressenter? Hur ser du på det?

Bjorn: Vi hade interna diskussioner om att vi behövde en plats dit människor kunde gå och få en samlad vy – en ingång till all annan information. Därför bestämde vi tidigt att vi ville ha Backstage på plats, för att verkligen skapa denna centrala informationspunkt. Men det betyder inte att det är plattformens kärna. Det är snarare ingången.

Backstage hjälper oss att skapa en plats där vi kan gå till Backstage och börja med en sökning. Om du inte får svar kan du gå till Slack och ställa frågan till teamet. Men det finns många delar av en plattform som inte är Backstage, till exempel CLI-verktyg. Allt detta är fortfarande utspritt, men du kan ändå hitta information om det i Backstage.

Tuomas: Jag tycker att Backstage är ett bra sätt att börja resan mot att skapa en samlad vy. Men när du kommer längre kanske du inser att kärnan snarare är Continuous Delivery-plattformen, eftersom alla kan se hur vi levererar värde till kunden – och det kan bli kärnan. I början kanske du däremot trodde att det var mallarna du skulle börja med.

Dan: När jag först tänkte på Backstage blev jag genast förtjust i det, eftersom det verkade lösa många av problemen kring mjukvarukataloger och ägarskap. Det hade också en slags systemmodell, vilket jag tycker är väldigt bra. Och naturligtvis mallfunktionerna, plugin-programmen och så vidare.

Bjorn: Vi hade en tydlig bild av att utvecklare har störst problem när de ska skapa nya tjänster. Vi hade ett dokument i Confluence: om du behöver de här platserna, klicka i de här rutorna, kom ihåg att ange rätt namn och allt sådant. Vi var säkra på att detta skulle vara det som alla utvecklare skulle älska.

Vi frågade på Slack: ”Vad vill ni att vi bygger först?” Och det visade sig att mjukvarukatalogen fick flest tummar upp. Den låg långt före nästa alternativ. För det många utvecklare egentligen vill ha är överblick över ägarskap: Vad har vi? Och vem kan jag fråga? Det var just den enkla saken vi ville lösa.

Att mäta plattformens nytta

Mario: Om plattformen används och är hållbar kommer nästa fråga: hur kopplar man resultaten från Platform Engineering till affärsresultaten? Räcker det, eller går det att ha någon form av mätetal? Är DORA metrics också användbara i det här sammanhanget? Och hur kan man säga om denna plattformssatsning har skapat affärsvärde eller inte?

Dan: Om vi som plattformsteam mäts utifrån hur vi möjliggör för andra team, är mätetal som genomströmning, stabilitet och tillförlitlighet verkligen viktiga för oss. Och kanske bör vi också fokusera på hur vi kan koppla dem till de applikationer som våra utvecklare ger sina användare tillgång till.

Prestation, kommunikation och samarbete samt effektivitet i flödet. Kanske täcks en del av effektiviteten av DORA. Men det handlar om mer än bara konkreta, kvantitativa mått. Det finns också kvalitativa och upplevda aspekter.

Bjorn: Det affärsvärde som en plattform kan ge bör förhoppningsvis identifieras genom de problem den behöver lösa. Jag tror att det är svårt att hitta KPI:er som varje månad bekräftar att det fortfarande är rimligt att ha ett plattformsteam.

Tuomas: DORA metrics är ett alternativ. Jag har dock inte sett dem användas särskilt mycket i praktiken. Och jag tror att det femte mått som de har övervägt är tillförlitlighet, vilket på något sätt hänger ihop med användarupplevelsen. SLI:er, SLO:er och runtime-delen. Upplevelsen och funktionaliteten i runtime-miljön.

Är Platform Engineering för alla?

Mario: Gartner säger nu att IDP:er är nödvändiga för att skala DevOps-insatser. Hur ser du då på Platform Engineering i förhållande till DevOps maturity model? Är det något enbart för högpresterande organisationer, eller bör det vara för alla företag? Hur ser det ut? Vad har vi, säg, om fem år? Är det fortfarande en plattform? Eller är det något annat? Finns DevOps fortfarande kvar eller inte?

Tuomas: Jag tror att det är helt avgörande för skalning att vi kan abstrahera bort vissa saker, eftersom vi då verkligen kan koncentrera oss på affärsresultaten. Hur förändrar vi faktiskt slutanvändarens vardag?

Jag känner mig väldigt lyckligt lottad som arbetar på ett kontor där det finns många designers, och vi äter lunch och tar kaffe tillsammans. Jag har snappat upp mycket design thinking och metoder inom tjänstedesign som har hjälpt mig mycket att upptäcka de problem som ett företag eller en organisation kan ha.

Bjorn: Jag tror i alla fall att det kommer att finnas något, eftersom de underliggande problemen inte försvinner. Men de kan visa sig kräva andra abstraktioner.

Vi kommer helt enkelt att fortsätta titta på nästa stora problem att lösa, inte nästa lösning eller nästa trend. Sedan kan vi utforska lösningsutrymmet och fråga: ”Vad finns här som kan hjälpa oss att lösa det här problemet? Är det ett plattformsteam? Är det i stället ett produkttänkande eller ett verktyg? Är det något annat?” Men vi måste börja med att identifiera nästa problem.

Dan: Hur mycket tid lägger du på att ta reda på vilka problem du har, och hur samarbetar du för att omvandla dem till konkreta lösningar? Det är den intressanta delen för mig.

Avslutning

Panelen hade en mycket intressant diskussion som lyfte många olika teman inom DevOps och Platform Engineering. Det blev tydligt att en plattform inte bara handlar om teknik, utan också om att stötta utvecklare och effektivisera processer.

Platform Engineering bör ha tydliga mål, fokusera på Developer Experience och främja en samarbetskultur mellan team.

Varje företag är unikt. Därför bör arbetet med Platform Engineering rikta in sig på problemområden och efterfråga kontinuerlig feedback från flera intressenter – inte bara utvecklare, utan även produkt- och affärsansvariga.