Monoliittien hajottaminen

Monoliittinen sovellus rakennetaan yhtenä jakamattomana kokonaisuutena. Kaikki komponentit, kuten käyttöliittymä, liiketoimintalogiikka ja tietojen käyttö, ovat tiiviisti kytkeytyneet yhteen suureen koodikantaan.

Monoliitit ovat aluksi helppoja, mutta niiden kasvaessa niistä voi tulla hyvin monimutkaisia ja vaikeasti hallittavia.

Monoliittisten sovellusten kasvaessa ne kohtaavat usein merkittäviä haasteita:

• Hidas kehitys: Suuret koodikannat tekevät muutoksista riskialttiimpia ja hidastavat kehityssyklejä.
• Skaalaushaasteet: Koko sovellusta on skaalattava, vaikka lisäresursseja tarvittaisiin vain yhdelle pienelle osalle.
• Teknologiasidonnaisuus: Uusia teknologioita on vaikea ottaa käyttöön kirjoittamatta koko sovellusta uudelleen.
• Julkaisuriski: Pienenkin muutoksen vuoksi koko sovellus on julkaistava uudelleen, mikä lisää riskiä.

Mikropalvelut ratkaisevat nämä haasteet jakamalla sovelluksen pieniksi, itsenäisiksi palveluiksi. Kukin palvelu keskittyy yhteen liiketoimintaominaisuuteen, toimii omassa prosessissaan ja viestii kevyiden mekanismien, kuten APIen, välityksellä.

Tämä lähestymistapa tarjoaa enemmän joustavuutta, mahdollistaa itsenäiset julkaisut ja helpottaa skaalaamista.

Yksi tehokkaimmista tavoista hajottaa monoliitti on erillisten liiketoimintaominaisuuksien tunnistaminen.

• Ajatelkaa liiketoimintanne keskeisiä toimintoja (esim. "Tilausten hallinta", "Käyttäjäprofiilit", "Maksujen käsittely").
• Kustakin ominaisuudesta tulee itsenäinen mikropalvelu. Näin palvelut pysyvät yhtenäisinä ja löyhästi kytkettyinä.

Domain-Driven Designissa (DDD) Bounded Context määrittää selkeän rajan, jonka sisällä tietty toimialuemalli pätee.

• Sanoilla ja käsitteillä (kuten "Product") on täsmällinen merkitys vain omassa kontekstissaan.
• Esimerkiksi varastonhallinnan kontekstissa "Product" voi tarkoittaa eri asiaa kuin myynnin kontekstissa.
• Hajottaminen näiden rajojen mukaisesti auttaa luomaan palveluita, joilla on selkeät ja erilliset vastuualueet.

Strangler Fig -mallissa monoliittisen sovelluksen osia korvataan vähitellen uusilla mikropalveluilla sen sijaan, että sovellus kirjoitettaisiin kerralla kokonaan uudelleen.

• Uudet toiminnallisuudet toteutetaan erillisinä mikropalveluina.
• Uusien ominaisuuksien pyynnöt ohjataan mikropalveluille, kun taas vanhat pyynnöt käsitellään edelleen monoliitissa.
• Lopulta mikropalvelut "kuristavat" monoliitin eli korvaavat sen kokonaan. Tämä on vähäriskinen ja vaiheittainen lähestymistapa.

Myös sen analysointi, missä tietokantatransaktiot alkavat ja päättyvät, voi auttaa hajottamisessa.

• Jos tietty joukko toimintoja suoritetaan aina yhdessä saman tietokantatransaktion sisällä, se voi viitata yhteen palveluun.
• Toiminnot, joiden ei tarvitse kuulua samaan transaktioon, voivat kuulua eri palveluihin.
• Tämä auttaa minimoimaan hajautettujen transaktioiden monimutkaisuuden myöhemmin.

Monoliitin hajottamiseen liittyy myös haasteita:

• Kasvanut monimutkaisuus: Useiden palveluiden hallinta on luonnostaan monimutkaisempaa kuin yhden palvelun hallinta.
• Hajautetut transaktiot: Tietojen yhdenmukaisuuden varmistaminen useiden palveluiden välillä voi olla hankalaa.
• Ylläpidon lisäkuormitus: Useammat palvelut tarkoittavat enemmän käyttöönotettavaa, valvottavaa ja vianmääritystä vaativaa.
• Tietojen monistuminen: Jaettujen tietojen hallintatavan päättäminen palveluiden välillä voi olla monimutkaista.

Kun siirtymistä monoliitista mikropalveluihin halutaan helpottaa, kannattaa harkita seuraavia tekniikoita:

• API:t: Määrittäkää selkeät API:t uusien palveluiden ja vanhan monoliitin väliseen viestintään.
• Viestijonot: Käyttäkää asynkronista viestintää palveluiden väliseen löyhästi kytkettyyn viestintään.
• Jaetut kirjastot: Erottakaa yhteinen, liiketoiminnasta riippumaton koodi kirjastoihin, joita useat palvelut käyttävät.
• Ominaisuuskytkimet: Ottakaa uudet mikropalvelutoiminnot käyttöön käyttäjille vaiheittain.

Olemme oppineet, että monoliitin hajottaminen ratkaisee hitaan kehityksen ja skaalautuvuuden kaltaisia haasteita ottamalla mikropalvelut käyttöön.

Monoliitin hajottamisen keskeisiä strategioita ovat palveluiden määrittäminen liiketoimintakyvykkyyksien perusteella, Domain-Driven Designin Bounded Context -kontekstien hyödyntäminen sekä Strangler Fig -mallin käyttäminen vaiheittaiseen ja vähäriskisempään siirtymään.

Vaikka siirtymä tuo mukanaan uusia monimutkaisuuksia, huolellinen suunnittelu ja oikeat työkalut voivat tehdä siitä onnistuneen.