Platform Ops tukee pilvialustan skaalausta

Konsulttiyhtiö Gartner alkoi käyttää Platform Ops -termiä jo viime vuosikymmenellä, mutta asiasta puhuminen on yleistynyt hiljattain. Mitä tämä uusi laji tuo lisää DevOpsin, DevSecOpsin, MLOpsin, DataOpsin jne. oheen, vai onko kyse silkasta sumutuksesta?

Platform Opsin perusajatus on simppeli: Jonkun on tehtävä töitä sen eteen, että organisaation IT-alusta on skaalautuvasti ja helposti kaikkien käytössä. Toisesta näkökulmasta tarkasteltuna: Platform Opsin tehtävänä on huolehtia siitä, että DevOpsia käyttävät tiimit voivat keskittyä palveluidensa kehittämiseen, ei alustakysymyksiin. Kyse on siis vakiintuneiden toimintatapojen skaalaamisesta: Platform Opsia tekevän alustatiimin tehtävänä on tuotteistaa ja rakenteellistaa niitä välineitä, joita palvelukohtaiset tiimit tuottavat ja tarvitsevat.

Eikö pilvi ratkaise tämän ongelman?

Idealistisesti ajatellen PaaS-palvelut huolehtivat monista sellaisista asioista, joihin aiemmin olisi tarvittu jonkinlaista alustan hallintaa. Käytännössä on kuitenkin osoittautunut, että pilvikin tarvitsee huoltajansa: Mitä laajemmaksi organisaation sovellusportfolio kasvaa, sitä enemmän yksittäiset sovellustiimit takeltelevat alustateknologian kanssa, ja sitä enemmän ylläpitotyön aikaa kuluu sovellusten välisten eroavaisuuksien ymmärtämiseen ja hallintaan. Tietyllä tapaa pilvi lisää kunnollisen alustaoperoinnin tarvetta, sillä kun resursseja on helppo luoda, niitä on myös helpompi luoda ja käyttää väärin.

Gartnerin alustafilosofiaa ei tarvitse nielaista sellaisenaan ja hypesanat voi jättää kokonaan käyttämättä, mutta käytännön kokemus on osoittanut, että organisaation pilvikäytön laajentuessa alustavakioinnin laiminlyönti käy kovin kalliiksi. Kasvava hinta näkyy myös esimerkiksi Azuren käyttökuluissa, mutta ennen muuta kehitys- ja koordinointikustannuksissa. Näiltä osin ehkä onkin reilua sanoa, että alustaoperointi on kuin mikä tahansa laatutekijä: helppo ja halpa juttu, niin kauan kun olet sitkeästi ollut valmis maksamaan sen kustannukset koko pilvimatkan ajan.

Tarkoittaako tämä sitä, että IT-organisaatioon pitäisi lisätä uusi tiimi pohtimaan alustakysymyksiä ja väkertämään työkaluja? Entä miten tämä koko soppa suhtautuu hallintamalleja (governance) ja tietoturvaa tekeviin tiimeihin? Hyviä kysymyksiä, ja ideaalivastaukset varmasti riippuvat organisaatiosta. Mutta Platform Opsin kaltaisia taikasanoja tärkeämpää on miettiä, miten itse tehtävät tulevat hoidetuksi.

Alustaoperoinnin ydin on pilviresurssien hallinnassa

Alustan monipuolisuudesta ja vaatimuksista riippuen, sen operointi voi tarkoittaa hyvin monenlaisia asioita. Perustavoite on kuitenkin helposti sanallistettavissa: Alustatiimin tavoitteena on tehdä organisaation pilvipalveluiden käytöstä sujuvampaa tarjoamalla sovellustiimeille sellainen välineistö, että organisaation valitsema oikea tapa on samalla myös helpoin tapa.

Hallintanörtin unelma: Rattaat huolehtivat toisistaan.

Tämä määritelmä ei siirrä vastuuta tietoturvasta, verkoista, valvonnasta, kustannusseurannasta tai mistään muustakaan hallintasiilosta, mutta luo ikään kuin uuden yhteistyösuhteen: alustatiimi toimii yksittäisten alueiden käyttöpolitiikan äänitorvena ja käyttöönottokanavana. Mitä tämä alustatiimin rooli voisi sitten käytännössä olla?

Tärkein alustatiimin tehtävä on käytännössä varmastikin infrastructure as code -praktiikan tukeminen. IaC:ssä on kyse siitä, että pilviresurssit synnytetään aina vakioiduilla skripteillä – esimerkiksi ARM-, Bicep- tai Terraform-malleilla – jotka konfiguroivat pilvipalvelut oikein. Alue on äärimmäisen mutkikas sekä teknisesti että konseptuaalisesti, mutta alusta-ajatus on selkeä: Mitä selkeämmät yleiset periaatteet organisaation tietokantoja, laskentaympäristöjä ja muita pilviresursseja koskevat, sitä helpompi projektitiimien on työnsä tehdä.

Ideaalitilanteessa projektiryhmä – sisäinen tai toimittajavetoinen – saa käyttöönsä jatkuvasti päivittyvän mallikirjaston, joka suoraan näyttää oikeat tavat käyttää Azuren kaltaista ympäristöä juuri tässä organisaatiossa. Valmis mallikirjasto vakioi esimerkiksi nimeämiskäytännöt, palvelinkeskusvalinnat, resurssien metatiedot (esim. vastuuhenkilön nimi), käytettävissä olevat kapasiteettivalinnat ja niin edelleen.

Mallikirjastoa ei välttämättä tarvitse liittää policy-ajatteluun: Ehkäpä kaikista resurssien asetuksista ei tarvitse päättää pakottavasti, vaan poikkeamat ketteryyden nimissä ovat aivan hyväksyttäviä. Mallikirjasto tekee oikeasta toteutuksesta helpoimman vaihtoehdon, ja tämä riittää useimmiten vakioimaan valtaosan pilvipalveluiden käytöstä.

Alustan rakennuspalikoita on monenlaisia

Platform Ops -rooli ei hoidu pelkästään sillä, että pilviresurssien luonti tehdään koodina. Hyvä hallintakäytäntö vaatii toimiakseen myös muuta työkalustoa.

Hyvä esimerkki on sovellusten toiminnan valvonta. Mitkä ovat organisaation parhaat käytännöt valvontaan? Mitä pidetään mitenkin vakavana ongelmatilanteena? Miten eri vakavuuksisista ongelmatilanteista raportoidaan? Muodolliset palvelukuvaukset ja RACI-matriisit toimivat sopimusvaiheessa, mutta toteutusvaiheen tuottavuudessa auttavat monesti enemmän esimerkiksi vakioidut valmispalikat, koodikirjastot ja rajapintapalvelut (”Lähetä tähän rajapintaan ne virheilmoitukset, jotka haluat nostaa vastuutiimin DevOps-boardille”).

Vastaavia esimerkkejä löytyy vaikkapa varmuuskopiointikäytäntöjen, versiointimallien, salaisuuksien hallinnan ja käyttäjätunnistuksen ympäriltä. Parhaita käytäntöjä on tuettava selkeällä dokumentaatiolla ja viestinnällä: osassa asioista kyse on vain kevyistä suosituksista, osassa taas pakottavista käytännöistä. Näiden erottaminen toisistaan ja järjestyksen ylläpitäminen vaatii alustatiimiltä kyvykkyyttä projektien aikataulupaineiden, IT:n hallintatarpeiden ja kehittäjien toiveiden ristitulessa.

Kuvassa on joitain ajatuksia Platform Ops -tiimin kohtaamista haasteista. Pyramidissa on hyvä lähteä pohjalta, mutta kaiken ei tarvitse olla kunnossa, jotta voisi edetä ylöspäin. Lohtusanat: Kenelläkään kaikki ei ole kunnossa.

Klassisen tietohallintokulttuurin mukainen vaativa ote ei riitä hyvän platform-mallin toteutukseen, vaan toimivalla alustatiimillä on oltava myös psykologista silmää siinä, miten tuottavuuskulttuuria todella kehitetään: yhteistyössä ja askel kerrallaan. Monet alustavaatimukset – esimerkiksi suorituskyvyn mitattavuuden tai dokumentaatiokäytäntöjen osalta – ovat luonteeltaan vaikeasti määriteltäviä, ja sopivan menetelmän etsiminen on jatkuva prosessi, jossa tuotteiden ja projektien muuttuminen vanhentaa aina osan jo tehdystä dokumentaatiosta.

Kuka vastaa alustasta?

Platform Ops on selvästi IT-ammattilaisen tehtävä. Roolin ytimessä on liiketoiminnan vaatiman ketteryyden yhdistäminen tuottavuusodotuksiin ja kypsään elinkaariajatteluun, ja työ vaatii laajaa näkemystä niin prosesseista, teknologiasta, työkaluista kuin inhimillisestäkin työstä. Useimmissa organisaatioissa tämä toiminto kuuluu selkeästi IT-osastolle, vaikka itse kehitysprojekteja tehtäisiinkin liiketoimintayksiköissä.

Onko tekijät sitten pakko löytää sisältä, vai voiko Platform Opsin ulkoistaa? Varsinkin monimutkaisemmissa pilviskenaarioissa voi olla vaikeaa ylläpitää talon sisällä osaamista kaikesta tarvittavasta teknologiasta, jos omaa kehitystoimintaa ei ole riittävän paljon. Ulkoistaminen varmasti onnistuu, mutta kuten kaikessa hallintatyössä, konsulttien käytön riskit kannattaa huomioida.

Yrityksen liiketoiminta-alustan hallinta vaatii laajaa koordinaatiotyötä yli lukuisten projektien ja yksiköiden, ja tällaisessa roolissa omalle henkilökunnalle kehittyvä yrityksen prioriteettien, liiketoimintatarpeiden ja työtapojen laaja tuntemus auttaa. Puolipäiväisen konsultinretkun teknisempi ote voi olla erittäin arvokas kehitysresurssi, mutta omistajuuden ulkoistaminen ontuu tässä aivan kuin muussakin hallintatyössä. Se, että miten organisaation oma Platform Ops -toiminta sitten kannattaa pystyttää ja mihin kannattaa panostaa ensin, voikin olla oikein mainio ulkoisen toimijan kanssa sparrattava kysymys.

Haluatko jutella lisää pilviympäristöjesi hallinnasta? Kaipaatko apua Platform Ops -praktiikkasi pystyttämiseen? Ota yhteyttä!