Mikropalvelut ratkaisuna digitalisaation haasteisiin

Kuten kuvasta voi huomata, mikropalveluiden perusideana on luoda joukko itsenäisiä tarkasti käyttötarkoituksen mukaan rajattuja sovelluksia, jotka yhdessä muodostavat isompia kokonaisuuksia. Esimerkiksi verkkokauppa voisi koostua tilaus-, asiakasdata-, ostoskori-, arvostelumikropalveluista jne. Huomattavaa tässä on se, että esimerkiksi kerran kehitettyä arvostelumikropalvelua voitaisiin hyödyntää minkä tahansa muun järjestelmän peruskomponenttina joustavasti rajapinnan kautta. Näin ollen samoja kyvykkyyksiä ei enää rakenneta moniin eri monoliittisiin järjestelmiin.

Kuvassa vasemmalla esim. ERP ja CRM perinteisinä järjestelminä, oikealla mikropalveluihin perustuva skaalautuva pilvialusta, jonka päälle voidaan tehdä erilaisia näkymiä(esimerkiksi selaimessa toimivia) edustamaan vaikkapa CRM- tai ERP-käyttöliittymiä.

Miksi siirtyä käyttämään mikropalveluihin perustuvaa arkkitehtuuria?

Serveri-infran näkökulma:

• Jokaista järjestelmän osaa voidaan (automaatti)skaalata toisistaan riippumatta. Näin ollen esimerkiksi jos tilauksia tulee paljon, koko järjestelmä ei hidastu ja pahimmillaan mene jumiin, vaan sen sijaan korkean kuormituksen komponenttia voidaan skaalata joustavasti.
• Jokaisella palvelulla voi olla oma SLA kriittisyyden mukaan. Järjestelmän ei-kriittisten osien kahdennus tai HA-toteutus ei tarvitse olla samaa luokkaa kuin tärkeiden osien.

Ohjelmistokehityksen näkökulma:

• Mikropalveluiden tapauksessa jokaista palvelua voi kehittää oma porukkansa. Tällöin vastuu jakautuu selkeämmin, ja tiimeille voidaan asettaa vaikkapa mikropalvelukohtaisia KPI:tä. Kun tiimi on vastuussa yhdestä kokonaisuudesta eikä esim epämääräisestä osasta suurta järjestelmää, vastuunotto tapahtuu luonnostaan. Sen sijaan, että asioita pallotellaan eri spesialistien kesken, ovat tiimit itsenäisesti vastuussa komponentin toimivuudesta.
• Toimittajariippumattomuus. Koska mikropalvelut toteutetaan yleisten ohjelmistokehityksen periaatteiden mukaan, eivätkä ne perustu mihinkään tiettyyn alustaan, vastuuta voidaan eri tiimien lisäksi jakaa eri toimittajien kesken. Tällöin asiakas ei ole riippuvainen enää esimerkiksi tietystä alustatoimittajasta, ja tämä kannustaa toimittajia tekemään parempaa jälkeä.
• Koska jokainen mikropalvelu on oma pieni kokonaisutensa, voidaan jokaiseen palveluun valita soveltuva ohjelmointikieli sekä muut teknologiaratkaisut. Esimerkiksi, jos komponentti vaatisi salamannopeaa reaaliaikaisuutta, voitaisiin käyttää vaikkapa C++-ohjelmointikieltä, järjestelmän muiden osien ollessa Javaa, PHP:tä, Javasscriptiä tai muuta soveltuvaa teknologiaa. Tämä lisää joustavuutta ja kehityksen tehiokkuutta huomattavasti.
• Mikropalveluiden kehittäminen mahdollistaa sen, että järjestelmän montaa eri osa-aluetta kehitetään samaan aikaan toisistaan riippumattomasti. Mikropalvelut soveltuvat erityisen hyvin nykyaikaiseen joustavaan ohjelmistokehitykseen, sekä erityisesti nk. Continuous Deployment -malliin, jossa suurien versiopäivitysten sijaan palveluita kehitetään jatkuvasti, ja uusia ominaisuuksia ja muutoksia lisätään jopa päivittäin.

Edelliset kohdat ottivat kantaa lähinnä teknologisiin ja ohjelmistokehityksen kysymyksiin. Ehkäpä kiinnostavinta asiakasyrityksen kannalta ovat kuitenkin business-hyödyt. Mikropalveluiden käyttämisen eduksi voidaan laskea ainakin seuraavat liiketoimintaan kiinteästi liittyvät asiat:

• Sen sijaan että asiakastietoa tai muita toiminnallisia komponentteja monistettaisiin moneen eri järjestelmään, mikropalveluarkkitehtuurissa on kuhunkin tarpeeseen yksi tiukasti rajattu järjestelmä, joka hoitaa tämän osa-alueen. Tätä järjestelmää voidaan skaalata käytön mukaan, ja vaativia käyttötapauksia tukeakseen mikropalvelut kommunikoivat keskenään. Näin ollen ei tarvita suuria järjestelmäintegraatioita. Esimerkkinä mikropalveluiden päälle toteutettu verkkokauppa on vain näkymä, jota pyörittävät taustalla eri mikropalveluiden logiikat, joiden kanssa näkymä keskustelee.
• Jokaista osasta voidaan päivittää riippumattomasti ja kevyesti. (viitaten aiemmin läpikäytyyn Continuous Deployment -malliin, jossa tehdään koko ajan pieniä päivityksiä). Näin ollen ei enää tarvita kalliita ja virheherkkiä järjestelmäpäivityksiä, jotka ovat yleensä mittavia projekteja, vaan mikropalveluja kehitetään jatkuvasti tarpeen mukaan. Yksi "palikka" on myös helppo vaihtaa kokonaan.
• On paljon helpompaa kokeilla uusia palveluja ja business-logiikoita, kun voidaan tehdä esim yksi uusi mikropalvelu kevyesti, ja jos se ei toimi niin voidaan ketterästi kokeilla jotain muuta. Tämä ei ole millään mahdollista monoliittisten järjestelmien kanssa, tai ainakaan järkevää.
• Yksi tärkeimmistä business-hyödyistä on mikropalveluiden kehittäminen reaalimaailman rajoitteita ja ominaisuuksia”vastaaviksi. Toisin sanoen järjestelmien toimintalogiikat mallinnetaan niin, että ne toteuttavat suoraan yrityksen toimivaa business-logiikkaa. Monoliittisten järjestelmien maailmassa on usein niin, että alustaa aletaan väkisin taivuttaa johonkin suuntaan. Tämä usein vaatii suuria muutoksia monissa eri osissa. Samaten jos muutoksia halutaan tehdä, niin useasti tämä aiheuttaa järjestelmävirheiden tai -muutosten ketjureaktion. Mikropalvelut sen sijaan ovat hyvin joustavia ja hyvin pieniin loogisiin kokonaisuuksiin jaettuja, jolloin niillä pystytään mallintamaan business ja sen tarpeet huomattavasti ketterämmin. Ideana on, että jokainen palvelu toteuttaa oman business-sovellutuksensa.