Sovelluskehittäjän tehtävät, työskentelytavat ja menetelmät ovat muuttuneet valtavasti viimeisen muutaman kymmenen vuoden aikana. Karu totuus on, että ne työkalut, jotka olivat teräviä 1990-luvulla ovat menettäneet teränsä ja 2010-luvulla tarvitaan uudet keinot tuottavaan sovelluskehitykseen. Tällä hetkellä suurinta nostetta keräävät sovelluskehitysmenetelmät niputetaan DevOps termin alle. Sanan, jolla tarkoitetaan yhtä montaa asiaa kuin sillä on käyttäjiä, vailla yhtenäistä määritelmää.
Menetelmien aikakaudet
Sovelluskehitys voidaan jakaa karkeasti viimeisen parinkymmenen vuoden ajalta kolmeen aikakauteen. Vesiputousmalli on se prosessi, josta kaikki alkoi. Vesiputousmallin mukaisesti projekteja on viety läpi vuosikymmeniä ja viedään varmasti vieläkin. Vesiputousmalli on havaittu käytännössä kehnoksi, sillä se vaatii vaatimusten ennalta tietämistä ja täydellistä etukäteen suunnittelua, mikä on käytännössä mahdotonta. Tähän syntyi ratkaisuna ketterä ohjelmistokehitys. Ketterää ohjelmistokehitystä voidaan tehdä monella tavalla, mutta ehkä merkittävimmät menetelmät joita yhä käytetään ovat Scrum ja Kanban. Ketterä ohjelmistokehitys ratkaisi pääasiassa haasteet asiakkaan ja toimittajan viestinnän välillä sekä mahdollisti vaatimusten muuttumiseen reagoimisen projekteissa. Sovellukset tarvitsevat kuitenkin infrastruktuurin missä niitä ajetaan sekä niiden päivittäminen ja ylläpito vaatii työtä. DevOps pyrkii ratkaisemaan haasteet infrastruktuurin hallinnassa sekä sovellusten päivittämisessä ja integroinnissa.
Vesiputousmalli on saanut alkunsa jo 1970-luvulla ja siinä prosessi etenee vaihe vaiheelta eteenpäin kuin vesiputouksessa. Voidaan ajatella, että asiakkaalta tulee syöte vaatimusten muodossa toimittajalle, josta sovelluskehittäjät valmistavat lopputuotteen, joka lähetetään asennettavaksi ajoympäristöön. Prosessi on hyvin kankea eikä mahdollista nopeita suunnanmuutoksia projektin aikana. Sovelluskehittäjän näkökulmasta tämä voidaan nähdä helppona tilanteena, sillä tekninen määrittely on kuvaus sovelluksesta mikä toteutetaan, eikä juuri muusta tarvitse murehtia. Vastaavasti kun tuote on valmis, se vain sysätään eteenpäin asennettavaksi. On kuitenkin selvää, että tällaisella mallilla kun viestintä on aina joka vaiheessa vain yhteen suuntaan syntyy täysin vääränlaisia ja epäonnistuneita lopputuloksia.
Ketterä ohjelmistokehitys ratkaisi useita vesiputousmallin haasteita. Merkittävin ero oli siirtyminen yksisuuntaisesta viestinnästä kaksisuuntaiseen asiakkaan ja toimittajan välillä. Kun vaatimukset jaettiin pienempiin kokonaisuuksiin ja muutoksiin pystyttiin reagoimaan nopeasti, syntyi iteratiivinen ohjelmistokehitys. Sovelluksia kehitettiin pala-palalta ja asiakas näki lopputuloksen kehittyvän ajallisesti suhteellisen lyhyissä iteraatioissa. Iteratiivinen kehitys asetti testaukselle uusia vaatimuksia. Kun sovellusta kehitetään pienissä osissa, on hyvin todennäköistä että syntyy regressiota. Regression havaitsemiseksi tarvitaan automatisoituja testejä. Syntyi tarve jatkuvalle integraatiolle. Sovelluskehittäjän kannalta ketterä ohjelmistokehitys lisäsi vaatimuksia sosiaalisille taidoille sekä sovellusten rakentamiseen iteratiivisesti.
DevOps perustuu pitkälti ketterästä ohjelmistokehityksestä opittuihin asioihin, johon lisättynä virtualisoitu infrastruktuuri mahdollisti automatisoidun järjestelmähallinnan. Fyysiset rajapinnat muuttuivat ohjelmoitaviksi rajapinnoiksi. Infrastruktuurin hallinnalle syntyi nopeasti uusia vaatimuksia ja sen kautta syntyi uusia työkaluja ja toimintatapoja. Osa järjestelmäasiantuntijoiden tehtävistä siirtyi sovelluskehittäjille kun mekaaninen työ muuttui ohjelmointityöksi. Infrastruktuurin hallintatyökalut kuten Chef, Puppet ja JuJu pyrkivät vastaamaan uusiin vaatimuksiin kasvattamalla tuottavuutta korkeammalla abstraktiotasolla ja uudelleenkäytettävillä komponenteilla. Sovelluskehittäjille syntyi vaatimus täysin uuden osa-alueen hallintaan uusilla työkaluilla ja teknologioilla.
DevOps – määritelmä
DevOps termille ei ole mitään virallista määritelmää ja sitä käytetään hyvin monenlaisissa merkityksissä. Kerron tässä oman näkemykseni siitä mitä DevOps tarkoittaa ja se on toivottavasti ainakin lähellä sitä mitä termin yleisesti kuvitellaan tarkoittavan. DevOps voidaan jakaa sen filosofiseen merkitykseen, sekä konkreettiseen tekemiseen. DevOps on joukko menetelmiä ja toimintatapoja, jotka pyrkivät parantamaan viestintää ja yhteistyötä sovelluskehittäjien ja järjestelmäasiantuntjoiden välillä. Infrastruktuurin hallinnasta tulee osa sovelluskehitystä.
DevOps ei ole mahdollista ilman ketteriä ohjelmistokehitysmenetelmiä. Sovellusten päivittämisen ja asentamisen automatisointi tarkoittaa sitä, että myös vaatimustenhallinta pitää olla hyvin ketterää. Tämä ei onnistu ilman jatkuvaa viestintää toimittajan ja asiakkaan välillä. Nopeassa tahdissa tehtävät sovellusten julkaisut vaativat korkealle tasolle automatisoidun testausjärjestelmän ja julkaisujen hyväksymismenetelmän. Jatkuva integraatio on oltava osana kehitysprosessia.
Pilvipalvelut ja vielä tärkeämpänä virtualisointi ylipäätään mahdollistavat infrastruktuuritasolla nopean reagoimisen vaatimusten muuttumiseen. Toimintaympäristö, asiakas ja loppukäyttäjät luovat jatkuvasti muuttuvan ympäristön. Ei riitä, että sovellustasolla pystytään mukautumaan muuttuviin vaatimuksiin, vaan myös infrastruktuurin on mukauduttava. Perinteisesti tämä ei ole ollut mahdollista, sillä jo uusien palvelimien tilaaminen on saattanut kestää kuukauden. Virtualisoidussa maailmassa tämä voidaan tehdä nappia painamalla, tai jopa niin, että palvelimen hankinnasta, pystytyksestä ja käyttöönotosta vastaa sovellus ja sinne rakennetut algoritmit.
Onko sovelluskehittäjä herra?
DevOps nähdään usein siten, että sovelluskehittäjä ottaa vastuulleen osan järjestelmäasiantuntijan tehtävistä, mutta harvoin toisinpäin. Ehkä termin osien Dev ja Ops järjestys on muodostunut juuri siitä syystä, että sovelluskehittäjä nähdään seksikkäämpänä roolina ja järjestelmäasiantuntija jää vähemmälle huomiolle. Työkalujen abstraktiotaso on noussut ja esimerkiksi shell-skriptien sijasta käytetään ilmaisuvoimasempi ohjelmointikieliä kuten Ruby tai Python. Uusien ohjelmointikielien ja sovelluskehysten tuleminen osaksi infrastruktuurin hallintaa sekä palvelinten virtualisointi ovat vähentäneet perinteistä järjestelmäasiantuntijan työtä.
DevOps ei kuitenkaan tule yksin. Virtualisoitu infrastruktuuri mahdollistaa korkean tason automatisoinnin, mutta se ei ole mahdollista ilman tuottavia työkaluja. Järjestelmäasiantuntijoiden on omaksuttava toimintatapoja ja taitoja sovelluskehittäjiltä, sillä perinteinen palvelinten ja infrastruktuurin mekaaninen ylläpito on yhä vähenemässä. Suomessakin on havaittavissa, että isot järjestelmäinfrastruktuuria tarjoavat IT-yritykset ovat joutuneet omaksumaan täysin uusia tapoja ja työkaluja toteuttaa järjestelmien hallintaa. Voidaan sanoa, että järjestelmäasiantuntijoille tie DevOps maailmaan on kivinen, mutta varmasti hedelmällinen.
Sovelluskehittäjän osaamisvaatimukset ovat lisääntyneet niin sosiaalisella kuin tekniselläkin puolella. Harvassa ammatissa vaaditaan näin suurta osaamisprofiilin muutosta suhteellisen lyhyellä aikajänteellä. Ja loppua ei näy. Jos olet nyt harjalla, pidä huolta että olet siellä myös jatkossa. Sovelluskehittäjä, ole ylpeä ammatistasi!
