Perinteinen tapa rakentaa sovelluksia monoliittisen arkkitehtuurin (kuva alla) avulla saattaa olla ongelmallista sovellusten yhä suurentuessa ja monimutkaistuessa. Vaihtoehdoksi on tulossa mikropalvelut. Suosittelemme katsomaan alan arvostetun "gurun" Nana Janishan ihailtavan selkeästi esittämän videon, joka kertoo kaiken oleellisen mikropalveluista. Napauta kuvaa.

Jos et ehtinyt katsoa videota, kuvaamme seuraavassa lyhyesti, mitä mikropalvelut ovat. Eli se on löyhästi toisiinsa liittyvien ohjelmistojen - moduulien - muodostama iso sovellus. Itsenäisten moduulien, konttien muodostamat mikropalvelut ovaT erittäin vikasietoisia ja niitä on helppo laajentaa. Miktopalveluiden käyttöönoton suurin haaste on ison sovelluksen osittaminen moduuleiksi ja miten kokonaisuutta hallitaan (orkestrointi). Tekoälyn käytöllä tulee varmasti olemaan suuri merkitys tulevissa ratkaisuissa.

Kerromme aluksi, miten mikropalveluista koostuva sovellusarkkitehtuuri poikkeaa monoliittisesta sovelluksesta. Kuvaamme lopuksi mikropalveluiden vahvuuksia ja heikkouksia. Kuvauksessa pyrimme katsomaan arkkitehtuuria sekä kehittäjien että sovelluksen hankkijoiden kannalta. Lopuksdi pohdimme, miten mikropalvelut sopisivat kotimaamme olosuhteiiin ja miten yhtiömme, Dianti voisi osallistua talkoisiin.

Ohjelmistokehittäjät ovat perinteisesti luoneet laajoja, monoliittisia sovelluksia, jotka sisältävät kaikki organisaation tarvitsemat toiminnot yhteensopivana pakettina. -- Monoliitteja ovat useat kansainvälisten jättiläisten rakentamat sovellukset. Niissä joissakin on todettu vakavia puutteita. Suomeen hankittu ja kovaa kritiikkiä saanut potilastietojärjestelmä Apotti on turhauttava esimerkki. Eikä se ehkä ole viimeinen.

Alussa kaikki saattaa toimia monoliitissa ja käyttäjät ovat tyytyväisiä. Jossain vaiheessa -- se on lähes sääntö -- käyttäjät pyytävät parannuksia ja lisäominaisuuksia. Eli tarvitaan lisää kehitystyötä ja monoliittisovellus kasvaa. Samalla helposti hahmotettu sovellus alkaa monimutkaistua. Useita itsenäisiä kehittämisryhmiä työskentelee samanaikaisesti sovelluksen kimpussa. Nämä "itsenäiset" ryhmät eivät kuitenkaan ole oikeasti lainkaan itsenäisiä. Ne työskentelevät yhdessä ja samassa koodiavaruudessa ja muuttavat samoja koodinosia.

Mitä tapahtuu, kun vaikkapa kolmen kehitysryhmän tehtävät ovat päällekkäisiä sovelluksessa? Koodimuutokset saattavat helpostikin törmätä. Koodin laatu - ja siten koko sovelluksen laatu - kärsii. Yksittäisen kehitystyöryhmän on hankala tehdä muutoksia ilman, että on laskettava vaikutukset muille tiimeille. Pahimmassa tapauksessa tiimi ei edes huomaa, miten sen tekemä koodi on ristiriidassa muiden kanssa.

Lopputuloksena on hidastuva ja hauras sovellus, jonka parasta-ennen päiväys on lopullisesti ohitettu ja jonka ylläpito on erittäin resursseja kuluttavaa. Asiakas voi lisäksi olla jopa ns. toimittajaloukussa, jossa asiakas maksaa sen, mitä toimittaja pyytää.

Edellä esitetty ei tietenkään tarkoita sitä, että käytössä oleva, hyvin toimiva monoliittinen sovellus pitäisi korvata jollain muulla. Se olisi järkevää vain selvässä umpikujatilanteessa. Kuvattu skenaario ei kuitenkaan ole maailmalla epätavallinen. Uuden ison sovelluksen suunnittelijoiden kannattaakin tekniikan kehittyessä harkita ja arvioida mikropalveluita todellisena mahdollisuutena.

Alan gurun Martin Fowlerin mukaan mikropalvelu-arkkitehtuuri koostuu "itsenäisesti käyttöönotettavien palveluiden sviiteistä", jotka on järjestetty "liiketoiminnan, automatisoidun käyttöönoton, loppupisteiden älykkyyden, kielten ja tietojen hajautetun valvonnan ympärille".

Määritelmä pyrkii sanomaan yhdessä lauseessa lähes kaiken mikropalveluista ja vaatii hieman selvennystä. -- Mikropalvelu-arkkitehtuurin perimmäisenä ajatuksena on, että sovellukset ovat yksinkertaisempia rakentaa ja ylläpitää pienempinä paloina, jotka toimivat saumattomasti yhdessä. Mikropalveluissa ohjelmistotoiminnot hajautetaan useisiin itsenäisiin palveluihin (moduuleihin), jotka ovat vastuussa vain moduulille määriteltyjen tehtävien suorittamisesta. Ne kommunikoivat keskenään yleisesti hyväksyttyjen, standardoitujen rajapintojen avulla - esimerkiksi REST rajapinnan kautta JSON-tiedostomuotoa käyttäen.

Arkkitehtuurin yhteenveto :

1. Koostuu useista, löyhästi kytketyistä, itsenäisistä moduuleista.
2. Moduulit eli kontit suorittavat liiketoimintaan kuuluvia palveluja.
3. Moduulit voidaan hajauttaa pilveen ja/tai lähiverkkoon.
4. Moduulia voidaan muuttaa, päivittää ja se voidaan poistaa muista riippumatta.

Yllä kuvatun arkkitehtuurin itsenäisiä moduuleja ylläpitävät ja kehittävät omat kehittäjät toisistaan riippumatta. Koko sovellusta on tämän vuoksi erittäin helppo laajentaa liittämällä siihen aina uusi mikropalvelu - kontti, jolla on oma kehittäjätiimi. Todella huikeita mahdollisuuksia sisältyy siihen, että palvelun voi rakentaa ulkopuolinen kehittäjä ja mikropalvelut sijaitsevat internetin etäpalvelimilla. Tällaisia sovelluksia on jo olemassa ja niiden määrä kasvaa.

Edellä on mainittu useaan otteeseen käsite "kontti". Monet kehittäjät kokevat, että kontit ovat kuin tehty mikropalveluille. Pieniä mikropalveluja voi käyttää ilman konttejakin, mutta silloin menettää paljon konttien eduista.

Mikropalvelujen moduuli (yksittäinen mikropalvelu) paketoidaan konttiin, joka sisältää minimimäärän softaa palvelun toimimiseksi. Kontti ja mikropalvelu (mikropalvelujen moduuli) eivät siis tarkasti ottaen ole sama asia. Jokainen kontti on käytännössä itsenäinen ja alustasta riippumaton palvelu ja voi sinällään olla oikea sovellus, jonka teoriassa voi lähettää asiakkaalle sellaisenaan. Amerikkalainen Docker yhtiö on konttiteknologian uranuurtaja.

Kontit keskustelevat tavallisesti standardoitujen REST rajapintojen kautta. Konttien yhteistoiminta on ollut hankalin asia konttiteknologiassa. Asian ratkaisevat ja tuovat jopa lisäarvoa ns. orkestrointityökalut, vähän kuin orkesterin kapellimestarit. Googlen kehittämä, mutta nyt avoin, Kubernetes niminen konttienhallintaohjelmisto, konttialusta on nousemassa ykköseksi.

Sovelluskehittäjille mikropalvelut ovat ideaalisia. Jokainen kehittäjä tai tiimi voi keskittyä siinä omaan mikropalveluunsa, konttiinsa sotkematta toisten kehittäjien koodia. Mikropalvelusovelluksen jonkun kohdan päivittäminen on myös helppoa. Vaihdetaan vain kontti ja toiminta jatkuu ilman, että koko sovellus häiriintyy. Seikka nopeuttaa dramaattisesti ylläpitotyötä. -- Heti perään on sanottava, että monoliittistäkin ohjelmistoa voi kehittää ja kehitetään tiimeittäin, vaikkakin niissä ei päästä mikropalveluja vastaavaan "vapauteen".

Myös sovelluksen hankkijalle mikropalveluiden "Legopalikka" arkkitehtuurista on vastaava hyöty. Organisaatiot, jotka ovat ovat jo ottaneet käyttöön mikropalvelut, pitävät niistä. LeanIX yhtiön tekemän selvityksen mukaan useimmat mikropalveluja käyttävät organisaatiot ovat niihin tyytyväisiä. Ja 71% niistä aikoo lisätä niiden käyttöä seuraavan vuoden aikana. Sovelluksia rakentavat yritykset taas kertovat saavansa tuotteensa viisi kertaa nopeammin markkinoille kuin monoliittisia sovelluksia rakentavat ohjelmistotalot.

Teknologia soveltuu raskaan varusohjelmiston (konttien hallinta, rajapinnat) vuoksi parhaiten laajojen sovellusten rakentamiseen. Pienten sovellusten luontiin, joiden arvioidaan myös pysyvän pieninä, rakentamiseen monoliittinen tekniikka on taloudellisempaa ja nopeampaa.

Lee Atchinson vuorostaan listaa mikropalveluille mm. seuraavia etuja:

1. Parantunut laajennettavuus
   Mikropalveluja voi lisätä mihin tahansa ketjussa. Skaalaus on nopeaa.
2. Parantunut vikasietoisuus
   Jos yksi mikropalvelu kaatuu, muut palvelut jatkavat työtään.
3. Optimoidut laajentumispäätökset
   Skaalauspäätökset voidaan tehdä moduulitasolla.
4. Oma mikropalvelu kunnossa
   Mikropalvelun rakentaja kantaa huolta vain oman palvelunsa moitteettomasta toiminnasta.
5. Liiketoiminnan ketteryys
   Moduulin vioittuminen vaikuttaa vain ko. palveluun -- nopeat kokeilut mahdollisia .
6. Ylläpito helppoa
   Mikropalveluja on helppo liittää sovellukseen. Ylläpito on mutkatonta.
7. Kehittämisen ja liiketoiminnan yhteistoiminta
   ´ Mikropalvelut peilaavat organisaation toimintoja, kehittäjät ymmärtävät käyttäjien tarpeita.
8. Kestävää arkkitehtuuria
   Kehittyneempi teknologia voidaan päivittää yhdessä moduulissa sen vaikuttamatta koko sovellukseen.
9. Pienempiä tiimejä
   Kehittäjätiimit ovat pieniä. Jeff Bezos'in kuuluisa "kaksi pizzaa sääntö" kuvaa mikropalvelujen filosofiaa. "Tiimi, jonka ruokailuun ei riitä kaksi pizzaa, on liian suuri."

Kolikolla on aina kaksi puolta. Alla on listattu Lee Atchinson'ia mukaellen mikropalvelujen mahdollisia haittoja.

1. Mikropalvelut voivat olla monimutkaisia
   Yksittäiset mikropalvelut ovat helposti ylläpidettäviä. Suuren moduulijoukon yhteistoiminta saattaa olla sotkuista.
   Kommentti: Konttien hallintaan on kehitteillä tehokkaita ohjelmistoja, esimerkiksi Kubernetes.
2. Vaativat huolellisen suunnittelun
   Sovelluksen suunnittelu on pakostakin oltava perinpohjaista ja kallista. Rakentaminen voi vaatia useita iteraatiokierroksia. Suuren järjestelmän pilkkominen moduuleiksi on osoittautunuthaasteelliseksi. Kommentti:
   Sitä se on perinteisessä isojen monoliittienkin koodauksessakin. Jos osittamisessa mikropalveluihin onnistutaan, se avittaa suuresti järjestelmän skaalautuvuutta.
3. Laajuuden arviointi haasteellista
   Sovelluksen koon arviointi on tärkeää. Liian suurta sovellusta on vaikea hallita.
   
4. Ostettuja palveluja ei voi hallita
   Ulkopuolisten toimittajien moduuleja ei voi kontrolloida. Toimittaja voi esimerkiksi muuttaa palvelun rajapintoja (API).
   Kommentti:
   Huonosti voi käydä toimittajalle, joka muuttaa palvelunsa yhteisesti sovittuja toimintoja tai rajapintoja.
5. Huono suunnittelu voi olla kallista
   Vikasietoisuuden suunnittelu voi olla monimutkaisempaa kuin monoliitissa. Suunnittelussa täytyy ottaa huomioon mm. itsenäisten moduulien kaatumisesta aiheutuvat toipumiset.
6. Hyviä asiantuntijoita on ollut nihkeästi saatavilla
   Mikropalvelut vaatii suunnittelijoilta, kehittäjiltä ja ylläpitäjiltä "syvän tason" osaamista, kuten ns. ketterää kehittämistä, kehittämisen automatisointia ja yhä enemmän myös pilviteknologian tuntemista. Ja jos tekijöitä ei löydy, vaaka kallistuu usein tutuille turvallisille vesille.
   Kommentti:
   Suomessa on jo pk-yrityksiä, joilla on syvällistäkin mikropalveluosaamista. Yhteistoiminnassa niiden ja sovellusten tuottajien kanssa mikropalveluihin perustuvat kotimaiset ratkaisut ovat reaalisiaja ja myös turvallisia.

Mikropalveluilla on tukevia taustavoimia kuten Google, IBM, Docker, Oracle ja Microsoft, joten on odotettavissa tekniikan kehittyvän ja kypsyvän vääjäämättä. Mikropalvelut on jo näyttänyt kyntensä useissa moderneissa IT organisaatioissa. Monoliittiset järjestelmät eivät rakenteensa vuoksi kykene vastaamaan kaikkiin, jatkuvassa kehityksessä olevien tietojärjestelmien tarpeisiin.

Mikropalvelukoneiston hyvin öljytty toiminta vaatii sen säännöllistä tarkastusta. Uusien palvelujen lisääminen on suoritettava huolella. Sovelluksen ja arkkitehtuurin hyvällä tuntemuksella se onnistuu. Sen jälkeen, kun oppirahat on maksettu ja käyttö opittu, mikropalvelut on osoittanut maksavan itsensä takaisin muutamassa vuodessa .

Mikropalveluihin ja kontteihin perustuva arkkitehtuuri alkaa olla vakavasti otettava teknologia myös Suomessa. On mahdollista päästä asteittain markkinatilanteeseen, jossa, toisin kuin nyt, pienetkin kotimaiset IT yritykset voivat mikropalvelujen tuottajina menestyksellisesti kilpailla kansainvälisten IT-jättien kanssa. Arkkitehtuuri on nähty tärkeäksi myös julkishallinnossa. Valtio on jo panostanut 100 miljoonaa euroa kontteihin. Digi- ja väestötietovirasto (DVV) on kehittänyt Palveluväylään pilvipalveluna liityntäpalvelinta, jonka voi tuoda palvelun kylkeen mikropalveluna ilman tällä hetkellä tarvittavaa palvelininvestointia. Lue lisää

Oracle on julkaissut uuden käänteentekevän tietokannan Oracle 23c, joka soveltuu erittäin hyvin mikropalveluksi yhdessä Oracle Apex sovelluskehittimen kanssa. Oracle 23c:ssä on yhdistyneenä relaatio-, JSON, teksti- ja vektoripohjainen data, jota käyttäjä voi operoida yksinkertaisilla SQL-lauseilla. Tietokannassa on lisäksi Oraclen ja sen partnerin kehittämä uniikki tekoäly, joka mahdollistaa ChatGPT:n tapaisen ja yrityksen paikallisen tiedon yhdistetyn haun.