Mikropalvelutko ratkaisevat IT-haasteet?, päivitys 25.2.2016

Ote kansikuvasta TIVI-lehden helmikuun 2016 numerosta

Mikropalveluista on TIVI-lehden helmikuun 2016 numerossa pitkä juttu. (1) Kyse on uudenlaisesta tietojärjestelmien rakentamistavasta. Vanhan monoliittisen rakentamistavan sijaan tehdään itsenäisiä komponentteja tai palveluja, jotka siten liitetään yhteen ratkaisukokonaisuudeksi. Rakentamistavan etuna pidetään nopeutta ja helppoa hallittavuutta. Kokonaisuuteen voidaan tuoda myös uudenlaista tekniikkaa mukaan. Myös tällä ratkaisulla voidaan suojautua yhden toimittajan loukusta. Mikropalvelut ovat samaa tekemisen kulttuuria ketterien menetelmien kanssa mukaan lukien ns. Devops-kulttuuri. (2) Mikropalvelun toteuttaminen edellyttää myös systemaattista arkkitehtuuria ja tätä kautta pilkkomista osiin. Oleellista on myös, että mikropalvelut kytketään palininfrastruktuusissa pilvipalveluihin. Mikropalvelulla pitää olla myös oma tietomallinsa.

Mikropalvelun toteuttamisesta on esitetty jo duubioitakin. Edellytyksenä on kokonaisarkkitehtuuri, joka on hallinnassa. Jos hallinta menetetään, syntyy tietojärjestelmäkokonaisuudesta sotku. Samoin haasteena on tuo kunkin komponentin osalta oma tietomallinsa. Miten sitten eri komponentit toimivat yhteen ja miten komponenttien sisäinen logiikka toimii. Julkisella sektorilla vannotaan mm. tiedon kertakirjauksen nimeen. Erilliset komponenttikohtaiset tietomallit eivät välttämättä tätä tue. Onko sittenkään hallittavuus se etu. Onko sittenkään toimittajariippumattomuus tosiasia. Mikropalveluista esitetään toimivina ratkaisuina nettipohjaisia järjestelmiä kuten Amazon, Netflix tai Spotify.

Mikropalvelut tilaajan kannalta kuulostavat äkkiseltään myös keskeisten tilaajan ongelmien ratkaisulta. Voidaan tehdä yleinen tilaus, joka sitten voidaan määritellä yhdessä tuottajan kanssa tarkentamalla tilaajan arkkitehtuuripiirustuksia. Tilauksessa voidaan keskittyä yhdessä hallitun kokonaisuuden rakentamiseen, jolloin saadaan myös nopeita osavoittoja aikaan. Tällä vältetään vesiputousmallin jäykkyys. Toisaalta keskeiseksi nousevat kokonaisarkkitehtuurin kattavuus, systemaattisuus ja pitkälle viedyt sisältökuvaukset. Samalla on luotava kuitenkin standardit, joita noudatetaan pitkälle rakentamisen eri vaiheissa. Muuten hallitttavuus katoaa. Tietoturva on myös (varsinkin sosiaali- ja terveydenhuollossa) keskeinen haaste. Miten hallitaan tietoturva eri softakomponenttien viidakossa ja eri pilvipalvelujen viidakossa.

Mikropalvelut osana IT-liiketoimintaa voisi olla ratkaisu myös sosiaali- ja terveydenhuollon vanhentuvan tietojärjestelmäinfran uudistamiseen. Nythän Apotti-hankkeessa on valittu monoliittinen ratkaisu, johon luvataan kyllä rajapintaratkaisut avoimeen laajennettavuuteen. Tämä Apotin monoliitti ei kuitenkaan anna mahdollisuuksia koko järjestelmän vähittäiseen uudistamiseen. Toinen hankekokonaisuus UNA ilmeisesti lähtee enemmän mahdollistamaan tätä mikropalveluajattelua.

Mikropalvelut ja hankkeen/projektin hallittavuus. Julkisia hankkeita on kritisoitu erilaisista epäonnistumisista liittyen hankkeen ytimeen: tavoitteet, resurssit/kustannukset ja aikataulu. Olennainen epäonnistumisen syy on tilaajan ja tuottajan välisen yhteistyön, dialogin, ymmärryksen pettäminen. Tilaajan kannalta ongelmia tuottaa se, miten tuottaja toteuttaa ratkaisut, miten se sitouttaa rakentamisen eri vaiheissa tilaajan mukaan prosessiin. Tuottajan kannalta ongelmia tulee vääristä tai optimistisista kuvitelmista rakentaa palvelu siten, että myös riittävä liikevoitto varmistetaan. Tilaaja ei kovin paljoa rajaa tilauksessaan sitä, millä työmenetelmillä tuottaja tekee ratkaisut. Vesiputousmalli, ketterät menetelmät ja erilaiset hybridimallit ovat mahdollisia. Mikropalvelu on noihin edellä esitettyihin verrattuna vielä astetta autonomisempi malli. Mikäpäs siinä, jos komponentti on olemassa, koeteltu ja tiedetään, mitä se tuottaa. Jos komponentteja rakennetaan pitkin matkaa, on tilaajalla kokonaisuuden hallinta tosi vaativa tehtävä.

IT-työmenetelmien avaaminen olisi tarpeellinen standardoinnin kohde. Tilaajan pitäisi tietää varsin tarkkaan, minkälaisia työmenetelmiä tuottaja käyttää. Itse asiassa pitäisi voida verrata keskenään kilpailutilanteessa tuottajakandidaattien työmenetelmiä. Kilpailuttaminen voisi olla prosessi, jossa käydään läpi tilaajan toiveet, mutta samalla myös kilpailuun osallistuvien tuottajien työmenetelmät. Lisäksi on äärimmäisen tärkeätä määritellä arkkitehtuurissa myös tuottajan kannalta toimintaan, tietoon, softaan ja palvelinifraan liittyvä yhteen toimivuus. Mikropalvelut ja korotetun tietoturvan mahdollistamat palvelininfraratkaisut ovat monitoimijaympäristöä. Tuon kokonaisuuden on toimittava niin rakentamis- kuin ylläpitovaiheessakin.

Pohdiskelin IT-haasteita tietämättä tästä uudesta mikropalveluajattelusta. Monelta osin samat haasteet toistuvat tässäkin konseptissa. (2) 

Päivitys 21.2.2016: Toni Hintikka FB:n puolella kommentoi:
"Ainakin Suomi.fi portaalissa on menestyksellisesti tehty. Pieniä palasia ketterästi. Julkisella puolella pitäisi ehdottomasti tehdä avointa lähdekoodia, kuten suomi.fi"

Päivitys 25.2.2016: Hannu Laesvuori kommentoi LinkedInin puolella seuraavasti:
"Mielestäni yksi työkalu lisää työkalupakkiin. Yhtä viisasten kiveä menetelmien osalta ei ole, koska tehtävät hankkeet vaihtelevat niin paljon. Kuka tekee, mitä tekee, millaisessa ympäristössä, millaisilla reunaehdoilla? Usein menetelmien osalta järkeviä vaihtoehtoja on useampia, mutta valitettavasti joskus näkee täysin vääriäkin valintoja joiden takia hyviäkin hankkeita on mennyt pahasti pieleen.
Julkisella sektorilla tilaajien resurssit ja osaamistaso ohjelmistotuotannon ymmärtämisen suhteen vaihtelee. Toiset pystyvät hyvin valitsemaan hankkeissa käytettäviä menetelmiä, toiset eivät. Vaarallista on jos mennään kulloisenkin muotisanan perässä ilman että ymmärretään millaiseen ympäristöön se sopii ja mihin ei."

Viitteet

(1) Ari Saarelainen: Ohjelmistot muuttuvat mikropalveluiksi, TIVI, helmikuu 2016

(2) Olli Nylander: Digitaalisten palvelujen käytettävyys on pitkä prosessi, Tietoasiantuntija - lehti 5/2015, ss. 20-22.
http://ollintuumailut.blogspot.fi/2016/01/sahkoisten-palvelujen-kaytettavyys-on.html
- Devops: https://fi.wikipedia.org/wiki/Devops
"DevOps on ketterä toimintamalli sähköisten palvelujen tuottamiseen. Sillä pyritään edistämään kehitys- ja tuotantotoimintojen keskinäistä vuoropuhelua ja kykyä toimittaa muutoksia tuotantoon.
DevOps on muodostettu sanoista development (kehitys) ja operations (tuotanto), joiden rajapinnassa DevOps -toiminnot tapahtuvat. Tavallisia ohjelmistokehityksen toimintoja ovat uuden toiminnallisuuden luomiseen ja virheiden korjaamiseen liittyvät ohjelmointi-, suunnittelu-, testaus- ja dokumentointitehtävät. Tuotantotoiminto rakentaa palvelun vaatiman infrastruktuurin (palvelimet, verkot, ohjelmistoasennukset) ja vastaa palvelun toimittamisesta mm. tarkkailemalla palvelun toimintaa, asentamalla päivitykset ja huolehtimalla kapasiteetin optimaalisesta käytöstä."