Sokan nem értik a microservice-ek lényegét, nem ismerik az előnyeiket (a hátrányaikat általában ismerik :).
Akik nem ismerik a microservice-ek előnyeit, azoknak tudom ajánlani ezt a cikket és ezt a diasorozatot.
A monolitikus felépítésnek és a microservice-es felépítésnek is megvannak a maga előnyei, hátrányai. Ezek figyelembevételével kell egy-egy rendszert megtervezni. Egyik sem jobb a másiknál minden körülmények között!
Aztán az egészet ki kellett egészíteni olyan szolgáltatásokkal, librarykkel (auto discovery, routing, load balancing, monitoring) amik egyenként megfeleltethetők voltak a JavaEE stack belső szolgáltatásainak
Így van, ez pl. az egyik hátránya a microservice-es rendszereknek, hogy ezekre nagy szükség van, és ezek biztosítása, automatikus működése nagy feladatot jelent mindjárt induláskor. Azonban ezek az eszközök is egyre inkább kezdenek kiforrni és egyre több kész eszközt lehet ezekre használni, pl. Kubernetes, Docker.
Ahhoz, hogy az alkalmazás elinduljon mondjuk egy fejlesztői gépen (8-12 spring boot service), kevés volt a 16GB Ram a gépekbe.
Itt valami el lehetett esetleg rontva, mert a microservice-eknek pont az az egyik lényege, hogy nagyon kicsik és egy fejlesztői gépen is azért pár tucatot el lehet indítani belőlük.
Több lehetséges felépítése lehet a microservice-eknek, pl. van ahol egymást hívják, ezeknél fontos a függőségkezelés is; van ahol MessageQueue-kon (MQ) kommunikálnak egymással. Ez utóbbi azért is jobb sok esetben, mert önállóan fejlesztheted, tesztelheted, használhatod a microservice-eket.
Épp ez az egyik előnye a microservice-es rendszernek, hogy nem kell egy hatalmas alkalmazásnak elférnie a fejlesztői gépen, elegendő csak a fejlesztés alatt álló microservice-nek (esetleg egy pár függőségének).
Miért is kell minden spring boot service-nek önálló környezetet, saját web servert, jpa-t stb. indítani, mikor az érdemi alkalmazás egyébként pár kilobyte bytekód? Szerintem ez pazarlás, ráadásul ezek között a modulok között a kommunikáció (rest, http, https) sokkal lassabb mint egy bináris (akár udp) belső szinkronizációs protokoll.
Így van, ez pazarlás, de egyrészt ettől lesz a rendszer horizontálisan, funkciónként (microservice) skálázható, hibatűrő.
Másrészt egy jól elkészített microservice-es rendszernél a kommunikációs közeget könnyen cserélhetőre szokás elkészíteni, amivel a http-s kommunikáció helyett akár egyszerű függvény hívás is szerepelhet, sőt akár több microservice futhat egy monolitikus alkalmazásként is. Ez nagyon jól jön tesztelésnél és fejlesztésnél.