Mitä tarkoittaa MACH-arkkitehtuuri?

Composable commerce on laajempi filosofinen lähestymistapa verkkokaupan toteutukseen. Tässä osassa pureudumme tarkemmin sen käytännön toteutukseen, joka noudattaa niin sanottua MACH-arkkitehtuuria.

Composable commerce -artikkelisarjan aiemmassa osassa käsittelimme lähestymistavan hyötyjä ja haittoja ylätasolla ja liiketoiminnan näkökulmasta. Jos et ole lukenut aiempaa artikkeliamme, löydät siinä esitellyt termit myös tämän artikkelin lopusta.

MACH-arkkitehtuuri

MACH-arkkitehtuurissa kokonaisuus rakennetaan toisistaan riippumattomista mikropalveluista, jotka kommunikoivat keskenään rajapintojen (API) avulla. Arkkitehtuuri noudattaa neljää pääperiaatetta, joista termi MACH muodostuu:

• Microservices: Kokonaisuus rakennetaan itsenäisistä mikropalveluista, jotka vastaavat tietystä selkeästi rajatusta tehtävästä.

• API-First: Eri mikropalvelut kommunikoivat keskenään rajapintojen avulla.

• Cloud-native: Mikropalvelut ovat pilvipohjaisia, mikä mahdollistaa skaalautuvuuden. 

• Headless: Kokonaisuus käyttää headless-teknologiaa. Niissä frontend (esityskerros) ja backend (taustajärjestelmä) ovat aina erillisiä, ja järjestelmän osat viestivät keskenään rajapintojen välityksellä. 

Mikropalvelut

Mikropalvelulla viitataan itsenäisesti toimivaan palveluun, jonka tarkoitus on suorittaa jokin selkeästi rajattu tehtävä. 

Jotta abstrakti konsepti aukeaisi paremmin, käytämme esimerkkinä (tietenkin) kuurakettia. Saturn V raketin tehtävänä oli kuljettaa onnistuneesti kuuhun laskeutunut Apollo 11 -avaruusalus maan vetovoiman ulottumattomiin kolmen moduulin avulla. Kukin moduuli oli ikään kuin oma pienoisraketti omine polttoainesäiliöineen ja rakettimoottoreineen. Kun moduuli oli suorittanut tehtävänsä, se tiputettiin kylmän viileästi matkasta.

Raketin moduulin ja mikropalvelun yhdistävä tekijä on, että kukin moduuli kykenee suorittamaan oman tehtävänsä itsenäisesti. Perille pääsy edellyttää kuitenkin, että kaikki moduulit toimivat yhdeistyössä keskenään.

Koska Saturn V -raketti koostui ikään kuin kolmesta pienemmästä raketista, voit ajatella, että kukin mikropalvelu on ikään kuin oma pieni tietokone. 

Verkkokaupan kontekstissa yksittäisen mikropalvelun tehtävä voisi olla esimerkiksi vastata tuotetiedon hallinnasta, ostoskorista tai maksuista. Kuvitellaan, että olet ostamassa verkkokaupasta uuden avaruuspuvun. Selaat ensin eri vaihtoehtoja. Pukujen kuvaukset, hinnat, kuvat ja muut tiedot haetaan tuotehallinnan mikropalvelusta. Lisäät sen jälkeen puvun ostoskoriin, josta vastaa oma mikropalvelu. Ostoskorin tehtävä on muistaa valitsemasi tuotteen tuotekoodi, kappalemäärä ja hinta. Siirryt lopulta kassalle, jossa veloituksesta vastaava mikropalvelu veloittaa luottokorttiasi. Veloituksista vastaava mikropalvelu tarvitsee jälleen kerran edellistä vaihetta vähemmän tietoa - sille riittää tilauksen loppusumma ja veloitettavan luottokortin tiedot.

Perinteiseen monoliittiseen ratkaisuun nähden mikropalveluarkkitehtuuri mahdollistaa kunkin mikropalvelun kehittämisen ja skaalauksen toisistaan erillään. Kuvitellaan, että tilauksen veloitus vie aivan liian kauan aikaa. Monoliittisessa arkkitehtuurissa joutuisit kasvattamaan koko kaupan suorituskykyä, vaikka hitaus liittyi vain veloitukseen. Mikropalveluarkkitehtuurissa riittää, että kasvatat sen mikropalvelun suorituskykyä, joka vastaa maksujen käsittelystä.

Rajapinnat eli APIt

Mikropalvelut viestivät keskenään rajapintojen avulla. Rajapinnan kautta muut mikropalvelut voivat esimerkiksi pyytää tietoa tai käskeä mikropalvelua suorittamaan jonkin tehtävän. Esimerkiksi maksuista vastaavaa mikropalvelua voidaan rajapinnan avulla käskeä tekemään tietyn suuruinen veloitusta tietyltä luottokortilta. Palvelu vastaa pyyntöön, joko kertomalla, että veloitus onnistui tai toteamalla esimerkiksi, että kortilla ei ollut katetta.

Rajapinnat piilottavat varsinaisen logiikan alleen. Veloitusta pyytävän palvelun ei tarvitse tietää mitään siitä, että miten veloituspyynnön vastaanottanut palvelu hoitaa tehtävänsä. Pääasia on, että homma hoituu. 

Tämä mahdollistaa sen, että maksuista vastaava palvelu voidaan vaihtaa lennosta, mikäli uusi palvelu kykenee vastaanottamaan samanlaisen käskyn ja vastaamaan siihen samalla tavalla kuin aiempi palvelu. Muut mikropalvelut eivät edes huomaa joukkuekaverin vaihtuneen.

Pilvipohjaisuus

Pilvipohjaisuus tarkoittaa rajusti yksinkertaistettuna sitä, että fyysisen tietokoneen sijaan kaikki mikropalvelut ovat virtuaalisia ja pilvessä. Pilvipohjaisuus mahdollistaa sen, että yksittäisen mikropalvelun tehoja voidaan kasvattaa nappia painamalla sen sijaan, että vaihtaisit fyysisen tietokoneen osia.

Headless

Headless -toteutus tarkoittaa yksinkertaisesti sitä, että frontend ja backend on erotettu toisistaan. 

Miten valita sopiva mikropalvelu?

Kun olet päättänyt toteuttaa verkkokauppasi MACH-arkkitehtuuria noudattaen ja määrittänyt kunkin mikropalvelun tehtävän karkeasti, täytyy seuraavaksi päättää, että toteutatko mikropalvelut itse vai hyödynnätkö kolmannen osapuolen valmista ratkaisua. Composable Commerce -lähestymistavan lähtökohtana on, että käytetään valmista ratkaisua, jos sopiva ratkaisu löytyy.

Valitessasi kolmannen osapuolen ratkaisuja composable commerce -toteutuksella tehtyyn verkkokauppaan, kannattaa kiinnittää erityistä huomioita seuraaviin seikkoihin:

Kykeneekö ratkaisu kommunikoimaan muiden mikropalveluiden kanssa?

Harkitessasi ratkaisua verkkokaupan osaksi, tutustu aina huolellisesti sen rajapintoihin. Modernit ratkaisut ovat usein suunniteltu rajapinnat edellä, mikä yleensä tarkoittaa kattavia ja hyvin dokumentoituja rajapintoja. Vanhempien järjestelmien kanssa on kuitenkin syytä olla hyvin tarkkana, sillä rajapinnat on yleensä rakennettu jälkikäteen. Voi olla, että kaikki tarvittava tieto ei ole saatavilla tai rajapintaan liittyy muita teknisiä haasteita.

Onko ratkaisu riittävän fokusoitunut?

Composable commerce -lähestymistavassa kuhunkin toimintoon pyritään löytämään paras mahdollinen ratkaisu. Jos valittu ratkaisu on riittävän fokusoitunut, voit yleensä luottaa siihen, että sen kehityksessä keskitytään oikeisiin asioihin.

Jos valitset ratkaisun, joka tekee tarvitsemasi ominaisuuden lisäksi paljon muutakin, voi käydä niin että kehittäjä päättääkin panostaa sen muihin ominaisuuksiin, eikä siihen, jota sinä käytät.

Testaa aina käytännössä!

Pelkkä ominaisuuksien vertailu Excelissä ei riitä. Älä valitse valmista ratkaisua osaksi composable commerce -toteutusta ilman että testaat sitä käytännössä. Tällöin voit tehokkaasti välttää monet sudenkuopat, jotka tulevat esiin vasta käytännössä.

Ratkaisu voi esimerkiksi kuulostaa herkulliselta paperilla, mutta osoittautua karvaaksi käytännössä. Saatat vaikkapa todeta käytännön testissä, että käyttöliittymä on epäintuitiivinen tai hidas. Tällöin kyseinen ratkaisu on paras jättää hyllylle.

Lopuksi

MACH-arkkitehtuuri on composable commerce -lähestymistavan ytimessä ja monen mielestä se on paras tapa tehdä modernia ohjelmistokehitystä. 

Kuten aiemmassa artikkelissa totesimme, kyseessä ei kuitenkaan hopealuoti, joka ratkaisee kaikki ongelmat. MACH-arkkitehtuurin soveltaminen vaatii kokemusta, maalaisjärkeä ja perinteisestä ajattelusta luopumista. Emme missään nimessä suosittele hyppäämään suoraan altaan syvään päätyyn, vaan aloittamalla pienin vedoin kahluualtaassa.

Mikäli mietit, olisiko composable commerce -lähestymistapa ja MACH-arkkitehtuuri sopiva juuri sinulle, ole meihin yhteydessä. Vastaamme mielellämme kysymyksiisi ja avaamme tarkemmin eri lähestymistapojen hyötyjä ja haittoja. 

Termit tutuiksi

Frontend

Frontend sisältää kaiken sen, mitä verkkokaupan asiakas näkee ja kaiken sen, jonka kanssa asiakas on suoraan vuorovaikutuksessa. Suomeksi saatetaan myös käyttää termiä esityskerros.

Backend

Backend sisältää kaiken sen, mikä ei kuulu frontend:iin. Suomeksi saatetaan käyttää myös termiä taustajärjestelmät.

Verkkokauppa-alusta

Verkkokauppa-alustalla tarkoitetaan järjestelmää, joka vastaa verkkokaupan perustoiminnoista. Suosittuja verkkokauppa-alustoja ovat muun muassa: Shopify, Magento, WooCommerce ja Salesforce Commerce Cloud.

Monoliittinen arkkitehtuuri

Monoliitilla viitataan toteutukseen, jossa sama järjestelmä vastaa sekä frontend- että backend-toteutuksesta.

Headless

Headless tarkoittaa frontend- ja backend-toteutuksen erottamista toisistaan.

Composable commerce -lähestymistapa

Tämän artikkelin kontekstissa voit ajatella, että loppuun asti viety composable commerce -toteutus on monoliitin vastakohta. Tämä on toki äärimmilleen viety yksinkertaistus, mutta sen tarkoitus on helpottaa hahmottamista.