Modern Platform Engineering i en AI-driven era för mjukvaruutveckling

I den här första delen utforskar vi hur konceptet Platform Engineering har utvecklats ur välkända DevOps-metoder och vad det innebär för design, implementering och tankesätt. På vägen lyfter vi fram de viktigaste trenderna och drivkrafterna som formar dagens landskap för Platform Engineering.

Utvecklingen av Platform Engineering: viktiga trender och drivkrafter

Kan Platform Engineering moderniseras?

Ända sedan storskalig databehandling började användas har utvecklingstakten bara ökat, och de senaste åren är inget undantag. I dag möter företag hårdare konkurrens, vilket ökar pressen på organisationer att lyckas. För att frigöra mer tid för kärnkompetenser och kreativt tänkande kan Platform Engineering vara nyckeln till din organisations framgång.

Under många år har friheten att välja verktyg och det som fungerar bäst för dig varit ett viktigt budskap för att hålla utvecklare nöjda och fokuserade. Flexibilitet i hur team eller arbetsgrupper sätts samman minskar den kognitiva belastningen när utvecklare introduceras till ett potentiellt nytt affärsområde. Efter en mycket utforskande period har vi sett en omfattande konsolidering av verktyg och metoder, som fortfarande ger enskilda team tillräckligt utrymme att anpassa dem efter sina behov.

Närmare titt: DevOps och Platform Engineering i förändring

När vi ser tillbaka på de stora förändringarna i vår bransch kan vi konstatera att DevOps-metoder, som för utveckling och drift närmare varandra, ofta har lett till kortare time to market – men det kan ha ett pris, vilket vi har sett genom åren. Priset är inte alltid ekonomiskt, utan handlar ofta om utvecklarnas kognitiva kapacitet. När vi introduceras till ett nytt arbetsområde minskar hastigheten, den kognitiva kapaciteten och agiliteten naturligt, eftersom ny kunskap måste tas in och bearbetas.

Även om ”You build it, you run it” är viktigt för teamens ägarskap och därmed känsla av angelägenhet, har många utvecklare behövt lära sig driftmetoder som de aldrig tidigare kommit i kontakt med. Behovet uppstod eftersom driftkompetensen inte räckte till för att skala i takt med antalet team som behövde den. Att lämna de köade arbetsuppgifterna i en traditionell driftorganisation krävde ett betydande skifte i tankesätt, och i många fall har vi sett att inte alla organisationer har satsat på det. Detta skifte i tankesätt var, och är fortfarande, avgörande för att undvika en återgång till silor – och i vissa fall skyttegravskrig – som försämrade konkurrenskraften för alla i organisationen. Baksidan av DevOps-medaljen är att utvecklare har behövt bygga upp kunskap om grundläggande molnnätverk, hur Kubernetes konfigureras och content delivery networks. Dessa kunskapsområden kräver specialistkompetens för att hanteras väl ur drift-, flexibilitets- och ekonomiperspektiv.

För att utvecklare ska kunna fokusera sin kunskap på det affärsområde de verkar inom, bygga välarkitekturerad kod och behålla sin kreativa frihet har Platform Engineering blivit det ledande tillvägagångssättet. Med stort fokus på utvecklarnas behov av att skriva, bygga, testa, driftsätta och drifta mjukvara har plattformar byggts för att minska den kognitiva belastningen. Det innebär att en del av friheten återfås genom ett enhetligt sätt att arbeta, vilket inte är negativt när sidoeffekterna av Platform Engineering blir viktiga i en värld med ökande krav på styrning och regelefterlevnad.

Vilka är de viktigaste drivkrafterna för modernisering inom Platform Engineering?

Vi har sett många organisationer migrera till molnet, men också en förflyttning mot ett mer Cloud Native-förhållningssätt. Det innebär inte nödvändigtvis att alla går till molnet, även om många har gjort det, utan handlar snarare om ett tankesätt där man använder tekniker som varit centrala byggstenar i de moln vi ser i dag. Det kan omfatta många arkitekturmönster inom mjukvaruutveckling, men det råder ingen tvekan om att virtualisering, containerisering och Kubernetes har varit de stora aktörerna i Cloud Native-resan. Att bygga mindre, fokuserade tjänster som är enklare att felsöka, skala och underhålla är en av nycklarna till framgång. Det står i stark kontrast till tiden då man packade in så mycket som möjligt i en enda tjänst och pressade ut den sista kapaciteten ur serverns CPU och minne.

I dag driftar vi hundratals, tusentals eller ännu fler tjänster i våra organisationer, och vi förlitar oss på plattformen för att packa dessa tjänster effektivt på de faktiska servrarna och få ut mesta möjliga av våra ekonomiska investeringar.

Genom att ta till oss resan mot Platform Engineering kan vi börja optimera användningen av de resurser vi har tillgång till, oavsett om det handlar om servrar on-premise eller kluster som startas hos den molnleverantör du väljer. Om vi inte tar till oss resan mot Platform Engineering kan vi naturligtvis drifta våra system, men då krävs specialistkunskap för att få allt att fungera lönsamt utan att spendera alla pengar på många enskilda kluster och upprepade stödtjänster.

Genom att analysera dataströmmarna från plattformarna kan vi vidta genomtänkta åtgärder för att förbättra och utöka de funktioner som erbjuds mjukvaruutvecklarna som använder plattformen. Detta är en viktig grundsten som har fått mer uppmärksamhet de senaste åren. Allt fler organisationer har insett att plattformen byggs för utvecklare och därför bör stödja deras behov. Vi rör oss alltmer mot att driva plattformar som produkter. Men vi är inte där ännu, eftersom många fortfarande ser Platform Engineering som en teknisk utmaning, medan hela konceptet är en socioteknisk övning. Det är viktigt att samla in användarnas återkoppling både kvantitativt och kvalitativt för att säkerställa att vi bygger rätt saker, att de används och att användarna trivs med att arbeta med plattformen.

Sist men inte minst har branschen sett en ökande efterfrågan på att köra AI-arbetslaster på plattformar. Det har väckt många diskussioner, både för oss som bygger plattformar och arbetar med säkerhet, och för stora hårdvaruföretag som NVIDIA. Hur bygger vi en plattform som kan utnyttja hårdvarans potential och få den att fungera på ett sätt som passar den Cloud Native-baserade modellen med delad hosting?

Från de första stegen, där hårdvara konfigurerades direkt för enskilda arbetslaster, ser vi nu allt fler steg mot en modell där hårdvaran delas mellan flera arbetslaster. Detta har varit möjligt ett tag, men vi ser nu standarder växa fram i branschen som hjälper oss att driva detta långsiktigt.