Tämän hetken kuumia trendejä ohjelmistokehityksessä ovat virtualisointialustat kuten Docker, mikropalvelut sekä  REST-rajapinnat. Mikropalveluarkkitehtuurilla menee jo niin lujaa, että alalla on alkanut nousta soraääniä, jotka kysyvät ollaanko mikropalveluita laittamassa liian moneen paikkaan?

Ohjelmistokehityksen ostajalle kysymys on oleellinen. Sean Kelly esittää artikkelissaan Microservices, Please Don’t yleisiä harhakuvitelmia mikropalveluarkkitehtuurista. Mikropalveluarkkitehtuuri on monessa tapauksessa erinomainen valinta, mutta toimittajan pitäisi pystyä perustelemaan arkkitehtuurivalinta muullakin kuin trendeillä.

Seuraavaksi esitän yhden näkemyksen sitä, miksi ja milloin on perusteltua soveltaa mikropalveluarkkitehtuuria sovelluskehityksessä.

Mikropalveluarkkitehtuuri ei ole aina oikea ratkaisu

Uusien järjestelmien alkuvaiheessa täysi mikropalveluarkkitehtuuri on harvoin oikea valinta. Kun epävarmuus projektissa on suurinta, järjestelmän osien toteuttaminen toisistaan erillisinä mikropalveluina voi tuoda ohjelmistokehityksen kriittiseen käynnistysvaiheeseen enemmän kankeutta kuin toivottua joustavuutta ja selkeyttä.

Jos päädyt aloittamaan uuden projektin mikropalveluarkkitehtuurilla, varmista että sinulla on alusta saakka selvä käsitys järjestelmän palvelukartasta ja järjestelmien vastuista. Varo myös, ettei arkkitehtuurin valinta ohjaa projektia tarpeettomasti kohti vesiputousmallia. Monimutkaisuutta alkuvaiheessa lisäävä arkkitehtuuri voi pahimmillaan olla Lean-ajattelun vastustamaa haaskausta. Hyvin suunnitellussa järjestelmässä palveluita voidaan erottaa irrallisiksi mikropalveluiksi vasta tarpeen vaatiessa.

Monimutkaisuutta alkuvaiheessa lisäävä arkkitehtuuri voi pahimmillaan olla Lean-ajattelun vastustamaa haaskausta.

Mikropalvelut pitävät koodin siistinä

Tarvittaessa monimutkaisista legacy-järjestelmistäkin saadaan tarjottua palveluja siistien rajapintojen kautta esimerkiksi sopivalla palveluväyläratkaisulla. Monimutkaiseksi kasvaneen järjestelmän paloittainen uudistaminen mikropalveluiksi purkamalla on myös usein hyvä ja kestävä ratkaisu. Itsenäisiksi kokonaisuuksiksi puretut palvelut pysyvät helpommin siisteinä koodiltaan ja rajapinnoiltaan.
Siisti koodi ei kuitenkaan ole arkkitehtuuririippuvaista. Myös yhden sovelluksen sisällä palvelut voivat noudattaa selkeitä, karkeajakoisia rajapintoja, joilla on rajatut vastuut ja joissa yksityiskohdat sisäisestä toteutuksesta eivät vuoda palvelun kuluttajalle. Tällöin sovelluksesta voidaan tarjota ulos rajapintoja aivan yhtä helposti kuin mikropalveluna. Mikropalveluille on siis oltava muukin peruste kuin pelkästään siisti koodi tai halu julkaista ulkoisia rajapintoja.

Miksi sitten mikropalveluarkkitehtuuri?

Sovelluksen eri palveluiden jakamiselle itsenäisiksi mikropalveluiksi on hyviäkin perusteita. Ensimmäinen on suorituskyky. Virtualisoidussa suoritusympäristössä mikropalveluilla päästään skaalaamaan juuri sitä osaa sovelluksesta, joka on pullonkaula.

Toinen peruste on merkittävä ero palveluiden kehitysnopeudessa. Jos sovelluksen eri osat elävät täysin eri sykleissä, voidaan saavuttaa merkittävää etua kehitysnopeudessa, jos järjestelmän osat ja kehitysaikataulut erotetaan toisistaan. Erottaminen mikropalveluksi voi myös helpottaa julkisen rajapinnan tarjoamista palvelulle.

Kolmas peruste on teknologiavalintojen vapaus. Docker ja mikropalvelut mahdollistavat parhaiden työkalujen soveltamisen jokaisen palvelun toteutuksessa. Kannattaa kuitenkin huomioda, että mikropalvelut eivät poista tarvetta järjestelmien ylläpidolle, jolloin valittujen teknologioiden tulee istua kokonaisarkkitehtuurin teknologiapalettiin.

Mikään arkkitehtuuri ei itsessään ole hyvä tai huono. Eri arkkitehtuurit soveltuvat eri tarkoituksiin. Valitsetpa minkä tahansa arkkitehtuurin seuraavan järjestelmäsi pohjaksi, tärkeintä on että valinta on tietoinen, perusteltu ja valittu toteutettavan järjestelmän tarpeita ajatellen.

 

Kalle Pahajoki

Senior Software Developer