Strangler Fig -malli

Perusajatuksena on ottaa käyttöön uusi, ohut sovelluskerros, joka toimii olemassa olevan monoliitin edessä julkisivuna tai välityspalvelimena. Kaikki saapuvat pyynnöt ohjautuvat ensin tälle välityspalvelimelle.

Välityspalvelin päättää sitten, ohjataanko pyyntö vanhaan monoliittiseen sovellukseen vai uuteen, nykyaikaiseen mikropalveluun.

Ensimmäinen vaihe on tunnistaa monoliitista pieni, itsenäinen toiminnallisuuden osa tai ”rajattu konteksti”, jonka haluat irrottaa.

Etsi seuraavia:

• Ominaisuuksia, joilla on selkeät rajat
• Usein muuttuvaa toiminnallisuutta
• Alueita, jotka aiheuttavat skaalautuvuusongelmia

Aloita pienestä, jotta riskit pysyvät vähäisinä ja opit prosessin aikana.

Kun olet valinnut ominaisuuden, rakennat täysin uuden mikropalvelun käsittelemään kyseistä toiminnallisuutta. Tämä uusi palvelu kehitetään nykyaikaisilla teknologioilla ja arkkitehtuurin parhaiden käytäntöjen mukaisesti.

Ratkaisevaa on, että uusi palvelu toimii itsenäisesti monoliitin koodikannan ulkopuolella.

Kun uusi mikropalvelu on valmis, päivität välityspalvelimen. Sen sijaan, että se lähettäisi kaikki kyseiseen ominaisuuteen liittyvät pyynnöt monoliitille, se ohjaa ne nyt uuteen mikropalveluun.

Vanhan monoliitin kyseiseen ominaisuuteen liittyvää koodia ei enää käytetä, joten uusi palvelu on käytännössä ”kuristanut” sen pois käytöstä.

Oletetaan, että monoliittisi käsittelee käyttäjäprofiileja. Päätät irrottaa toiminnon ”Käyttäjän sähköpostiosoitteen päivittäminen”.

1. Rakenna uusi UserProfileService.
2. Välityspalvelin tarkistaa saapuvista pyynnöistä polun /api/users/{id}/email.
3. Jos kyseessä on sähköpostiosoitteen päivitys, välityspalvelin lähettää pyynnön palvelulle UserProfileService.
4. Muut profiiliin liittyvät pyynnöt, kuten nimen vaihtaminen, ohjataan edelleen monoliitille.

Lopulta kaikki profiiliin liittyvät ominaisuudet on siirretty, ja vanha monoliitin koodi voidaan poistaa.

Strangler Fig -mallin hienous on sen asteittaisuudessa. Kaikkea ei kirjoiteta uudelleen kerralla.

• Irrota yksi ominaisuus.
• Testaa se perusteellisesti.
• Kasvata luottamusta ratkaisuun.
• Toista sama seuraavan ominaisuuden kohdalla.

Näin toiminta voi jatkua keskeytyksettä ja niin sanotun ”big bang” -uudelleenkirjoituksen riski pienenee.

Tämän mallin käyttäminen tarjoaa SaaS-tuotteen kehitykselle merkittäviä hyötyjä:

• Pienempi riski: Siirto tehdään yksi osa kerrallaan.
• Jatkuva toiminta: Pitkiä käyttökatkoja ei tarvita.
• Nykyaikaistaminen: Uudet palvelut käyttävät modernia teknologiaa.
• Parempi skaalautuvuus: Mikropalveluita voidaan skaalata itsenäisesti.
• Nopeampi kehitys: Pienemmät ja keskittyneet tiimit työskentelevät uusien palveluiden parissa.

Vaikka malli on tehokas, huomioi myös mahdolliset haasteet:

• Välityspalvelimen monimutkaisuus: Reitityskerroksesta voi tulla monimutkainen.
• Datan siirto: Uusien palveluiden tarvitsemien tietojen siirtotavan päättäminen voi olla hankalaa.
• Hajautettu monoliitti: Ilman huolellista suunnittelua mikropalvelut voivat päätyä tiukasti toisiinsa kytkeytyneiksi.

Suunnittelu ja selkeät rajat ovat avainasemassa!

Tänään tutustuimme Strangler Fig -malliin, joka on strateginen tapa nykyaikaistaa vanhoja monoliitteja mikropalveluiksi.

• Se käyttää välityspalvelinta liikenteen uudelleenohjaamiseen.
• Ominaisuudet irrotetaan ja rakennetaan uudelleen uusiksi palveluiksi.
• Prosessi on asteittainen, mikä pienentää riskejä.
• Keskeisiä hyötyjä ovat jatkuva toiminta ja nykyaikaistaminen.

Tämä malli on erittäin hyödyllinen, kun olemassa olevia SaaS-alustoja kehitetään ilman suuria häiriöitä. Jatkakaa rakentamista!