Miért mondják a microservice-re, hogy költséghatékony?

Nyilván megvannak a különbségek a monolithic és a microservice architektúra között. Monolitikus szoftver esetén van egy nagy kódbázisból fordított szoftvered, aminek kell egy adatbázis és nagyon kis számú külső függőség (cache szerver, stb.). Mivel egy szoftverben nagyon sok kód gyűlik össze, ezért nagyon nehéz módosításokat végezni rajta, mivel minden módosítás hatással van minden másra, ezért minél több funkciót szuszakolsz bele, annál tovább tart tesztelni. A telepítés/frissítés nehézségeiről pedig ne is beszéljünk, főleg, ha leállás nélkül akarod véghezvinni. Mindennek tetejében csak vertikálisan skálázható a legtöbb esetben, ami azt jelenti, hogy egy példánynak kell elbírnia a teljes terhelést, így csak egy erősebb proci és több RAM segíthet a helyzeten. Esetleg lehet egy backup példányod, ha az éles rendszer meghal. Mindennek van azért egy pozitív oldala is, hogy van egy nagyon egyszerű hálózatod.

Összegezve tehát a monolith rendszer költségeit:

- pénzt veszítesz, mivel a lassú fejlesztés miatt nem tudod költséghatékonyabbá tenni a munkafolyamataidat (akár egy-két évig is eltarthat, mire a fejlesztők szállítani tudják az általad megrendelt funkcionalitást)

- a kód komplexitása miatt sok időbe kerül a fejlesztés és a tesztelés (ki kell fizetni a fejlesztőket erre az időre)

- ha teljesítmény kell, a vertikális skálázhatóság miatt nagyon könnyen eljuthatsz oda, hogy a te igényeidet csak a létező legdrágább, csúcstechnológiás hardver bírja el

- nagyot bukhatsz, ha az új verzióban valami félresikerül (szóval a frissítésnek nagy a kockázata) - főleg, ha csak úgy tudtok frissíteni, ha az egész rendszer áll

És ezzel szemben van a microservice, aminek az a lényege, hogy egy marhanagy szoftver helyett sok picike szoftvert készítesz, amik például REST API-n keresztül kommunikálnak, így a komponensek lazán kapcsoltak, nincsenek olyan szorosan egymásra utalva, mintha egybe lennének fordítva. Bármelyik apró összetevőt kicserélheted bármi másra, amíg tudja ugyanazt a funkcionalitást biztosítani, amit az elődje. Így amíg fejlesztőként odafigyelek arra, hogy az új verzió visszafele kompatibilis legyen a régivel, akkor már sikerült elérnem azt, hogy rettegés nélkül tudjak fejlesztéseket végezni a rendszeren. Ha ezeket a kis programocskákat úgy írjátok meg, hogy nem zavarja össze őket az, hogy több példányban is futnak, akkor még a horizontális skálázhatóság is spórolhat a költségeken, mivel nem lesz szükség csúcshardverre a futtatáshoz - szétszórhatod több olcsóbb gépre a terhelést. Cserébe van egy bonyolult hálózatod.

Szóval microservice architektúra esetében:

- gyorsan tudom szállítani a kért funkcionalitást, így a megrendelőm hamarabb vetheti be, és így hamarabb kezdhet el spórolni/plusz profitot termelni az üzleti folyamatok egyszerűsödésének/modernizálásának köszönhetően

- kisebb komponenseket nem tart sokáig fejleszteni és tesztelni, tehát a megrendelőnek kevesebb fejlesztési időt kell megfizetnie (nyilván ez szerződéstől függ)

- olcsóbb gépeket állíthatok üzembe, ha megugrik a terhelés, nem kell csúcstechnológiáért fizetni

- minimális rizikóval végezhető el a frissítés, és ha baj van, az is csak a felhasználók minimális százaléka tapasztalja majd.

Ajánlom neked, hogy a Kubernetes és a microservice architektúra mellett tanulmányozd az Istio service mesht, az Envoy proxyt és a Flaggert is. Jó cuccok.

26/N