Tänä päivänä Suomessa on käynnissä useita digitalisaatiohankkeita niin julkisella kuin yksityiselläkin puolella. Sähköisten palvelujen saaminen yhdeltä luukulta nopeasti ja turhaa käsittelyä välttäen tuo säästöjä ja parantaa käyttäjäkokemusta.

Suuret tavoitteet johtavat monesti suuriin hankkeisiin, ja suuret hankkeet ovat tunnetusti olleet aina haastavia. Miten tällä kertaa voitaisiin välttää ne samat ongelmat, joihin kerta toisensa jälkeen törmätään, kun rakennettava kokonaisuus kasvaa isommaksi kuin tekijöidensä kyky ymmärtää sitä?

Miksi järjestelmät sitten kasvavat hallitsemattomiksi monoliiteiksi ja lopulta rämettyvät sellaiseen tilaan, että niiden ylläpito ja kehittäminen käy mahdottomaksi? Harvoin ne syntyessään ovat tässä lohduttomassa jamassa, vaan muutos tapahtuu ajan kanssa ja lähes huomaamatta sitä mukaa kun järjestelmälle keksitään yhä uusia tehtäviä ja vastuita. Jokainen lisätty ominaisuus tekee seuraavasta muutoksesta aina vähän vaikeampaa, kunnes kehitys pysähtyy. Miten tämä jo ennalta nähtävissä oleva kohtalo voidaan välttää?

Microservices-arkkitehtuurissa yhden ison ja kaikesta vastuussa olevan järjestelmän sijaan rakennetaan useita pienempiä palveluja, joilla jokaisella on vain yksi tarkkaan rajattu tehtävä. Nämä palvelut ovat itsenäisiä kokonaisuuksia, joilla on mahdollisimman vähän riippuvuuksia keskenään. Palvelujen välinen viestintä tapahtuu kevyillä protokollilla, joista yleisimpiä ovat REST-rajapinnat sekä viestijonot.

Poistamalla palvelujen väliset tiukat riippuvuudet saavutetaan useita etuja:

Microservices-periaatteiden noudattaminen ei kuitenkaan ole aina helppoa. Suunnittelun kannalta haastavin tehtävä on päättää missä kulkevat palvelujen välisten vastuiden rajat. Tämä linjanveto voi olla hyvinkin vaikeaa, varsinkin jos toimiala ei ole tuttu tai sen liiketoimintasäännöt ovat tekijöille hepreaa.

Myös arkkitehtuurin hajautettu luonne tuo mukanaan omat haasteensa ja vaatimuksensa. Palveluista on esimerkiksi rakennettava vikasietoisia, jotta lyhyet tietoliikennehäiriöt tai yksittäisten palvelujen hetkellinen hajoaminen ei vie kaikkia muitakin mukanaan.

Microservices-arkkitehtuuri ei tietenkään sovellu kaikkiin projekteihin. Se tuo mukanaan kompleksisuutta ja suuremman määrän liikkuvia osia, joiden hallinta ja orkestrointi voi viedä suhteettoman paljon resursseja projektissa. Pienet ja yksinkertaiset järjestelmät eivät siis todennäköisesti hyödy microservices-arkkitehtuurista, mutta suurille IT-hankkeille se voi olla ainoa järkevä vaihtoehto.

Voitaisiinko microservices-arkkitehtuuria noudattamalla varmistaa digitalisaatiohankkeiden onnistuminen? Pelkästään tekniseltä kannalta tarkasteltuna sen mukanaan tuomat edut kuulostavat jo varsin hyviltä, mutta on vielä jotain muutakin, joka oikein hyödynnettynä voi muuttaa tavan, jolla isoja hankkeita vedetään.

Microservices-arkkitehtuurin yhteydessä puhutaan projektien sijaan tuotteista. Tuotteen rakentanut tiimi vastaa siitä kokonaisuudessaan myös julkaisun jälkeen ylläpitäen sitä ja oppien kuinka se käytännössä toimii tuotantoympäristössä. Pitkäjänteisempi työ tuotteen parissa tuo kehittäjät lähemmäksi loppukäyttäjiä ja auttaa heitä löytämään ratkaisuja, joilla tuote saadaan palvelemaan käyttäjiään vieläkin paremmin.

Erityisesti julkishallinnon hankkeet hyötyisivät tällaisesta kehitysmallista, koska se mahdollistaa myös kotimaisten pienten ja ketterien IT-talojen osallistumisen julkisten palvelujen kehittämiseen. Aito kilpailu varmistaisi myös sen, ettei yhdellekään toimittajalle tulisi edes mieleen tarjota nykyaikaan täysin sopimattomia ratkaisuja, kuten Apotti-hankkeen  MUMPS.

Suomessa on jo pitkään kyselty innovaatioiden perään. Koko kansan palveluiden digitalisoinnin yhteydessä on kaikki edellytykset luoda hyvät olosuhteet innovoinnille ja tuoda samalla kaivattua uutta näkemystä ja intoa julkisen puolen IT-hankkeisiin.