Mikropalveluarkkitehtuuri – milloin ja milloin ei?

Blogi Kirjoittanut:
Digital Illustratedilla olemme olleet kehittämässä useita mikropalvelutoteutuksia hyödyntämällä Microsoft Azuren (PaaS) alustakyvykkyyksiä. Useiden projektikokemusten kerryttämänä on hyvä pohtia, sitä mihin mikropavelut soveltuvat ja mihin eivät.

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 Digital Illustratedilla 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. Monoliittisemmin kehitetyn ratkaisun tapauksessa käyttötapausten muuttuminen johtaa helpolla 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), minkä 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öä. Mikropalveluiden kommunikoinoinnin perustuessa asynkronisesti viestijonoihin, vältetään suoria riippuvuuksia järjestelmien välillä – esim. 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. Esim. TE-digi-hankkeen projektissamme, jossa saman datan parissa työskentelevät mm. virkailijat ja 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 taikka samalta toimittajalta, mikropalveluarkkitehtuurissa tiimit voivat toimia itsenäisti mm. 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 Digital Illustratedinkin itseohjautuvat tiimit ovat soveltaneet useissa hankkeissa kuten edellä mainitussa TE-digihankkeessa ja Outotecin palveluliiketoimminan transformaatioprojekteissa.

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 sijaan 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 ole 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.

Yhteenveto

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.