Search:

MINI- VAI MIKROPALVELU?

Mini- vai mikropalvelu?

Mistä kaikki alkoi?


Palvelukeskeinen arkkitehtuuri (SOA) kehittyi toistakymmentä vuotta sitten. Sen tarkoitus on piilottaa eri-ikäiset ja kykyiset liiketoimintajärjestelmät ja julkaista niistä yleiskäyttöisiä teknisiä liiketoimintapalveluita (service). Yhdessä projektissa tehtävät palvelurajapinnat ovat näin käytössä seuraavassa, jolloin kokonaiskulut pienenevät. Palveluiden granulariteetti, eli julkaistavan käsitteen taso ja koko, oli alussa tyypillisesti suuri. Esimerkiksi asiakastiedot tai tilauspalvelu. Näitä kutsumme makropalveluiksi.

Makropalveluiden ongelmaksi muodostui monesti liiallinen yleiskäyttöisyyden tavoittelu ja monoliittisyys. Usein myös sisäinen tietomalli kanonisointiin yhteinäiseksi koko organisaatiossa. Kanonisointi tarkoittaa sitä, että tieto-olento asiakas näyttää kaikkine satoine attribuutteineen samalta tarvittiin sitä missä yhteydessä tahansa. Tulokset yleiskäyttöisyyden suhteen olivat parhaimmillaan loistavia, mutta yleensä laskun maksaja yllättyi loppusumman suuruudesta ja liiketoiminta oli jo puolessa välissä hermostunut makropalvelun kehittämisen hitauteen. Usein myös tällainen palvelu saattoi vanheta nopeasti liiketoiminnan kehittyessä nopeasti.
Tee makropalvelu kun...
  • Palvelun yleiskäyttöisyyden maksimointi on tärkeää
  • Palvelun toteuttamiseen saa kulua aikaa
  • Palvelu rakentuu vähän muuttuvien monoliittisten taustajärjestelmien varaan

Mikropalveluiden synty

Viime vuosina on suosiotaan on kasvattanut mikropalveluarkkitehtuuri (MSA - micro service architecture), joka monella tapaa pitää sisällään parhaat opit siitä, miten palveluarkkitehtuuria kannatti kehittää: sopivan pieniä palveluita, jotka pyörivät täysin itsenäisesti ja joiden tuotantoon otto (deployment) onnistuu myös ilman riippuvuuksia toisista palveluista tai järjestelmistä. Mikropalveluiden luonteeseen kuuluu myös muista palveluista riippumaton skaalautuvuus. Tästä syystä pilvialustat ovat luonteva itsessään skaalautuva alusta niiden rakentamiseen.

Mikropalveluarkkitehtuuri sisältää myös paljon nykyorganisaatioille disruptiivisia piirteitä, joista haastavin lienee se, että mikropalvelun tulee omistaa oma liiketoimintafunktion tietonsa. Ollakseen täysin riippumaton, itsenäinen ja skaalautuva, mikropalvelussa ei voi dogmaattisen tulkinnan mukaan olla riippuvaisuuksia (decoupled). Mikropalvelu ei voi nojautua ydintietonsa suhteen esimerkiksi liiketoiminnanohjausjärjestelmään tai asiakastietojärjestelmään eikä mihinkään muuhunkaan. Tästä syystä mikropalveluarkkitehtuurin toteuttaminen vaatii merkittävän muutoksen totuttuun ajatteluun ja järjestelmien suunnitteluun.

Parhaimmillaan se onkin, kun luodaan kokonaan uutta tietojärjestelmien varaan rakentuvaa liiketoimintasovellusta. Dogmaattinen tulkinta mikropalveluista tarkoittaa siis sitä, että se on täysin riippumaton (decoupled) muista palveluista tai rajapinnoista. Tämä käytännössä tarkoittaa sitä, että jokaisella minipalvelulla on oltava oma tietovarastonsa. Mikropalveluiden fundamentaaleimmissa vaatimuksissa myöskään kehitintä tai kieltä ei saa rajoittaa.

Mikropalveluarkkitehtuuri sopii hyvin, kun rakennetaan kokonaan uutta ja tehdään jotain, missä ei ole tarkoitus käyttää alustana muita valmisohjelmistoja. Tunnetuin esimerkki mikropalveluarkkitehtuurin perustuvasta ratkaisusta on Netflix.

Tee mikropalvelu kun...
  • Palvelun markkinoille saamisen nopeus (time-to-market) on tärkeintä
  • Täydellinen riippumaton skaalautuvuus on vaatimus
  • Yleiskäyttöisyys ei ole tärkeintä
  • Olet kehittämässä uutta sovellusta tai verkkopalvelua ilman valmiita taustasovelluksia
  • Haluat palvelutuotantosi tukeutuvan DevOps -malliin

Minipalvelut

Minipalvelu termi syntyi makro- ja mikropalveluiden välimaastoon. Yksinkertaistettuna minipalvelu on pääosin kuin mikropalvelu ilman vaadetta täydellisestä riippumattomuudesta: minipalvelu saa olla löyhästi riippuvainen (loosely coupled) muista järjestelmistä ja rajapinnoista.

Yhtälailla minipalvelu voi tarvittaessa omistaa tietonsa, eli sisältää oman tietovaraston. Usein palvelun raekoko - eli kuinka suuria kokonaisuuksia palvelu sisältää - on myös makro- ja mikro palvelun välissä. Myös minipalvelun - kuten mikropalvelunkin - tulee olla itsenäisesti asennettavissa ja mahdollisimman skaalautuva. Toisin kuin mikropalveluissa, skaalautumisessa tulee kuitenkin huomioida löyhienkin riippuvuuksien tuomat rajoitteet: skaalautuko alla oleva järjestelmä minipalvelun mukana vai tarvitaanko taustajärjestelmästä tai palvelusta riippuvaisuuden katkaiseva välitietovarasto.

Monesti näkeekin toimittajien markkinoivan mikropalveluitaan, kun tosiasiassa sisältä paljastuukin minipalvelu löyhine riippuvaisuuksineen. Tätä kutsutaan englanninkielisellä termillä "microservice-washing".

Tee minipalvelu kun...
  • Yleiskäyttöisyys on tärkeää
  • Palvelun markkinoille saamisen nopeus (time-to-market) on olennaista
  • Rakennat palveluita olemassa olevien järjestelmien päälle
  • Haluat palvelutuotantosi tukeutuvan DevOps -malliin

Mini vai mirkopalvelut_blogi_kuva_01.jpg

Palveluarkkitehtuurien lähitulevaisuus

Gartner arvioi "Innovation Insight for Miniservices" -julkaisussaan minipalveluiden olevan seuraava arkkitehtuuriparadigma, josta tulee hitti vuosien 2018 ja 2019 aikana. Minipalvelut edustavat pragmaattista nyky-ympäristön huomioon ottavaa arkkitehtuuria, joka vastaa hyvin digitalisoituvan maailman tarpeisiin. Esimerkiksi mobiilisovelluksen oman vanhan liiketoiminnan tueksi kehittävä yritys ei ole välttämättä valmis samalla siirtämään muita ydinjärjestelmiään museoon mikropalveluiden tieltä. 


SOA:n perillisten - makro-, mini- ja mikropalveluiden lisäksi lanseerattu termi nanopalvelu. Sillä tarkoitetaan usein liian pientä raekokoa - esimerkiksi yksittäinen funktion julkaisemista palvelukerroksessa. Esimerkiksi receiveOrder -palvelu voisi olla mini- tai mikropalvelu. Jos sen sisältä nostetaan omaksi palvelukseen validateEmailAddress -palvelu, voidaan puhua nanopalvelusta. Onko se väärin tai oikein? Sitä ei voi ilman kontekstia tuomita, mutta usein funktiotason nosto palvelukerrokseen on merkki liian pienestä raekoosta, joka tekee palvelun käytöstä hitaampaa ja luo turhaan toisistaan riippuivaisia palveluita.

EDIT: 22.9.2018

Tässä kuluneen vuoden aikana on tullut vastaan useampi Suomen mittakaavassa järeä organisaatio, jotka ovat rakentaneet digitalisaationsa suoraan pelkästään mikropalveluiden ja pilvialustan varaan. Tiimit ovat olleet nykyaikaisia DevOps -tiimejä. Muutaman vuoden sisään nämä organisaatiot ovat huomanneet tehneensä mikropalveluspagetin ja hukanneet valmistuotteiden hyödyt. Kulut tiimeistä ovat hurjat ja DevOps -tiimikin keskittyy pääosin Opsiin kun aikaa ei Deviin enää riitä. Lähtisin itse katsomaan asiaa ns. SweetSpot -arkkitehtuurikulmalla - siinä organisaatio valitsee etukäteen hyvin tarkkaan milloin käyttää mikropalveluita (hyödyt vrt. kulut) ja milloin minipalveluita. 


Lähteet:


1. *Innovation Insight for Miniservices, 21.2.2017, Anne Thomas, Aashish Gupta* (vaatii maksullisen Gartner -palvelun)

Antti Toivanen

antti.toivanen@hiq.fi
Kirjoittaja on HiQ:n integraatiotoiminnoista vastaava vetäjä 22 vuoden integraatiokokemuksella ja lupsakalla luonteella.

Haluatko meille töihin?

Olemme digitaalisen ajan käsityölaisiä ja suhtaudumme työhömme intohimolla. Meillä pääset toteuttamaan upeita projekteja Suomen suurimmille yrityksille sekä luomaan kokonaan uusia, markkinoita muuttavia palveluita. Töihin HiQ:lle? HiQ kasvaa ja etsimme aktiivisesti joukkoomme uusia osaajia!

Ota yhteyttä!