Mini- vai mikropalvelu?

Mikropalvelu vai minipalvelu?

Tämä artikkeli käsittelee mikro- ja minipalveluiden eroja ja nykyaikaisen integraatioalustan mahdollisuuksia. Se on tarkoitettu integraatio-osaajille ja EA-arkkitehdeille.

Mistä mikropalvelut saivat alkunsa?

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 - usein jo liian pitkän syntyprosessin aikana. Uusien makropalveluiden kehittämisestä on laajalti luovuttu.

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 itsenäisesti. 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. Toisin päin - ollakseen täydellisesti vaikkapa konttiympäristössä skaalautuva - se ei voi olla riippuvainen vaikkapa ERPistä. Ollakseen täysin riippumaton, itsenäinen ja skaalautuva, mikropalvelussa ei siis voi puritaanisen tulkinnan mukaan olla riippuvaisuuksia vaan sen on täysin riippumaton muista järjestelmistä (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. Puritaanien 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.

Kehittämällämme Frends-integraatioalustalla voi rakentaa ja julkaista mikropalveluita. Puritaanisen mikropalveluiden määritelmän mukaan frends:kin on vain kehitin, joka tukee CI/CD-prosesseja ja mahdollistaa kontitusympäristössä tarpeen mukaan joustavasti skaalautuvan APIn kehityksen, suorituksen ja hallinnan.

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

Minipalvelu

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 mikropalvelun välissä tai lähellä mikropalvelua. 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. Lähes aina rajan skaalautumiselle muodostaakin kytketyt legacy-järjestelmät ja niiden rajapintojen ja tietovarastojen skaalautumattomuus ja suorituskyky. Monesti näkeekin toimittajien markkinoivan mikropalveluitaan, kun tosiasiassa sisältä paljastuukin minipalvelu löyhine riippuvaisuuksineen. Tätä kutsutaan englanninkielisellä termillä "microservice-washing". Tätä tehdään kahdesta syystä: ei olla ymmärretty mitä mikropalvelu todella tarkoittaa tai halutaan tietoisesti trendikäs termi omaan markkinointiin käyttöön.

Kehittämällämme frends-integraatioalustalla on tehty minipalveluita jo toistakymmentä vuotta aina SOAP-pohjaisten webservice -muotoisten palveluiden alusta saakka. Nykypäivänä frends onkin modernein markkinoilla oleva API-alusta, joka tarvittaessa toimii mikropalvelualustana tai minipalvelualustana. Olisikin tärkeää ymmärtää, että esimerkiksi minipalvelukyvykkyys ei ole mikään erillinen alueensa vaan yksi osa integraatioalustan kyvykkyyksiä.

Joskus myös minipalvelu voi olla kokoava komposiittipalvelu, eli sellainen joka sisäisesti kokoaa liiketoimintafunktion monesta eri järjestelmästä ja vaikkapa pienemmän granulariteetin mikropalveluista.

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

Palveluarkkitehtuurien lähitulevaisuus

Gartner ennusti "Innovation Insight for Miniservices" -julkaisussaan minipalveluiden olevan seuraava arkkitehtuuriparadigma, josta tulee hitti vuosien 2018 ja 2019 aikana. Historia todistaa, että ei niistä hittiä tullut, vaan minipalvelut ujuttautuivat osaksi integraatiokehittämisen arkea. 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.

Lähteet: *Innovation Insight for Miniservices, 21.2.2017, Anne Thomas, Aashish Gupta* (vaatii maksullisen Gartner -palvelun)

*Microservices, 25.3.2014, Martin Fowler, https://martinfowler.com/articles/microservices.html