Mikropalvelut, mihin niistä on?
Selvityksen lähteitä
Sivun lähteinä on käytetty mm.:
  1. Relic yhtiön mikropalvelugurun Lee Atchinsonin julkaisuja
  2. Konttiteknogian uranuurtajan Docker yhtiön kotisivut
  3. Suomalaisen Alfame yhtiön julkaisu Mikropalvelut selkokielellä
  4. Tuomas Piipon opinnäytetyö (TYY, 6.6.2018) Digikehittäminen ja mikropalvelut Turun kaupungilla
Lisäksi olen lisännyt tekstin yhteyteen aiheeseen liittyviä viittauksia.
Heikki Ojala, 15.10.2020.
Mikropalvelut (Microservices) versus monoliittiset ohjelmistot
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.
Monoliitti
Monoliitti (vasemmalla) on kompakti kokonaisuus. Mikropalvelut (oikealla) muodostuu itsenäisistä, helposti päivitettävistä moduuleista. SOA'ssa on molempien piirteitä.
____________________________
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.
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).
Mitä vikaa on monoliittisessa arkkitehtuurissa?
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 juuri hankittu ja arvosteltukin potilastietojärjestelmä, Apotti on hyvä esimerkki.
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.
Mikropalvelujen arkkitehtuuri
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". ”
Kaavio monoliitin ja mikropalvelujen toiminnoista.
Mikropalvelut (oranssi) ovat itsenäisiä palveluja tietokantoineen (vihreä). Vasemmalla monoliittinen ohjelmisto.
____________________________
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 :
  • Koostuu useista, löyhästi kytketyistä, itsenäisistä moduuleista.
  • Moduulit suorittavat liiketoimintaan kuuluvia palveluja.
  • Moduulit voidaan hajauttaa pilveen ja/tai lähiverkkoon.
  • 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.
Kontit paketoivat mikropalvelut
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.
Mikropalvelut paketoituina kontteihin
Mikropalvelut tietokantoineen on pakattu kontteihin. Ne voivat olla itsenäisiä sovelluksia, jotka voi sellaisenaan asentaa asiakkaiden erilaisiin järjestelmiin.
____________________________
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.
Kenelle mikropalvelut sopivat?
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 "hurahtaneet" mikropalveluihin tuntuvat pitävän 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:
  • Parantunut laajennettavuus
    Mikropalveluja voi lisätä mihin tahansa ketjussa. Skaalaus on nopeaa.
  • Parantunut vikasietoisuus
    Jos yksi mikropalvelu kaatuu, muut palvelut jatkavat työtään.
  • Optimoidut laajentumispäätökset
    Skaalauspäätökset voidaan tehdä moduulitasolla.
  • Oma mikropalvelu kunnossa
    Mikropalvelun rakentaja kantaa huolta vain oman palvelunsa moitteettomasta toiminnasta.
  • Liiketoiminnan ketteryys
    Moduulin vioittuminen vaikuttaa vain ko. palveluun -- nopeat kokeilut mahdollisia .
  • Ylläpito helppoa
    Mikropalveluja on helppo liittää sovellukseen. Ylläpito on mutkatonta.
  • Kehittämisen ja liiketoiminnan yhteistoiminta
    ´ Mikropalvelut peilaavat organisaation toimintoja, kehittäjät ymmärtävät käyttäjien tarpeita.
  • Kestävää arkkitehtuuria
    Kehittyneempi teknologia voidaan päivittää yhdessä moduulissa sen vaikuttamatta koko sovellukseen.
  • 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."
Mikropalvelujen haittapuolia:
Kolikolla on aina kaksi puolta. Alla on listattu Lee Atchinson'ia ja muita mukaellen mikropalvelujen haittapuolia.
  • Mikropalvelut voivat olla monimutkaisia
    Yksittäiset mikropalvelut ovat helposti ylläpidettäviä. Suurem moduulijoukon yhteistoiminta saattaa olla sotkuista.
    Kommentti: Konttien hallintaan on kehitteillä ja olemassa tehokkaita ohjelmistoja, esimerkiksi Kubernetes.
  • 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.
  • Laajuuden arviointi haasteellista
    Sovelluksen koon arviointi on tärkeää. Liian suuri sovellusta on vaikea hallita.
  • Ostettuja palveluja ei voi hallita
    Ulkopuolisten toimittajien moduuleja ei voi kontrolloida. Toimittaja voi muuttaa palvelun rajapintoja (API).
    Kommentti:
    Toisaalta huonosti voi käydä toimittajalle, joka muuttaa palvelunsa yhteisesti sovittuja rajapintoja.
  • Huono suunnittelu voi olla kallista
    Vikasietoisuuden suunnittelu voi olla monimutkaisempaa kuin monoliitissa. Suunnittelussa täytyy ottaa huomioon mm. itsenäisten moduulien kaatumisesta aiheutuvat toipumiset.
  • Hyviä asiantuntijoita on 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. Uuteen tekniikkaan perehtyviltä vaaditaan siinä määrin riskinottoa, että vaaka kallistuu usein tutuille turvallisille vesille.
Kuoppaisesta tiestä huolimatta mikropalvelujen käyttö on kasvussa
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 on kehittämässä Palveluväylään pilvipalveluna liityntäpalvelinta, jonka voi tuoda palvelun kylkeen mikropalveluna ilman tällä hetkellä tarvittavaa palvelininvestointia.

Jouni Jokinen (opiskelee tietojenkäsittelyä Turun yliopistossa) on rakentanut Linux palvelimellemme mikropalvelun konttitekniikkaa käyttäen. -- Tulemme jatkossa kertomaan, mitä arkkitehtuurille kuuluu juuri nyt: Jos olet kiinnostunut esimerkiksi yhteistyöstä, ota yhteyttä heikki.ojala@dianti.fi tai yhteydenottosivu.

Pohja

Yhtiö Yhteydet  Johto  Teknologia
Oy Dianti Ab P. 050 410 7410 Tiina Jokinen Heikki Ojala & Pentti Nieminen
Apilatie 8 A 20 info[ ]dianti.fi P. 041 507 3570 P. 050 410 7410
21530 Paimio tiina.jokinen[ ]dianti.fi heikki.ojala[ ]dianti.fi