Få en unik ögonblicksbild av Platform Engineering idag

Med din hjälp, och hjälp från många andra som arbetar med data, kan vi få en bättre bild av vad människor tycker och vad företag gör. Vi får ett användbart riktmärke, eller en ögonblicksbild, av Platform Engineering i dag.

Jag har en enkät där jag snabbt vill testa fyra hypoteser. Jag vet: ”Ännu en enkät!?” Ja, men den här kan du lära dig mycket av – och den tar mindre än 5 minuter.. 

De fyra hypoteserna är följande: 

• De flesta Internal Developer Platforms är byggda ovanpå Kubernetes och Cloud Native

• De upplevda fördelarna med en plattform skiljer sig åt beroende på vem vi frågar

• Plattformsmisslyckanden följer två tydliga mönster

• Plattformsteam har svårt att balansera bredd och djup

De flesta Internal Developer Platforms är byggda ovanpå Kubernetes och Cloud Native

De upplevda fördelarna med en plattform skiljer sig åt beroende på vem vi frågar

Plattformsmisslyckanden följer två tydliga mönster

Plattformsteam har svårt att balansera bredd och djup

Låt oss ta reda på hur sanna de är. Så här kan du göra:

1. Läs mer om hypoteserna nedan

2. Fundera på vad dina erfarenheter säger dig

3. Gör den snabba enkäten

4. Ta reda på om hypoteserna stämmer när vi delar vad communityn inom Platform Engineering säger   

Läs mer om hypoteserna nedan

Fundera på vad dina erfarenheter säger dig

Gör den snabba enkäten

Ta reda på om hypoteserna stämmer när vi delar vad communityn inom Platform Engineering säger   

När du är redo hittar du länken till enkäten här. Varför inte göra den direkt, så att du inte glömmer? Enkäten stänger fredagen den 14 oktober 2022, så: 

Varför vi gör detta

Jag hjälper just nu TV 2 Danmark och deras nybildade plattformsteam att bygga en Internal Developer Platform. Martin, Staff Engineer i teamet, och jag diskuterade hur vi kunde få bästa möjliga försprång. 

Vi frågade oss: ”Hur har andra gjort, och vad kan vi lära oss av dem?”

Därför har vi pratat med kollegor i organisationer som har kommit längre på sin plattformsresa. Vi har deltagit på konferenser som KubeCon och PlatformCon för inspiration och nätverkande. Vi har läst enorma mängder blogginlägg, erfarenhetsrapporter och annat.

Utifrån all värdefull information och vägledning vi fick lyckades jag formulera de fyra hypoteserna nedan. Nu behöver vi bara bekräfta dem. För det behöver vi data från många människor i olika organisationer.

För det behöver vi dig!

Låt oss tillsammans ta reda på om hypoteserna stämmer. Du kommer förstås att få ta del av resultaten genom olika typer av innehåll som jag producerar och delar.

Redo? Här är hypoteserna:

Hypotes 1: Majoriteten av Internal Developer Platforms byggs ovanpå Kubernetes och Cloud Native

Är det någon som bygger sina IDP:er på något annat än Kubernetes? För många vore det otänkbart, men låt oss ta reda på om de finns.

Hur många är de, och vilka kännetecken har de? Finns de inom Big Tech, där resurserna räcker till för att bygga något som är skräddarsytt för specifika behov? Ses Kubernetes i andra organisationer kanske som ett alltför stort monster, så att de i stället föredrar att bygga något anpassat för ett specifikt användningsfall? Eller kanske enhörningar och startups helt enkelt ser Serverless = Platformless.

Även om undersökningen kanske inte kan besvara just dessa frågor kan vi, med tillräckligt mycket data, kanske koppla nöjdhet till organisationens storlek och plattformteamets kapacitet samt förekomsten av exempelvis Kubernetes.

Det är också intressant att se om fler organisationer använder Kubernetes för att abstrahera bort multi-cloud- och hybridmiljöer än som bygger ovanpå en enda infrastrukturleverantör, till exempel AWS eller on-premise.

Och för att utveckla detta:

• Är Kubernetes verkligen en avgörande del för att uppnå egenskaperna hos en bra plattform, såsom ökad självbetjäning, produktivitet och trivsel?

• Beror införandet av Kubernetes på den underliggande infrastrukturen?

Hypotes 2: De upplevda fördelarna med en plattform beror på vem vi frågar

Om du arbetar i ett plattformteam är det naturligt att tänka att plattformen har en positiv effekt på leveransteamen över hela linjen. Men du är lite partisk.

Utvecklare i leveransteamen kanske inte är lika nöjda med nivån av självbetjäning eller med det stöd och den dokumentation som plattformteamet erbjuder. Eller så upplever de att plattformteamet löser helt fel problem.

Jag vet att det inte är en revolutionerande hypotes. Men ändå: Hur många team tar aktivt kontakt med sina användare och frågar regelbundet om de är nöjda med plattformen och om den löser deras problem?

Vi frågar också dem som överväger att bygga en Internal Developer Platform om deras förväntningar. Vi vill jämföra deras förväntningar med nöjdhetsnivån hos dem som redan har en.

Hypotes 3: Plattformsmisslyckanden följer två tydliga mönster

I ett idealscenario:

Plattformteamet strävar kontinuerligt efter att förstå utvecklarnas behov och utmaningar. Teamet bygger en minimal viable platform från början. Plattformen behandlas som en produkt av teamet, dess användare och finansiärer. Teamet arbetar målmedvetet för att tillfredsställa utvecklarna och är inte rädda för att ändra riktning när det behövs.

Utvecklarna ser sig själva som plattformens kunder, ger feedback och uttrycker sina mål.

Finansiärerna finansierar plattformen utifrån det värde den skapar för teamen.

Låt oss kalla detta idealscenario för ”Den anpassningsbara produkten”.

Men saker är sällan ideala i livet. I den här hypotesen tittar vi därför på två vanliga sätt att misslyckas på – när plattformen inte lever upp till förväntningarna. Vi kallar dem ”legacyfällan” och ”falska starter”.

Legacyfällan

Hela organisationen har höga förväntningar på plattformen, vilket också återspeglas i den initiala nöjdhetsnivån. Men när hypen har lagt sig har plattformsteamet svårt att leverera en plattform som motsvarar dessa förväntningar.

Det kan finnas många förklaringar till detta. Kanske är området för stort eller komplext för att ett enda team ska kunna täcka det. Teammedlemmarna kanske fortfarande är fullt upptagna med support för äldre system som de fortfarande ansvarar för.

De hinner aldrig bygga något som liknar en plattform, så nöjdheten minskar stadigt över tid, både utanför och inom plattformsteamet.

Felstarterna

Här ser vi anti-patterns som plattformen som ett projekt, med tillfälliga plattformsteam och deltidsmedlemmar. De kan bara fokusera på kort sikt och lösa tillfälliga, lokala problem eller problem som bara berör dem själva.

I det här scenariot är de initiala förväntningarna på plattformen låga och fortsätter att minska tills plattformen till slut avvecklas.

För att bygga en organisation för Platform Engineering behöver du stöd från högsta ledningen. Utan aktivt stöd från ledningen finns en hög risk för osäkerhetsundvikande och halvhjärtade felinvesteringar.

Vår princip om att behandla plattformen som en produkt handlar alltså inte enbart om hur plattformsteamet interagerar med sina kunder. Den omfattar också plattformens finansieringsmodell. Plattformen bör finansieras som en produkt utifrån det värde den skapar, inte som ett projekt.

Hypotes 4: Plattformsteam har svårt att balansera bredd och djup

Plattformsteam bör stödja leveransteams förmåga att bygga, leverera och drifta sina applikationer. Men på ett sätt som inte tar bort leveransteamens yttersta ansvar för sin mjukvara, till exempel när det gäller tillförlitlighet och prestanda.

Men var bör plattformsteamet börja? Kan ett team erbjuda bra lösningar inom alla kategorier ovan? Och om ni täcker dem alla, vad behöver ni då kompromissa med när det gäller djup eller kapacitetsbrist?

Därför frågar vi i undersökningen: ”I vilken grad hjälper plattformen leveransteamen att bygga, leverera och drifta sina applikationer?”