Platform engineering tehostaa sovelluskehitystä helpottamalla DevOps -tekemistä

DevOps -tekeminen vaatii sovelluskehittäjiltä laajaa ammattiaitoa ja aiheuttaa haasteita asiakasorganisaatiossa

Yksi DevOpsin mantroista on ”you build it (Dev), you run it (Ops)”. Sovelluksen kehittämisen ja operoinnin pitäisi siis tapahtua yhtenä kokonaisuutena. Tässä on toki paljon nyansseja, mutta ideaali tilanteessa tiimi omistaa palvelun läpi sen elinkaaren: kehittää, julkaisee, testaa, operoi, valvoo ja korjaa löydetyt ongelmat. DevOpsin myötä kehityksen palautesykli on nopeampi, uusia ominaisuuksia pystytään julkaisemaan useammin, tuotteen laadun varmennukseen on paremmat edellytykset ja hukkatyö vähenee kommunikaation selkeytyessä. Kaiken kaikkiaan siis fiksu konsepti ja sinällään tavoiteltava tila.

Mutta ei mitään niin hyvää ettei jotain huonoakin. Jos kehitystiimin pitää kyetä tekemään kaikki yllä luetellut toiminnot ja paljon enemmänkin, tiimillä pitää olla erittäin laajat oikeudet organisaation työkaluihin sekä osaaminen niiden hyödyntämiseen. Kontekstina, suuren organisaation IT voi koostua tällaisista palikoista, mistä johtuu, että kehitystiimien osaamisen pitää olla erittäin laaja. Tämän lisäksi tiimit voivat tehdä paljon päällekkäistä työtä, kun jokainen kehitystiimi saattaa tahollaan esimerkiksi automatisoida samoja toisteisia työvaiheita.

Organisaatiosta tulee tätä myötä vääjäämättä tehoton, koska kokonaisuutta ei hallitse kukaan. Karkeasti voisi todeta, että jos jokainen sovelluskehitystiimi hoitaa kaiken itse, muodostuu villi länsi, joka ei todennäköisesti ole niin tietoturvallinen kuin pitäisi, kokonaisuus maksaa luultavasti enemmän kuin olisi tarpeen ja skaalautuvuuteen sekä hallintaan liittyviä ongelmia tulee varmasti vastaan.

Näiden ongelmien torjumiseksi organisaatiot ovat tuoneet takaisin IT-osastot (usein brändättynä DevOps tai Infra -tiimiksi) sekä ”site reliability engineer” roolit. Tämän myötä kehitystiimeillä on taas erillinen taho, jolle tullee selvittää; mitä tarvitsemme, milloin tarvitsemme, miksi tarvitsemme ja kuinka kauaksi aikaa sen tarvitsemme. Näin ollen siiloutuminen ja aikaa vievä tikettirumba ovat palanneet.

TLDR; Ongelma on, että jos jokainen kehitystiimi hoitaa kaikki tarpeensa itse, kehittäjien pitää olla yksisarvisia, jotka osaavat kaiken. Kehittäjillä tulee olla todella paljon aikaa sekä korkeat oikeudet kaikkeen organisaation infraan, mikä puolestaan aiheuttaa tyytymättömyyttä liiketoimintapuolella hallinnan puutteen vuoksi. Toisaalta, jos taas kaikki kehitystyön ulkopuolelle jäävät tehtävät keskitetään erilliselle tiimille, liiketoimintapuolella ollaan tyytyväisiä, mutta kehittäjien tehokkuus ja motivaatio laskevat autonomian puutteen ja byrokratian vuoksi. Tässä kohtaa kuvaan astuu Platform engineering.

Mitä on Platform engineering, ja miten se sopii nykyaikaiseen ohjelmistokehityksen maisemaan?

Platform engineeringin kautta luodaan edellytykset seuraaville elementeille sovelluskehittäjien työn tehostamiseksi:

• Toimivalta kehitystiimille – tiimin tulisi pystyä tekemään kaikki tuotteensa kehitykseen ja ajoon tarvittavat toiminnot itse ja omatoimisesti.
• Toiminnan ohjaus – kehitystiimien toiminnan tulee johtaa kokonaisuuden kannalta järkevään, kustannustehokkaaseen ja tietoturvalliseen ratkaisuun. Tätä varten on luotava valmiit polut, toimintatavat ja mallit, jotka ohjaavat kehitystiimejä. Microsoft viittaa tähän termeillä ”start right- stay right” ja ”paved paths”.
• Aktiivinen tiedonjako – pyörän uudelleen keksiminen tulisi minimoida: kun jokin ongelma on kerran ratkaistu, ratkaisu jaetaan kaikille.
• Automatisointi – pyritään automatisoimaan rutiinitoimintoja.

Ja tätä Platform engineering kaikessa yksinkertaisuudessaan on. Sen avulla toimitetaan yllä olevat ratkaisut yhtenäisen alustan muodossa, ja Platform engineeringin kontekstissa tätä alustaa kutsutaan Internal Development Platformiksi.

Platform engineeringin ydinidea on siis mahdollistaa ”sinä rakennat, sinä ajat” -ajattelutapa, antamalla tiimin operoida tuotettaan koko ohjelmiston elinkaaren ajan. Tähän kuuluu kyky käynnistää resursseja, toteuttaa laadunvarmistusta, CICD:tä, paketinhallintaa ja niin edelleen. Mutta sen sijaan, että tiimi ajaisi mitä tahansa missä tahansa millä tahansa työkaluilla, tarjoamme heille Internal Development Platformin eli IDP:n. IDP tarjoaa käyttäjilleen (sovelluskehittäjille) alustan, jossa he voivat itsenäisesti itsepalveluna hoitaa kaiken tarvittavan.

Platform engineeringin ratkaisemaan haasteeseen ollaankin herätty nyt laajasti, ja esimerkiksi Gartner ennusti vuonna 2023, että ”80% ohjelmistokehitystä tekevistä IT-organisaatioista on perustanut vuoteen 2026 mennessä oman tiimin kehittämään uudelleen käytettäviä palveluita, komponentteja ja työkaluja applikaatioiden toimittamiseen”. Lyhyemmin ilmaistuna, he ovat perustaneet Platform engineering -tiimin.

Internal Development Platform mahdollistaa sovelluskehittäjien toiminnan optimoinnin

Se, mitä IDP kehittäjille mahdollistaa, riippuu täysin organisaatiosta. IDP voi esimerkiksi mahdollistaa käyttäjälle tilapäisen testiympäristön luonnin ajamalla valmiiksi luodun templaten, jolloin alusta hoitaa kaiken resurssien luonnista koodin julkaisuun ja palomuurien konfigurointiin. Kertauksena vielä; Kaiken, mitä IDP mahdollistaa, pitäisi lähtökohtaisesti tapahtua itsepalveluna. Eli nimenomaan kehittäjille itselleen mahdollistetaan asioiden tekeminen. Tikettiportaali ei ole IDP.

Esimerkiksi itselleni toistuva kipupiste, jonka haluaisin automatisoitavan, on uuden jäsenen tuominen tiimiin. Tavallisesti heille täytyy antaa pääsy sinne ja tänne, ja lisäksi heidän täytyy löytää salaisuuksia kuten API-avaimia sun muuta. Koska normaaliin kehitysprojektiin liittyy usein paljon komponentteja, tästä tulee monesti yksinkertainen, mutta aikaa vievä vaihe. Hyvä IDP sen sijaan sallisi minun tehdä tämän yhdellä napin painalluksella.

Liiketoiminnan näkökulmasta IDP:n pitäisi optimoida kehitystiimien toiminta: Minimoidaan aika, minkä tiimi käyttää ydinosaamisensa ulkopuolella olevaan toimintaan sekä erinäisten tukitikettien kirjoittelemiseen.

IDP:n pitää myös optimoida ja yhtenäistää Ops-puolta. IDP:n tulisi asettaa toiminnalle sellaiset raamit, että yrityksen tekninen maisema pysyisi jotenkin hallinnassa, pilvikustannukset on optimoitu ja työkalut on konfiguroitu parhaiden käytäntöjen mukaan.

Suuressa organisaatiossa voi olla myös tarvetta jakaa tietoa. IDP voi esimerkiksi ohjata tiimejä käyttämään olemassa olevia API:ja tai ratkaisuja samoihin asioihin, jolloin voidaan mahdollisesti taas tehostaa toimintoja.

Jotta IDP saataisiin todella toimimaan, se tulee mieltää tuotteena. Tuotteena, jota organisaatiosi kehittäjät käyttävät, ja joidenka kehittäjäkokemus on ensisijainen menestyksen mittari. Mikäli tämä sisäistetään, voimme soveltaa IDP:hen kaikkia tunnettuja strategioita, jotka on osoitettu tuotekehityksessä hyväksi. IDP:tä rakennettaessa meidän täytyy siis tuntea asiakkaamme, kokeilla uusia asioita, kehittää iteratiivisesti ja tarkastella, mikä toimii, pitäen samalla silmällä tuotteen hallinnolliset ja kustannusnäkökulmat.

Mistä lähteä liikkeelle Internal Development Platformin rakentamisessa?

Platform engineering kehittää alustaa, joka koostuu templateista, työkaluista, käytännöistä ja dokumentaatiosta. On tärkeää ymmärtää, että IDP:n kehitys ei ole projekti; Sillä ei ole alku- ja päätöspäivää, eikä selvää päämäärääkään. Koska IDP on kehittäjille tuleva tuote, on loogista aloittaa alustan MVP:llä (minimum viable product) eli TVP:llä (Thinnest viable platform). Aloitamme siis perusteista ja minimi toteutuksesta: Mitkä ovat kehittäjiemme kipupisteet? Mitä toimintoja kaikki tiimit tarvitsevat? Mitkä ovat tarvittavat ominaisuudet ja mitkä ovat ne työkalut, joilla nämä ongelmat ratkotaan tehokkaimmin?

Yksinkertaisimmillaan IDP voi olla repo, missä on dokumentoitu, mitä pilvipalveluja käytämme sekä muutama bicep -tiedosto, jolla palvelut saadaan pyörimään sopivilla konfiguraatioilla. Ja siinä se on, ensimmäinen versiomme IDP:stä.

Tämän jälkeen voimme aloittaa näiden työkalujen käyttöönoton automatisoinnin ja keskittyä rakentamaan uudelleenkäytettäviä ratkaisuja kehitystiimin kohtaamiin ongelmiin tai toistuviin tehtäviin. Näitä voivat olla esimerkiksi DevOps -putkien jakaminen, tuotteiden kontitus ja konttien ajo jaetulla infrastruktuurilla.

Tästä matka jatkuu mukautumalla asiakkaiden tarpeisiin ja lisäämällä alustan maturiteettia. Eräänlainen ”lopputila” voisi olla esimerkiksi tilanne, jossa kehittäjä yhtä nappia painamalla käynnistää sovelluksen testiversion helposti valvottavassa ympäristössä. Tai esimerkiksi tilanne, missä uusi kehittäjä voidaan lisätä tiimiin niin, että hän saa automaattisesti kaikki tarvittavat oikeudet ja roolit työnsä tekemiseen.