Microservices eli mikropalvelut ovat nousseet pinnalle modernin sovellusarkkitehtuurin rakentamisessa. Sovellusten löyhät sisäiset sidokset, modulaarisuus, skaalautuvuus sekä avoimuus ovat mikropalveluissa keskeisiä teemoja.
Onko tämä kuitenkaan uutta? Voidaan sanoa, että mikropalveluratkaisut ovat olleet käytössä jo siitä asti, kun internet-teknologiat mahdollistivat verkkosovellusten rakentamisen. Jo 2000-luvun alussa toteutettiin verkkosovelluksia, joissa frontin ja backendin rajapinta oli toteutettu eräänlaisilla avoimilla rajapinnoilla. Esimerkiksi Progress Webspeed -arkkitehtuurissa staattinen html-sivu ja siihen liittyvä sovelluslogiikka olivat erotettuna omiksi moduuleikseen sovelluspalvelimella. JSONista ja RESTistä ei silloin vielä puhuttu, mutta modulaarisuus ja löyhät sidokset olivat vahvasti mukana. Esimerkkejä löytyy varmasti paljon muitakin.
API-teknologia
API-tuotteiden ja teknologian kehityksen myötä löyhät liitokset it-arkkitehtuurissa ovat tulleet lähemmäs hallittua IT:n kehitystä. Mutta, mitä Mikropalvelu-pohjaiset sovellukset sitten loppujen lopuksi ovat? Pieniä palveluita, funktioita ja avoimia rajapintoja. Nopeasti rakennettavia toteutuksia. Mikropalvelut voidaan yleistäen määritellä helposti ylläpidettäväksi ja testattavaksi, löyhästi kytketyksi, itsenäisesti julkaistavaksi, liiketoimintalähtöiseksi palveluiksi, joiden omistajuus on kehittäjätiimillä. Arkkitehtuurin lähtökohta on pilvipohjaisessa sovellusarkkitehtuurissa, jossa yksittäinen sovellus rakentuu löyhät sidokset mahdollistavista, itsenäisesti julkaistavista moduuleista, tai palveluista.
Kuva 1. Mikropalveluarkkitehtuuri
Näillä palveluilla on tyypillisesti oma sovelluskerros, mukaan lukien tietokanta ja tietomalli. Palvelut kommunikoivat REST APIen avulla tapahtumapohjaisesti sovelluspalvelimia hyödyntäen täyttäen yhden tai rajallisen määrän liiketoimintatarpeita.
Vaikka suuri osa mikropalveluista käytävästä keskustelusta on kiertänyt arkkitehtonisten määritelmien ja ominaisuuksien ympärillä, niiden arvo voidaan ymmärtää yleisemmin melko yksinkertaisilla liiketoiminnallisilla ja organisatorisilla eduilla:
- koodia voidaan ylläpitää helposti,
- tiimit voivat käyttää omia käyttötarkoitukseen parhaiten soveltuvia teknologioitaan tai komponentteja,
- sovellusten osat voidaan skaalata itsenäisesti.
KAAOS?
Syntyykö mikropalveluarkkitehtuurilla sitten sekasortoa vai järjestystä? Selvien etujen lisäksi mikropalvelut luovat myös haasteita arkkitehtuurin hallintaan. Miten hoidetaan tietoturva ja pääsynhallinta? Entä miten palvelut orkestroidaan ja sovelluskehityksen isokuva säilyy? Onko loppukäyttäjillä olemassa yksi yhteinen käyttökokemus (ei ainoastaan käyttöliittymä), riippumatta siitä mitä sovelluksen tai palvelun osaa he käyttävät? Tehdäänkö päällekkäistä työtä, jos samoja asioita ratkotaan eri tiimien ja sovellusten toimesta jne. Yhtä vastausta ei ole. Tuotteet ja arkkitehtuuriset näkökulmat pyrkivät tässäkin tapauksessa tarjoamaan ratkaisun tämähän dilemmaan. API Gateway, Service Mesh, ja niin edelleen.
Kuva 2. Mikropalvelutarkkitehtuuri ja API Gateway
MITEN HYÖDYNNÄN?
Miten pääsen alkuun mikropalvelupohjaisessa sovelluskehityksessä? Alkuun pääseminen ei luonnollisestikaan tarkoita koko IT-arkkitehtuurin uusimista kerralla. ”Think big and start small” toimii tässäkin. Verkkopalvelun rakentaminen on mikropalvelua parhaimmillaan. Legacy-sovelluksen jonkin toiminteen avaaminen verkkosovelluksen käyttöön tarjoaa sovelluskehityksellä lisää vaihtoehtoja…
Esimerkiksi jos verkkokaupan tuoteluettelo replikoinnin sijaan toteutetaankin mikropalveluina legacy-järjestelmästä, vältytään monelta päänvaivalta. Miten sitten avaan legacy-järjestelmän rajapinnan? Sovellus voi olla esimerkiksi itse rakennettu C#-ohjelma, joka toteuttaa liittymän legacy-järjestelmään, ja tarjoaa samanaikaisesti REST-rajapinnan ulospäin IT-arkkitehtuurin käyttöön kevyen http-serverin (esim. Nginx) avulla. Ratkaisu voi luonnollisesti pohjautua myös valmistuotteisiin. Lähes kaikki API Gateway -tuotteet toteuttavatkin mikropalveluita tai ainakin puhuvat siitä. API-tuotteet tarjoavat orkestrointia, pääsynhallintaa, kuormantasausta, tietoturvaa sekä laajan määrän rajapintoja taustajärjestelemiin. Eli juuri sitä miten Mikropalvelut määritelään.
Jos haluat heti tietää miten Netum on iPaaS-integraatiokonseptissaan hyödyntänyt mikropalveluarkkitehtuuria, ole yhteydessä.
Tero Nummijärvi
Netum Oy
p. +358405610120
E-mail: tero.nummijarvi(at)netum.fi
Seuraavassa blogissa käsittelemme tarkemmin API Gateway ja Service Mesh -näkökulmia sekä miten kontitus vaikuttaa toteuttamistapoihin mikropalveluarkkitehtuurissa.
Muutamia linkkejä:
https://microservices.io/
https://www.axway.com/sites/default/files/datasheet_files/axway_datasheet_api-gateway_en.pdf https://smartbear.com/solutions/microservices/
https://www.nginx.com/blog/what-is-a-service-mesh/