Mikropalvelut

Mitä ne ovat ja miksi organisaatiosi olisi järkevää käyttää niitä
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, Dianti 7.7.2019
-
Mikropalvelut (Microservices) on näinä päivinä kuuma aihe ohjelmistokehityspiireissä. Ja ihan hyvästä syystä!
Perinteinen tapa rakentaa sovelluksia monoliittisen arkkitehtuurin (kuva alla) avulla on ongelmallista sovellusten yhä suurentuessa ja monimutkaistuessa. Vaihtoehdoksi on tulossa joko SOA (Service Oriented Architecture) eli palvelukeskeinen arkkitehtuuri tai tai vielä pitemmälle granuloinnissa menevät mikropalvelut.
Monoliitti
Monoliitti (vasemmalla) on kompakti ja jäykkä 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 yhteysmuodosta. 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. Vaaka on kallistumassa jälkimmäisen hyväksi.
Kerron, 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älisen jättiläisen rakentamat suuret sovellukset. Suomeen juuri hankittu, kiistelty potilastietojärjestelmä, Apotti on tästä erinomainen esimerrki.
Kaikki saattaa toimia monoliitissa ja käyttäjät ovat tyytyväisiä. Jossain vaiheessa -- ja se on 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 riippumattoman 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äisten kehitystyöryhmien 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. Tämä johtaa hitaampiin, vähemmän luotettaviin sovelluksiin (esimerkkinä Apotti).
Skenaario ei ole väistämätön. Sovellus voidaan rakentaa ja suunnitella niin, että se vastaa organisaation tarpeita nyt ja pitkälle tulevaisuuteen. Nykyaikainen mikropalvelupohjainen arkkitehtuuri on varteenotettava tekniikka laajentuvien sovellusten rakentamiseen.
Edellä esitetty ei tietenkään tarkoita sitä, että käytössä oleva, hyvin toimiva monoliittinen sovellus pitäisi korvata jollain muulla. Se ei olisi järkevää. Sen sijaan uusien sovellusten suunnittelijoiden kannattaa harkita mikropalveluita todellisena vaihtoehtona.
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 monoliitti.
____________________________
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. 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 palvelu voi sijaita internetin etäpalvelimella. 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, jotka voivat olla itsenäisiä sovelluksia.
____________________________
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. Tästä löydät eri konttialustojen vertailuja.
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ä.
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.
Lee Atchinson 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 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 Lee Atchinson'ia mukaellen mikropalvelujen haittapuolia.
  • Mikropalvelut voivat olla monimutkaisia
    Yksittäiset mikropalvelut on helposti ylläpidettäviä. Suurem moduulijoukon yhteistoiminta saattaa olla sotkuista.
    Kommentti: Konttien hallintaan on tehokkaita ohjelmistoja, esimerkiksi Kubernetes.
  • Vaativat huolellisen suunnittelun
    Sovelluksen suunnittelu on pakostakin perinpohjaista. Rakentaminen voi vaatia iteraatiokierroksia.
  • Laajuuden arviointi haasteellista
    Sovelluksen koon arviointi on tärkeää. Liian suuri sovellus on vaikea hallita.
  • Ostettuja palveluja ei voi hallita
    Kommentti:
    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 itsenäisten moduulien kaatumisesta aiheutuvat toipumiset.
Mikropalvelujen edut ovat tutkitusti haittoja painavammat
Hyvin suunniteltu mikropalveluarkkitehtuuri mahdollistaa sovelluksen joustavan laajentamisen. Samalla vältytään rakentamasta raskassoutuinen sovellus, jonka uudistaminen on työlästä. Lee Atchinson puhuu tässä yhteydessä "kömpelöstä hirviöstä".
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.
Mikropalvelut on jo näyttänyt kyntensä moderneissa IT organisaatioissa. Isot monoliittiset järjestelmät eivät rakenteensa vuoksi kykene vastaamaan kaikkiin, jatkuvassa kehityksessä olevien tietojärjestelmien tarpeisiin.
Mikropalveluihin ja kontteihin perustuva arkkitehtuuri alkaa olla kypsä vakavasti otettavaksi myös Suomessa. On mahdollista päästä markkinatilanteeseen, jossa, toisin kuin nyt, pienetkin kotimaiset IT yritykset voivat menestyksellisesti kilpailla kansainvälisten IT-jättien kanssa. Arkkitehtuuri on nähty tärkeäksi myös julkishallinnossa.

Jouni Jokinen (18 v. abiturientti) on rakentanut Linux palvelimellemme mikropalveluja konttitekniikkaa käyttäen. -- Ota yhteyttä, tulemme kertomaan, mitä arkkitehtuurille kuuluu juuri nyt: heikki.ojala@dianti.fi tai yhteydenottosivu.