Perinteinen tapa rakentaa sovelluksia monoliittisen arkkitehtuurin (kuva alla) avulla saattaa olla ongelmallista sovellusten yhä suurentuessa ja monimutkaistuessa. Vaihtoehdoksi on tulossa joko SOA (Service Oriented Architecture) eli palvelukeskeinen arkkitehtuuri tai vielä pitemmälle granuloinnissa menevät mikropalvelut.

Keskityn tässä nopeasti kasvavaan mikropalvelutarkkitehtuuriin. SOA arkkitehtuurin ja mikropalveluiden keskeiset erot löytyvät moduulien koosta ja yhteysmuodoista. Suuremmat SOA moduulit viestivät yhteisen väylän kautta, kun taas mikropalveluja käyttävät sovellukset on rakennettu löyhästi kytkettyjen palveluiden kokoelmiksi. Mikropalvelut ovat vikasietoisempia ja niitä on helpompi laajentaa. Niiden käyttöönoton ehkä suurin este on, miten mikropalvelut luodaan, eli miten suuri ohjelmisto jaetaan pienemmiksi moduuleiksi ja miten niitä hallitaan (orkestroidaan).

Kerron aluksi, miten mikropalveluista koostuva sovellusarkkitehtuuri poikkeaa monoliittisesta sovelluksesta. Kuvaan lopuksi mikropalveluiden vahvuuksia ja heikkouksia. Kuvauksessa pyrin katsomaan arkkitehtuuria sekä kehittäjien että sovelluksen hankkijoiden kannalta. Sovelluksella tarkoitan tietokannasta tietoja hakevaa ohjelmistoa (mm. web-sovellus).

Ohjelmistokehittäjät ovat perinteisesti luoneet suuria, monoliittisia sovelluksia, jotka sisältävät kaikki organisaation tarvitsemat toiminnot yhteensopivana pakettina. . -- Monoliitteja ovat useat kansainvälisten jättiläisten rakentamat suuret sovellukset. Suomeen hankittu ja kovaa kritiikkiä saanut potilastietojärjestelmä Apotti on turhauttava esimerkki. Eikä varmasti ole viimeinen sovellus.

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 alussa 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. Mutta kuvattu skenaario ei kuitenkaan ole maailmalla epätavallinen. Sovellusten 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 moduuleihin, jotka ovat vastuussa vain moduulille määriteltyjen tehtävien suorittamisesta. Ne kommunikoivat keskenään yleisesti hyväksyttyjen, standardoitujen ohjelmointirajapintojen (API) avulla.

Arkkitehtuurin yhteenveto :

1. Koostuu useista, löyhästi kytketyistä, itsenäisistä moduuleista.
2. Moduulit 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ä kuvattu arkkitehtuurin itsenäisiä moduuleja ylläpitävät ja kehittävät omat kehittäjät toisistaan riippumatta (poissulkien sovitut rajapinnat). Sovellusta on tämän vuoksi erittäin helppo laajentaa liittämällä siihen aina uusi mikropalvelu, jolla on oma kehittäjä. Todella huikeita mahdollisuuksia sisältyy siihen, että palvelun voi rakentaa ulkopuolinen kehittäjä ja palvelut voivat sijaita internetin etäpalvelimilla. Tällaisia sovelluksia on jo olemassa ja niiden määrä kasvaa.

On vaikea puhua mikropalveluista puhumatta samalla myös ns. konteista. Monet kehittäjät kokevat, että kontit ovat kuin tehty mikro-palveluille. Toki pieniä mikropalveluja voi käyttää ilman konttejakin, mutta silloin menettää paljon konttien eduista.

Mikropalvelu paketoidaan konttiin, joka sisältää minimimäärän softaa palvelun toimimiseksi. 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 standardoitujen 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 sotkematta toisten kehittäjien koodia. Sovelluksen jonkun kohdan päivittäminen on myös helppoa. Vaihdetaan vain kontti ja voilà, 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ää 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 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 vain suurien ohjelmistojen rakentamiseen. Tekniikkaa

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 moduuleihin on osoittautunut haasteelliseksi. Kommentti:
   Sitä se on perinteisessä suurten kokonaisuuksien koodauksessakin. Jos osittamisessa mikropalveluihin onnistutaan, se avittaa suuresti järjestelmän skaalautuvuutta.
3. Laajuuden arviointi haasteellista
   Sovelluksen koon arviointi on tärkeää. Liian suuri 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 useita pk-yrityksiä, joilla on syvällistä mikropalveluosaamista. Yhteistoiminnassa niiden ja sovellusten tuottajien kanssa mikropalveluihin perustuvat kotimaiset ratkaisut ovat reaalisia ja myös turvallisia.

Mikropalveluilla on tukevia taustavoimia kuten Google, IBM, Docker, Oracle, 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 .

Kuten aiemmin jo tuli kerrottua, konttitekniikka ja mikropalvelut liittyvät tiiviisti yhteen. Yksittäinen, yhden sovelluksen käsittävä kontti on ensimmäinen, helppo ja yksinkertainen askel mikropalvelujen suuntaan. Totuuden nimessä seuraavat askeleet ovat sitten huomattavasti vaativampia.

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 täysin ilmaisen työkalun "Oracle Transaction Manager for Microservices Free". Se yksinkertaistaa huomattavasti esimerkiksi Oracle Apex sovellusten integointia eri ohjelmistokielillä luotuihin mikropalveluihin. -- Focusa ohjelmistomme on rakennettu Apex kehittimellä.

Jouni Jokinen (opiskelee tietojenkäsittelyä Turun yliopistossa) on rakentanut Linux palvelimellemme mikropalvelun konttitekniikkaa käyttäen. -- Tulemme jatkossa tässä blogissa kertomaan, mitä arkkitehtuurille kuuluu juuri nyt: Jos olet kiinnostunut esimerkiksi yhteistyöstä, lähetä meili.