Skip to Main Content

Mikropalvelut

Mikropalvelut, mitä ne ovat?
Lunastaako mikropalvelut (Microservices) siltä odotetut lupaukset?
Päivitetty 9.12.2023
Selvityksen lähteitä
Linkkejä mikropalveluihin:
  1. Selkeä esitys mikropalveluista (Niklas Wallenius, 2022): Mitä mikropalvelut ovat?
  2. Konttiteknogian uranuurtajan Docker yhtiön kotisivut
  3. Oraclen tuore kuvaus mikropalveluista.
  4. Tuomas Piipon opinnäytetyö (TYY, 6.6.2018) Digikehittäminen ja mikropalvelut Turun kaupungilla
  5. Laadukkaita videoita sivulta TechWorld with Nana (2023)
Mikropalvelut vs. monoliitti
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.
Monoliitti
Monoliitti (vasemmalla) on kompakti kokonaisuus. Mikropalvelut (oikealla) muodostuu itsenäisistä, helposti päivitettävistä moduuleista, konteista.
____________________________
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.
Mitä vikaa on monoliitissä?
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.
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 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.
Kontit paketoivat mikropalvelut
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.
Mikropalvelut paketoituina kontteihin
Mikropalvelut tietokantoineen on pakattu kontteihin. Ne voivat olla itsenäisiä sovelluksia, jotka voi sellaisenaan asentaa asiakkaiden erilaisiin järjestelmiin.
____________________________
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.
Mikropalvelujen hyvät puolet
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."
Haasteita mikropalveluille
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.
Mikropalvelujen käyttö on kasvussa
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.
Sopivatko mikropalvelut Suomeen?
Kyllä! Mikropalvelut sopivat erinomaisesti juuri Suomen kaltaiseen kehittyneeseen, pieneen maahan. Ostamme sadoilla miljoonilla euroilla laajoja järjestelmiä kansainvälisiltä yrityksiltä ja maksamme niistä "suolaisia" ylläpitomaksuja. Usein näin hankitut ohjelmistot ovat lisäksi huonosti toimivia tai sopimattomia maamme toimintakulttuuriin. Ylempänä luvussa on "Mitä vikaa on monoliitissä?" on esitetty syitä ja esimerkki yhdestä epäonnistuneesta hankinnasta.
Suomessa on runsaasti pieniä, muutaman taitavan osaajan miehittämiä IT-yrityksiä, jotka pystyisivät tuntemillaan kehitystyökaluilla rakentamaan yhden tai useamman toimivan osan mikropalveluun. Lisäksi tarvitaan yritys, joka pystyy rakentamaan konttien yhteistoimintaa varten orkestrointi-kerroksen. Sitä varten on olemassa hallintaohjelmistoja, kuten avoimen lähdekoodin Kubernetes.
Mitä Diantin panos voi olla mikropalveluissa?
Yhtiömme on esimerkki edellä kuvatusta pk-yrityksestä, joka voisi rakentaa yhden tai useamman mikropalvelusovellukseen. Meillä on käytössä Oraclen juuri julkaisema, käänteentekevä 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.
Yhtiömme on luonut Oracle Apex low-code kehittimellä isolle kaupungille sen omistamien asuntojen vuokrausohjelmiston Focusa vukraus. Ohjelmistoa on kehitetty vuosi vuodelta yhä paremmaksi. Sovellus sopii erittäin hyvin "kontiksi" mikropalveluun. Lisäksi olemme rakentaneet samalla kehittimellä asiakkuudenhallintaohjelmiston Focusa CRM:n, jossa on mm. rajapinta Netvisor talousohjelmistoon sekä kattava joukkosähköpostitusohjelma. Tietääksemme samanlaista ei ole missään muussa CRM-sovelluksessa. Sekin voi olla osa mikropalvelusovellusta.
Oracle Apex low-code kehittimellä on yllättävän helppo ja nopea rakentaa mikropalveluissa tarvittavia muitakin uusia sovelluksia.

Jouni Jokinen, LuK (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ä, ota yhteyttä

******************************