Mikropalveluarkkitehtuurista

Mikropalveluarkkitehtuurista on tulossa yhä enemmän standardivaihtoehto tulevaisuuden ohjelmistojen toteutustapoja miettiessä. Rekrytoija Saku jututti mikropalveluiden parissa työskenteleviä Rikua ja Anttia aiheesta "missä ollaan juuri nyt mikropalveluarkkitehtuurin saralla".

Riku ja Antti, hienoa että pääsitte jututettavaksi. Kun itse kuulin termin mikropalveluarkkitehtuuri ensimmäisen kerran, niin mietin, että onko tuo sana edes oikea! Milloin on alettu puhumaan mikropalveluarkkitehtuurista?

-Nyt pitäisi kysyä Googlelta… Termi on varmaan kymmenen vuotta vanha.

-Jotain sitä luokkaa.

-Sitä ennen oli SOA (service-orientated architecture) trendinä.

-Varmaan tällä vuosikymmenellä on ruvettu puhumaan enemmän ja nimenomaan vuosikymmenen alussa oli kovin noste.

-Siitä se varmaan lähti, että kun serverirauta alkoi olla halpaa eikä tarvinnut pyörittää kokonaisuutta sadantuhannen köntillä. Pystyi alkaa miettiä, että voidaan hajauttaa toteutus monelle halvalle palvelimelle eikä yhdelle kalliille.

Mitä mikropalveluarkkitehtuuri tarkoittaa?

-Se tarkoittaa yksinkertaisuudessaan sitä, että aiemmin tehtiin iso köntti, joka tekee kaiken. Sinne syötettiin tavara sisään ja saatiin vastaavasti ulos. Mikropalveluarkkitehtuurissa tehdään tämä pienissä osissa. Siitä siinä on kaikessa yksinkertaisuudessaan kyse. On erilaisia mielipiteitä kuinka pieniin osiin sitä kuuluu jakaa, mutta se keskustelu menee jo teoreettisemmaksi.

-Mitä pienempi kokonaisuus ja mitä vähemmän toiminnallisuuksia, sitä helpompi se on helpompi testata kattavasti. Tiedetään että se tekee tämän asian ja se tekee sen hyvin.

-Toinen etu on, että tällä tavoin voidaan toteuttaa kokonaisuus erillisissä tiimeissä ilman että päivittäin täytyy kommunikoida ja koordinoida, eli yksi osa voidaan tehdä Jyväskylässä, yksi Tampereella ja kolmas Helsingissä. Voidaan olla suhteellisen varmoja, että se toimii kun yhdistetään ne osat lopussa.

-Lisäksi ei tarvi olla homogeeninen teknologia. Ei tarvi koodata kaikkea vaikka Javalla. Jos jokin palikka on parempi koodata jollain muulla teknologialla, niin sovitaan vain rajapinnat ja koodataan se sillä mikä siihen sopii parhaiten.  

Millaista keskustelua mikropalveluarkkitehtuuriin tänä päivänä liittyy?

-Varsinkin vanhoihin toteutuksiin liittyvissä projekteissa karsastetaan mikropalveluita. Siirtyminen olemassa olevasta monoliitista mikropalveluun voi tuntua hankalalta. Käytännössä me pystytään palastelemaan monoliitti-könttiä pienempiin osiin, erilaisia tekniikoita on. Mutta kehittäjät eivät pysty itse päättämään asiaa vaan se vaatii organisaatiolta yhteistä päätöstä ja myös ylimääräistä työtä. Että saadaan pilkottua.

-Siitä on näkemyksiä, että kun mikropalveluita aletaan soveltaa, niin jos osakokonaisuudet ovat hyvin pieniä ja niitä on suuri määrä… Se väistämättä lisää järjestelmän kokonaiskompleksisuutta. Aiemmin kun oli monoliitti, oli yksi palikka, mutta hajautettuna tulee lisähaasteita hallintaan. Toki löytyy työkaluja, orkestraattoreita ja muuta, jotka hoitaa sitä. Ei tarvitse käsin tehdä kaikkea alusta asti.

-Mikropalveluarkkitehtuurin osalta nousee esille, että aiemmin on voinut kiertää joitakin seikkoja. Kun aiemmin oli yksi palvelin, jossa vaikka yksi Java-prosessi, oli helppo valvoa että se ei vienyt liikaa tehoa ja muistia. Mutta nyt kun on 50 tai 100 palikkaa hajautettuna, joista osa voi olla Suomessa ja osa esimerkiksi Japanissa, niin miten niitä saadaan valvottua? Kuitenkin on pystyttävä seuraamaan tapahtuuko jotain epänormaalia. Tällöin ei voi yksi ihminen kirjautua ja katsoa, että miltäs tämä käppyrä näyttää. Tämä tarkoittaa käytännössä, että on pakko automatisoida ja yhtenäistää se data.

Miten meillä hyödynnetään mikropalveluita?

-Mahdollisuuksien mukaan. Voi olla IoT-projekteissa selvät komponentit, eri osat vastaanottavat IoT-laitteen dataa tiettyjen protokollien mukaan ja ne voidaan eriyttää mikropalveluihin erikseen. Tiedon tallennus on yhtenäistetty yhteen palveluun. Sitä kautta se lähtee hiljalleen.

-Hyödynnetään kyllä. Olemassa olevia malleja pystytään käyttämään joko suoraan tai hieman muokataan tarpeen vaatiessa. Käytetään aina mahdollisuuden mukaan. Ei täällä monoliitteja kauheasti rakennella.

-Se ei ole enää vuonna 2018 paras ajatus niitä rakentaa.

Onko kompleksisuuden lisäksi muita vasta-argumentteja mikropalveluille?

Siinä tulee organisaatio vastaan. Se vaatii valvontaa. Vanhat mallit jotka toimivat yhden ison möllikän ja palvelimen ylläpidossa eivät toimi enää mikropalvelumaailmassa. Ei riitä, että tehdään mikropalvelusoftaa vaan kaiken siinä ympärillä pitää muuttua, kuten palvelinten ylläpito, ja devops tulee siihen mukaan. Ne on pakko olla siinä mukana, muuten tulee vaan paskaa mikropalvelua. Näin niin kuin ammattikielellä.

Kiitos tästä keskustelusta ja osuvista kommenteista!

Riku ja Antti juttelevat mikropalveluarkkitehtuurista.

Mitä hidasteita on mikropalveluiden käytön laajentamiselle?

 

Behind the scenes-klippi kuvauspaikan "varautuneesta tunnelmasta":

Avoin hakemus

 

 

 

Rekrytoimme jatkuvasti erilaisiin rooleihin ohjelmistopalveluihin, mm. koodinkeittäjiä.

 

Instagram @ciniafinland

Instagramiin