Code Factory
Zoltán Vígh

Vigh Zoltán

  · 4 min read

Visszatérnek a moduláris monolitok?

Visszatért a monolit, de nem úgy, ahogy otthagytuk. A modularitás kötelező, az elosztottság viszont opció – tanulságok a Shopify és a Google háza tájáról.

Visszatért a monolit, de nem úgy, ahogy otthagytuk. A modularitás kötelező, az elosztottság viszont opció – tanulságok a Shopify és a Google háza tájáról.

Az elmúlt tíz évben a “bontsuk szolgáltatásokra” alapértelmezett válasz volt minden növekedési problémára. 2026-ban ez már nem így van. Nem azért, mert a mikroszolgáltatás rossz, hanem mert a csapatok többsége nem a mikroszolgáltatás előnyét kapta meg, hanem az árát fizette ki: hálózati hívások ott, ahol elég lett volna egy függvényhívás, elosztott tranzakciók ott, ahol elég lett volna egy adatbázis-tranzakció, és tizenkét deploy pipeline egy nyolcfős csapatra.

A moduláris monolit ennek a korrekciója. Egyetlen deployolható alkalmazás, de belül kikényszerített modulhatárokkal: külön namespace-ek, explicit publikus interfészek, tiltott közvetlen adatréteg-elérés modulok között. Ugyanaz a fegyelem, mint a szolgáltatásoknál, hálózat nélkül.

Ki mondja ezt, és mivel

Shopify 2019-ben nyilvánosan leírta, hogy nem mikroszolgáltatásokra bontja szét a Railses monolitját, hanem komponenshatárokat húz benne. Az indoklás nem technológiai, hanem szervezeti volt: a fejlesztői produktivitást ölte meg, hogy bármilyen apró módosításhoz az egész rendszert érteni kellett (Deconstructing the Monolith). Másfél évvel később kiadtak egy őszinte utókövetést arról, mi bizonyult naivnak a tervből (Under Deconstruction: The State of Shopify’s Monolith). Ez utóbbi a hasznosabb olvasmány: a határok kikényszerítése lassabb és fájdalmasabb, mint a diagram sugallja.

Prime Video 2023-as esete a leggyakrabban félreértett adatpont. Egy audio/video minőségellenőrző rendszert vittek vissza szétosztott, Step Functions-alapú serverless felállásból egyetlen processzbe, EC2/ECS-re, és a működési költség 90%-kal esett (InfoQ összefoglaló). A megtakarítás nagy része nem a “monolit jobb” tételből jött, hanem abból, hogy megszűnt a köztes állapot- és adatátmozgatás a komponensek között. Adam Bellemare elemzése és több más értékelés is arra jut, hogy ez egy konkrét, adatintenzív workload esete, nem általános ítélet. CTO-ként pont ezért érdekes: megmutatja, hogy a topológia költséget generál, és a költség mérhető.

Google ugyanezt a problémát a másik oldalról támadta. A HotOS’23-as Towards Modern Development of Cloud Applications tézise, hogy az alkalmazás logikai felépítését el kell választani a futásidejű elosztásától: írj logikai monolitot, és a runtime döntse el, mi fut külön processzben. A prototípusuk (Service Weaver) a cikkük szerint akár 15× latency-javulást és 9× költségcsökkenést mért a hagyományos mikroszolgáltatásos deployhoz képest. A projekt maga megállt, de az érv él: a modulhatár és a processzhatár két különböző döntés, és a legtöbb csapat összemosta őket.

Martin Fowler ezt már 2015-ben leírta, csak nem hallgattunk rá. A MonolithFirst és a Microservice Premium alaptétele, hogy a mikroszolgáltatás felár, amit csak akkor érdemes kifizetni, ha a rendszer komplexitása már túllépte a monolit kezelhetőségi határát. Aki zöldmezőn kezd mikroszolgáltatásokkal, olyan határokat rögzít, amiket még nem ismer.

Mit jelent ez, ha most döntesz

Ha új terméket építesz: kezdj moduláris monolittal. A domainhatárokat nem tudod előre helyesen meghúzni, és monoliton belül egy elrontott határt egy refaktorral javítasz, két szolgáltatás között egy migrációval és egy visszafelé kompatibilis API-verzióval.

Ha meglévő monolitot modernizálsz: a modulhatárok kikényszerítése az első lépés, nem a szolgáltatásra bontás. Ha a monolitodon belül nem tudsz betartatni határokat, szolgáltatások között sem fogsz, csak akkor már hálózati hibamódokkal együtt. Ruby-ban erre a packwerk, Java/Springben a Spring Modulith, .NET-ben az assembly- és architektúra-tesztek adnak eszközt. A lényeg, hogy a határsértés build-időben törjön el, ne code review-n.

Ha már szétbontottál: a visszaolvasztás legitim opció. Nem kudarc, hanem költségoptimalizálás. Azokat a szolgáltatáspárokat érdemes összevonni, amelyek mindig együtt deployolódnak, mindig együtt hibásodnak, és nagy adatmennyiséget mozgatnak egymás között.

Mikor bontsd ki mégis: ha egy komponens skálázási profilja élesen eltér (GPU-igény, extrém írásterhelés), ha külön compliance-zóna kell neki, ha külön csapat birtokolja és a release-kadenciája ütközik, vagy ha más nyelvre/runtime-ra van szükség. Ez négy konkrét indok. Ha egyik sem áll, a szolgáltatáshatár csak szervezeti dísz.

Amit hozzá kell tenni

Két dolog változott azóta, hogy ez a vita elindult, és mindkettő a moduláris monolit felé tolja a mérleget.

Az egyik a platform. A DORA 2025-es adatai szerint a szervezetek jelentős többsége már belső fejlesztői platformot üzemeltet (DORA: platform engineering). Ha van egységes pipeline, preview environment és megfigyelhetőség, akkor a monolit deployja sem lassabb, mint egy szolgáltatásé. A mikroszolgáltatás egyik fő érve — a független release — nagyrészt platformkérdés volt, nem architektúrakérdés.

A másik a költségtudatosság. 2020-ban senki nem nézte, mennyibe kerül, hogy két komponens hálózaton beszél egymással. Ma ez tétel a felhőszámlán, és a topológia a legnagyobb egyszeri tétele.

A moduláris monolit nem visszalépés, hanem annak beismerése, hogy a modularitást és az elosztottságot összemostuk. A modularitás mindig kell. Az elosztottság csak akkor, ha megvan hozzá a konkrét indok és a platform, ami elviszi. Kezdj egyben, húzz kemény határokat, mérd a valós költséget, és csak bizonyíték alapján vágj.

Felhasznált források

Kérdésed van? Írj nekünk, és mi segítünk megtalálni a számodra optimális megoldásokat.

Share:
Vissza a cikkekhez