Miten hyödyntää mikropalveluarkkitehtuuria keskikokoisissa verkkopalveluissa?
Wunderillakin useammassa digikokonaisuudessa käytetty decoupled-rakenne yhdistää monoliittien ja mikropalveluarkkitehtuurin parhaat puolet. Mitä nämä ominaisuudet ovat ja miten ne voidaan parhaiten valjastaa palvelemaan spesifejä digitaalisia ratkaisukokonaisuuksia?
Ei vain jättiyhtiöille
Olet ehkä viime aikoina kuullut paljon mikropalveluarkkitehtuurista. Aihe on saanut lisänostetta, kun media on kirjoittanut internetjättien, kuten Netflixin tai Amazonin, käyttävän sitä. Todellisuudessa siitä voivat hyötyä myös nettijättejä pienemmät verkkopalvelut, ja itse asiassa moni käyttää sitä jo.
Mikropalveluarkkitehtuuria on myös kritisoitu jonkin verran. Monimutkaiset järjestelmät saattavat koostua sadoista ellei tuhansista sovelluksista, jolloin suorituskykyä kuluu merkittävästi vain järjestelmän sisäiseen kommunikaatioon. Lisäksi virheiden paikallistaminen voi olla haastavaa mikropalveluarkkitehtuurissa, jos eri sovelluksia on suuria määriä. Decoupled puolestaan on mikropalveluarkkitehtuurin hyvin yksinkertainen sovellus. Decoupled-rakenne hyötyy mikropalveluarkkitehtuurin vahvuuksista, muttei kärsi sen heikkouksista.
Mitä mikropalveluarkkitehtuuri on?
Aikaisemmin suurin osa verkkopalveluista rakennettiin monoliittiselle arkkitehtuurille, jossa yksi sovellus huolehtii useimmista tai jopa kaikista verkkopalvelun toiminnoista. Hyvä esimerkki monoliittisesta toteutuksesta on täysin Drupal-alustalle rakennettu verkkopalvelu, joka koostuu käyttöliittymästä, sisällönhallinnan hoitavasta palvelinpuolesta ja sisällön varastoivasta tietokannasta.
Mikropalveluarkkitehtuuri jakaa eri toiminnot yksittäisiksi sovelluksiksi, jotka ovat toisiinsa yhteydessä API:en, eli ohjelmointirajapintojen kautta. Kukin sovellus tekee oman osuutensa kokonaistyöstä, ja niitä voi erikseen kehittää ja skaalata. Lisäksi kunkin sovelluksen voi rakentaa kyseiseen tehtävään parhaiten sopivalla teknologialla. Siinä missä mikropalveluarkkitehtuuri hajauttaa toteutuksen, monoliittinen ei.
Mitä decoupled tarkoittaa?
Decoupled-verkkopalveluissa järjestelmä jaetaan sen eniten merkittäviin osiin, mutta ei sen pienemmiksi palasiksi. Usein vain käyttöliittymä (front-end) erotellaan eri sovellukseksi, ja taustajärjestelmä (backend) on järjestelmän ainut toinen sovellus. Joissain järjestelmissä voi olla sovellus tai pari lisää, kuten integraatiota hoitava sovellus, tai dynaamisen käyttöliittymän sisältöä hallitseva keskitaso (mid-end) käyttöliittymän ja taustajärjestelmän välissä. Backend-järjestelmiä voi myös olla useita. Mutta järjestelmä jaotellaan vain niihin sovelluksiin, jotka antavat järjestelmälle merkittävän edun ollessaan eriytettynä.
Miksi valita mikropalveluarkkitehtuuri?
Se säästää rahaa
Mikropalvelu- ja monoliittisen toteutuksen kehityskustannukset voivat olla samankaltaiset. Hyvin yksinkertaisen verkkopalvelun rakentaminen voi jopa olla edullisempaa toteuttaa monoliittisesti. Decoupled-rakenne osoittautuu kuitenkin järkeväksi investoinniksi, kun järjestelmä alkaa kasvaa yhä monimutkaisemmaksi.
Mikropalvelujärjestelmää voi olla halvempi ylläpitää ja kehittää kuin monoliittista. Jokaista järjestelmän osaa voi muokata erikseen, eikä yhden korjaaminen hajota toista, saati koko järjestelmää. Ei sovi myöskään unohtaa mikropalveluarkkitehtuurin keskeisintä ominaisuutta, eli skaalautuvuutta. Kun yrityksen liiketoiminta kasvaa, decoupled-verkkopalvelun suorituskyvyn kasvattaminen on lähes poikkeuksetta monoliittista edullisempaa. Decoupled-rakenne voi laskea myös hosting- eli käyttöpalvelukuluja.
Kun liikenne palvelussa kasvaa, front-endin skaalaaminen yleensä riittää. Monoliittisessa järjestelmässä jokainen järjestelmän osa pitää puolestaan skaalata, koska niitä ei ole erotettu toisistaan. Decoupled-rakenne on ihanteellinen dynaamiselle hosting-ratkaisulle, kun palveluun kohdistuu liikennepiikkejä vain ajoittain. Silloin palvelu kasvattaa automaattisesti suorituskykyään ja myös skaalaa itsensä automaattisesti alas öisin ja viikonloppuisin. Säästöjä voidaan saavuttaa myös serverless-palveluilla, joiden palveluntarjoajat laskuttavat asiakasta vain käytettyjen resurssien mukaan. Jos sovelluksella ei ole käyttäjiä, kulutkin ovat olemattomat.
Se parantaa käyttäjäkokemusta
Decoupled-rakenne jakaa verkkopalvelun sovelluksiin, joista jokainen on rakennettu suorittamaan oma tehtävänsä optimaalisesti. Esimerkiksi sisällönhallintajärjestelmä (content management system) voi keskittyä vain sisällönhallintaan ja toimia puhtaasti backend-sovelluksena. Tähän tarkoitukseen esimerkiksi Drupal on mainio avoimen lähdekoodin alusta. Sen frontend-ominaisuuksia on kuitenkin joskus kritisoitu rajallisiksi, pääasiassa menneiden versioiden yhteydessä.
Decoupled-järjestelmässä käyttöliittymä voidaan rakentaa käyttämällä tarkoituksenmukaisempia teknologioita, kuten ReactJS:ää. Facebook loi ReactJS:n hyvin pitkälti oman käyttäjäkokemuksensa maksimoimiseen. Maksimaalisella käyttäjäkokemuksella tarkoitan tässä yhteydessä palvelun nopeaa vasteaikaa sekä mahdollisimman monipuolisia ominaisuuksia, jotka mahdollistavat korkealuokkaisen verkkopalvelun ja tyylikkään visuaalisen ulkoasun rakentamisen.
ReactJS ja muut erilliset frontend-sovellukset voidaan optimoida suorituskyvyn maksimoimiseen ja siten tehdä palvelusta mahdollisimman käyttäjäystävällinen. Käyttäjän vuorovaikutus verkkopalvelun kanssa voidaan pelkistää tiedostojen lukemiseen front-endissa, mikä saa palvelun vasteet tuntumaan todella nopeilta verrattuna monoliittiseen toteutukseen, jossa jokainen vuorovaikutus käyttäjän kanssa saattaa edellyttää yhteydenottoa backendiin ja tietokantaan.
Se parantaa tietoturvaa
Decoupled-verkkopalvelussa backendiin ei ole tarvetta rakentaa pääsyä julkisesta internetistä. Jos backend on täysin eristetty internetistä, se on myös hyvin suojattu hakkerointiyrityksiltä. Julkinen frontend-, eli käyttöliittymäsovellus voi olla pelkkä nippu tiedostoja, jotka internetselain lukee. Koska kaikki haavoittuvat osat on eristetty internetistä, palvelun hakkeroimisesta ei ole juuri mitään iloa.
Decoupled-verkkopalvelut ovat myös moniliittisia turvallisempia kehittää edelleen, koska kehitystyö keskittyy aina vain valittuun osaan. Riski, että jotain hajoaa muualla järjestelmässä, on erittäin pieni.
Se ei lukitse tiettyyn palveluntarjoajaan
Tietyn sisällönhallintajärjestelmän (CMS), kuten Drupalin, palveluntarjoajia on yleisesti vain rajallinen määrä, ja heidän osaamistaan tarvitaan jokaiseen muutokseen, joka tehdään monoliittisessa sovelluksessa.
Decoupled-verkkopalvelussa CMS:n, kuten Drupalin, käyttö voidaan rajata vain backendiin. Kaikki muu, kuten käyttöliittymä, voidaan rakentaa käyttämällä esimerkiksi JavaScriptia. Ja tälle teknologialle löytyykin jo useampia palveluntarjoajia.
Mikropalveluarkkitehtuuria voi hyödyntää esimerkiksi näin
Kuten aluksi totesin, Amazonin ja Netflixin kaltaiset internetyhtiöt luottavat mikropalveluarkkitehtuuriin. Se on voi hyvin olla parhaiten toimiva valinta kaikenkokoisille yrityksille. Wunderin asiakkaista mikropalveluarkkitehtuuria hyödyntävät muun muassa Ruutu.fiAvautuu uuteen välilehteen, Traficom.fiAvautuu uuteen välilehteen ja NKL, eli Suomen näkövammaisten liiton uusi verkkosivusto.
Näkövammaisten liiton sivusto rakennettiin perus decoupled-rakenteella, jossa käyttöliittymä (frontend) on eri sovelluksessa kuin sisällönhallintajärjestelmä (backend). Sivustoa ei tehty saavutettavaksi vain lakivelvoitteiden takia, vaan siksi, että suuri osa sivuston käyttäjistä on jonkinasteisesti näkörajoitteisia eivätkä ilman korkeaa saavutettavuutta pysty käyttämään verkkopalvelua. Myös sivuston ylläpitotoiminnot ovat saavutettavia, minkä ansiosta liiton näkörajoitteiset työntekijät voivat ylläpitää verkkosivuston sisältöjä. Käyttöliittymäsovelluksen saavutettavuus rakennettiin ReactJS:llä. Saavutettavat ylläpitotoiminnot puolestaan toteutettiin Drupal CMS:n ominaisuuksilla.
Traficom.fi on myös decoupled-verkkopalvelu, jonka Drupal CMS on täysin eristettynä julkisesta internetistä, vähän kuin intranet ratkaisu. Vain sisäiset käyttäjät pääsevät CMS:ään käsittelemään sisältöä. Päivityksen yhteydessä muutokset palvelun ulkoisesti näkyvään sisältöön replikoidaan palomuurin ulkopuolelle Elasticsearch klusteriin. Tästä NodeJS sovellus hakee käyttäjälle dataa GraphQL:n avulla, ja sisältö näytetään käyttäjälle ReactJS:n avulla. Tämä on aidosti moderni ja erittäin tietoturvallinen ratkaisu.
Ruutu.fi:ssä ReactJS:llä rakennettu frontend-sovellus hakee dataa useista backend-sovelluksista ja piirtää käyttöliittymän näiden tietojen perusteella. Siinä data sisältää mm käyttäjätietoa, sisältöä, sisällön rakennetietoa ja käyttäjän katseluhistoriaa. Palvelu on responsiivinen ja Reactin avulla käyttäytyy mobiiliselaimessa natiivisovelluksen kaltaisesti.
Me Wunderilla uskomme, että yhä useammat yritykset päätyvät valitsemaan jonkinasteisen mikropalveluarkkitehtuurin verkkopalveluilleen.