Joudutko kotonasi anomaan kirjeitse talonmiehen apua tuulettamiseen tai roskien vientiin? Et tietenkään, sehän olisi täysin hölmöä. Töissä joudun kuitenkin kirjoittamaan tällaisia anomuksia jatkuvasti.
Ketterästä kehittämisestä on tullut arkipäivää. Ketteryydestä puhutaan kuitenkin kapeakatseisesti, keskittyen vain ohjelmistokehittämisen menetelmiin. ”Meillä on itsenäinen, ketterä kehitystiimi!”, tilaaja kerskuu hankinnastaan. Samalla hän kuitenkin vaatii tiimiä hankkimaan palvelimet kauan sitten valitulta, keskitetyltä käyttöpalvelukumppanilta.
Talonmies ei tunne asukkaiden tarpeita
Yksityisen ja julkisen sektorin ohjelmistoprojekteissa kehittäjät ja ylläpitäjät ovat pitkään kamppailleet kankeita yhteistyömalleja vastaan.
Vanhanaikainen käyttöpalvelutoimittaja vastaa kaikista infraan liittyvistä muutoksista, niin palvelimien, tietokantojen kuin verkkojenkin osalta. Kehitystiimi ei saa tehdä muutoksia itse palvelimille. Käyttöpalvelutoimittaja ottaa muutospyynnöt vastaan vain käsin tarkasti muotoilluilla Word-lomakkeilla.
Ensin Word-lomakkeet menevät muutosjonoon odottamaan. Sieltä lomakkeita käsittelee harmaa massa kaukaisia ylläpitäjiä, jotka eivät osallistu projekteihin täysiverisinä tiiminjäseninä. Tällainen geneerinen ylläpitäjä ei tunne palvelun käyttötarkoitusta tai historiaa. Lomakkeesta huolimatta tiedot saattavat olla puutteellisia tai väärin täytettyjä, jolloin ylläpitäjä joutuu pyytämään tarkennuksia.
Sähköposti ja lomakkeet pakottavat molemmat osapuolet manuaaliseen apinan hommaan. Suurin osa palvelupyynnöistä on yksinkertaisia tehtäviä ja täysin automatisoitavissa. “Saisimmeko kolme uutta palvelinta”, ”Voisitteko avata palomuuriportin”, ”Tämä reititysmuutos olisi kiva”. Yksinkertaisetkin tehtävät kasautuvat infratoimittajan jonoon seisomaan, kalenteriaika juoksee ja kehitystiimi odottaa.
Kun ulkopuolinen ylläpitäjä ei ymmärrä projektin tarpeita, eikä projektitiimi näe suoraan infran nykykonfiguraatiota, palvelutoimittajan ja kehitystiimin välille syntyy muuri.
Kehitystiimit monesti kiertävät kankeutta ostamalla kehitys- ja testiympäristöt pilvestä omaan hallintaan. Tämä sujuvoittaa kehitystä, mutta pidemmällä aikavälillä ympäristöt elävät ja kehittyvät projektin aikana.
Jos sen sijaan infraa hallittaisiin automatisoiduin työkaluin (esimerkiksi CloudFormation ja Terraform), voitaisiin yksiselitteinen, ajantasainen ja koneluettava kuvaus palvelusta tallentaa versionhallintaan. Ympäristöjen eriytyminen pysähtyy hyvällä hallinnalla.
Mikä on infran toimittajan tuottama lisäarvo?
Ylläpidon keskittämisellä tilaaja tavoittelee kustannustehokkuutta ja toimintavarmuutta. Korkean muurin takaa tapahtuva sokkoylläpito jarruttaa kuitenkin kehitystä, ja synnyttää piilokustannuksia. Moni tilaaja on kokemustensa kautta havahtunut tilanteeseen ja hiljalleen oivaltanut pilvipalveluiden merkityksen.
Äskettäin julkaistussa pilvialustoja kartoittavassa tietopyynnössä on useita loistavia vaatimuksia, joista poimin ja tiivistin tähän pari:
- Itsepalvelumahdollisuus ja ohjelmoitavat rajapinnat. Kehittäjien tulisi olla vastuussa siitä, että ohjelmisto toimii myös tuotannossa. Palvelukohtainen ylläpitotyö pitäisi olla osa projektia, ja se pitäisi erottaa pohjainfrastruktuurin ylläpidosta. Ohjelmoitavat rajapinnat mahdollistavat infran automatisoinnin. Plussaa saa erityisesti siitä, jos toteuttaa yleisesti käytössä olevan rajapinnan.
- Kapasiteetin ja kustannusten skaalautuminen käytön mukaan. Kun infraa saa tarpeen mukaan, ja hinnat pyörivät sadoissa euroissa kymmenientuhansien sijaan, kokeiluille ei muodostu kynnystä.
Mikä onkaan se lisäarvo, josta infran toimittajalle maksat? Perusinfran tarjoamisen tekevät globaalit pilvitoimittajat laadukkaasti, ja kilpailussa hinnat on poljettu maahan. Tuotantoonvienti ja sovelluspäivitykset onnistuvat kehitystiimiltä heittämällä nykyaikaisin työkaluin. 24/7 valvonta ja ylläpito hoituu pitkälti automaatiolla.
Ketterä kehitys ei onnistu sellaisen käyttöpalvelutoimittajan kanssa, joka piileksii muurin takana sopimuspapereitaan sivelemässä. Mielestäni on täysin selvää, että sellaiset yritykset joutuvat tulevaisuudessa joko keskittymään pilvipalveluiden tarjoamiseen tai osallistumaan aktiivisemmin ohjelmistokehitysprojekteihin. Kummalla tavalla muuri murretaan, sillä ei ole minulle niinkään väliä.
