Digipalvelut / prosessit Ohjelmistokehitys

Mikropalveluarkkitehtuuri – milloin ja milloin ei?

Jukka Hyvärinen 17.10.2019

Mikropalveluarkkitehtuurilla tarkoitetaan modernia tietojärjestelmäarkkitehtuuria, jossa kokonaisuus on jaettu pieniin ja itsenäisesti toimiviin palveluihin.

Mikropalvelujen ympärillä on ollut paljon hypeä viime vuosina ja myös me olemme olleet kehittämässä useita mikropalvelutoteutuksia hyödyntämällä Microsoft Azuren (PaaS) alustakyvykkyyksiä. Yksi kunnianhimoisimpia tämän alueen hankkeita on työvoimahallinnon uudistamiseen tähtäävän TE-digi-hankkeen järjestelmähanke, jossa olemme kehityskumppanina, ja jossa mikropalveluarkkitehtuuri on ollut keskeisessä roolissa vaativan ja ison hankkeen onnistumisen varmistamisessa.

Useiden projektikokemusten kerryttämänä nyt on hyvä pohtia sitä mihin mikropavelut soveltuvat ja mihin eivät.

Arkkitehtuurin edut

Kun kehitetään laajaa ja vaativaa tietojärjestelmäratkaisua, jolle haetaan pitkää elinkaarta, mikropalvelut ovat potentiaalinen lähestymistapa. Mikropalveluarkkitehtuurissa toimintaympäristön ja tarpeiden muuttuessa kokonaisuuden osa voidaan suoraviivaisesti korvata toisella.

Kun kyseessä on monoliittisemmin kehitetty ratkaisu, käyttötapausten muuttuminen johtaa helposti melko mittavaan ja kalliiseen koodin uudelleenkirjoittamiseen. Tällöin myös järjestelmän regressiotestaustarve voi kasvaa yllättävän suureksi.

Mikropalveluarkkitehtuuri tarjoaa parempaa vikasietoisuutta ja suorituskykyä kuin monoliittinen ratkaisu. Yksittäisillä palveluilla voi olla oma välivarasto (cache), jonka myötä tarvittavat tiedot ja palvelut voidaan tarjota käyttäjälle suorituskykyisesti. 


Lisäksi yksittäisen palvelun käyttökatko ei estä koko palvelun käyttöä. Koska mikropalveluiden kommunikoinointi perustuu asynkronisesti viestijonoihin, vältetään suoria riippuvuuksia järjestelmien välillä. Esimerkiksi, jos käyttäjä tallentaa tietoja ja tietojen hallinnasta vastaava palvelu ei ole käytössä, ei tämän tarvitse näkyä käyttäjälle käyttökokemuksen heikentymisenä.

Kun tietojärjestelmäratkaisun pitää palvella useita erilaisia käyttäjäryhmiä ja tarjota erilaisia käyttöliittymiä, mahdollistaa mikropalveluarkkitehtuuri joustavan käyttöliittymäkehittämisen. Esimerkiksi TE-digi-hankkeen projektissamme, jossa saman datan parissa työskentelevät sekä virkailijat että työnhakijat, voidaan kyseiset käyttöliittymät kehittää hyvin itsenäisesti ja hyödyntäen vain niitä palveluita, joita kunkin kohderyhmän vaatimukset edellyttävät.

Esimerkki mikropalveluarkkitehtuurista monikanavaisessa järjestelmäkokonaisuudessa:

Kehittämisen näkökulmasta mikropalveluarkkitehtuuri mahdollistaa tehokkaasti usean tiimin samanaikaisen kehittämisen. Olivat tiimit sitten eri toimittajilta tai samalta toimittajalta, mikropalveluarkkitehtuurissa tiimit voivat toimia itsenäisti esimerkiksi teknologiavalintojen osalta.


Tämä toki edellyttää toimivan ja skaalavaan kehitysmallin kommunikaation ja kokonaistavoitteita tukevan päätöksenteon varmistamiseksi. Tällainen malli on mm. SAFE, jota meidänkin itseohjautuvat tiimit ovat soveltaneet useissa hankkeissa, kuten edellä mainitussa TE-digihankkeessa ja Outotecin palveluliiketoimminan transformaatioprojekteissa.


twoday-blog-mikropalveluarkkitehtuuri-milloin-ja-milloin-ei



Milloin mikropalvelut eivät ole hyvä idea?

Mikropalveluarkkitehtuuri ei kuitenkaan ole mikään IT-projektien hopealuoti. Arkkitehtuuriin ei kannata suin päin rynnätä kehittäjälähtöisesti, vaan sen soveltuvuutta kannattaa ensin arvioida hankkeen tavoitteiden ja vaatimusten näkökulmasta. Mikropalveluarkkitehtuuri ei välttämättä ole hyvä idea, kun:

  • Vanhaa legacy-järjestelmää ollaan uudistamassa, mutta ei olla varmoja, kuinka pitkä elinkaari järjestelmällä tulee olemaan.
  • Hankkeen budjetoinnissa ei olla huomioitu arkkitehtuurin edellyttämiä investointeja.
  • Hankkeessa ei ole selkeää monitiimi-toimintatapaa tukevaa kehitysmallia (kuten SAFE).
  • Monimutkaisen kokonaisuuden edellyttämään kehittyneeseen julkaisunhallintaan ei ole riittävää kyvykkyyttä osaamisen ja työkalujen puolesta.

Kun samanaikaisesti ymmärretään mikropalveluiden vahvuudet sekä toisaalta tiedostetaan kyseisen arkkitehtuurin edellyttämät budjetti, organisaatio ja kehityksen kypsyystaso, on hyvät eväät valita kunkin hankkeen tavoitteita parhaiten palveleva malli.