Monolit Modular vs Microservicii: Ce Arhitectură Alegi pentru o Aplicație Web Custom B2B

Pentru majoritatea aplicațiilor web custom B2B, răspunsul corect la lansare este monolitul modular, nu microserviciile. Microserviciile rezolvă o problemă de scală organizațională și tehnică pe care puține echipe o au încă din prima versiune a produsului, iar overhead-ul lor operațional depășește repede beneficiul dacă nu ai deja trafic sau organizare care să-l justifice.

Asta nu înseamnă că microserviciile sunt o greșeală, ci un instrument pentru o problemă specifică, nu un standard implicit de calitate. Când construim o aplicație web custom pentru un client B2B, prima decizie de arhitectură nu e „microservicii sau nu”, ci „ce trebuie să poată face sistemul ăsta peste doi ani, fără să-l rescriem”.

Ce înseamnă, de fapt, un monolit modular

Un monolit modular nu e monolitul dezorganizat din 2012, cu totul amestecat într-un singur fișier de mii de linii. E o aplicație care rulează ca un singur proces, cu un singur deployment, dar cu granițe interne clare între module: stratul de date, logica de business și interfața nu se amestecă și nu se apelează direct unul pe altul fără o graniță definită. Diferența față de un monolit „vechi” nu e tehnologia, e disciplina de a separa aceste straturi de la început.

Avantajul practic: o singură bază de date de administrat, un singur mediu de deployment, un singur loc unde cauți o eroare când ceva nu merge. Pentru o echipă mică sau medie, asta înseamnă viteză de livrare mult mai mare în primele luni de viață ale produsului, exact perioada în care produsul se schimbă cel mai des pe baza feedback-ului real de la utilizatori. La Profesori Meditații, separarea din start a straturilor de date, logică de business și interfață, păstrate totuși într-un singur deployment, a permis adăugarea de funcționalități noi peste sistemul existent fără rescrierea altor module.

Ce sunt microserviciile, pe scurt

Microserviciile împart aplicația în servicii separate, fiecare cu propriul proces, propria bază de date (de obicei) și propriul ciclu de deployment. Serviciul de plăți nu știe cum e construit intern serviciul de notificări. Comunică prin API-uri sau printr-o coadă de mesaje, nu prin apeluri directe de funcții.

Beneficiul real: poți scala orizontal doar componenta care are nevoie de resurse suplimentare, fără să dublezi tot sistemul, iar echipe diferite pot lucra independent pe servicii diferite, fără să se calce pe picioare într-un singur codebase comun.

Costul real vine în același pachet: fiecare serviciu nou înseamnă infrastructură suplimentară, monitorizare separată și un contract (API) care trebuie menținut și testat, plus complexitate la depanare atunci când o problemă traversează mai multe servicii deodată. Alegerea de framework contează și ea aici: de ce alegem Next.js pentru aplicații custom explică de ce o structură bine gândită din start reduce costul de a extrage ulterior o componentă, indiferent pe care variantă arhitecturală pornești.

Monolit modular vs microservicii, criteriu cu criteriu

Când monolitul modular e suficient

Monolitul modular e suficient de fiecare dată când aplicația are un singur flux principal de business, chiar dacă acel flux e complex. Un portal B2B, o platformă de rezervări, un sistem intern de gestiune, toate pot avea logică sofisticată fără să aibă nevoie de servicii separate ca să funcționeze bine.

Semnul clar că monolitul modular e alegerea corectă: nu ai o componentă care cere scalare independentă de restul, nu ai echipe separate pe bucăți izolate ale sistemului și nu ai un domeniu tehnic complet diferit (hardware, procesare video, machine learning) care ar beneficia de un mediu de rulare propriu. Profesori Meditații e exemplul direct din portofoliul propriu: platforma face căutare pe materie și locație și gestionează planuri de promovare pentru profesori, un flux de business coerent, fără nevoie de servicii separate.

Martin Fowler, unul dintre autorii de referință în arhitectură software, recomandă exact această ordine: pornește cu un monolit bine structurat și extrage servicii separate doar când granițele reale ale sistemului devin clare din utilizare, nu din presupuneri făcute înainte de lansare (Martin Fowler, „MonolithFirst”, martinfowler.com, 3 iunie 2015).

Când chiar ai nevoie de microservicii

Ai nevoie de microservicii când o parte a sistemului are cerințe tehnice fundamental diferite de restul, nu doar „mai multă logică”: de exemplu, un domeniu care trebuie să comunice cu hardware extern în timp real, fără ca o problemă acolo să oprească tot sistemul.

La Titan (ERP complet cu acces prin cod QR, gamification pentru membri, POS pentru cafenea și integrare cu senzori IoT dintr-o sală de sport), separarea serviciilor nu a fost o decizie stilistică, a fost impusă de natura hardware-ului. Componenta de acces QR și cea de POS trebuie să răspundă în timp real la evenimente fizice, independent de restul ERP-ului. Dacă cititorul QR are o problemă temporară, restul sistemului (gestiune membri, gamification, raportare) trebuie să rămână funcțional.

Alte semnale reale, nu ipotetice: trafic concurent foarte mare pe o singură funcționalitate, în timp ce restul aplicației are trafic normal; echipe de dezvoltare separate care trebuie să livreze independent, fără să se blocheze reciproc pe același deployment; sau un serviciu cu cerințe de securitate diferite de restul sistemului, care are nevoie de izolare completă.

Dacă niciunul dintre aceste semnale nu se aplică azi, microserviciile nu rezolvă o problemă reală, ele adaugă una nouă: coordonarea între servicii.

Costul ascuns al microserviciilor pentru o echipă fără DevOps dedicat

Cel mai des ignorat cost al microserviciilor nu e cel de dezvoltare, e cel de operare: un mediu de rulare de monitorizat pentru fiecare serviciu, alerte de configurat separat și, la un moment dat, nevoia de a urmări o cerere care trece prin trei sau patru servicii diferite ca să înțelegi de ce a eșuat.

Doi giganți tech au documentat public exact acest cost. Echipa de inginerie Prime Video a renunțat, în 2023, la o arhitectură distribuită bazată pe microservicii și componente serverless pentru serviciul lor de monitorizare audio/video, în favoarea unei aplicații monolitice, și au redus costul infrastructurii cu peste 90%, din cauza costului de orchestrare, nu din lipsă de trafic (raportat de The New Stack, „Return of the Monolith: Amazon Dumps Microservices for Video Monitoring”, martie 2023). Segment (azi parte din Twilio) a publicat un caz similar în 2018: a migrat de la peste 140 de microservicii mici, greu de întreținut, înapoi la un singur monolit, pentru că numărul lor depășise capacitatea echipei de a le opera eficient (Alexandra Noonan, „Goodbye Microservices: From 100s of problem children to 1 superstar”, Twilio Segment Engineering Blog, 10 iulie 2018). Ambele companii aveau resurse tehnice considerabile; pentru o echipă mică fără DevOps dedicat, riscul e și mai mare.

Calea pragmatică: arhitectură pregătită să evolueze, nu impusă de la început

Decizia corectă nu e „alegem monolit sau microservicii o dată, pentru totdeauna”. E să construiești un monolit modular cu granițe interne suficient de clare încât, dacă apare nevoie reală de scalare pe o singură componentă, s-o poți extrage ca serviciu separat fără să rescrii restul sistemului. Nu porni de la un boilerplate generic care amestecă tot; separă din start straturile de date, logică și interfață, cu contracte interne consistente între module.

• —Un singur domeniu are nevoi tehnice foarte diferite (hardware, IoT, throughput izolat)? Dacă da, separă doar acel domeniu ca serviciu propriu; restul rămâne monolit modular.
• —Ai deja o echipă dedicată de DevOps/platformă care poate opera infrastructură distribuită? Dacă nu, rămâi pe monolit modular, cel mai probabil e alegerea corectă acum.
• —Doar o parte a sistemului are nevoie reală de scalare orizontală, la trafic concurent mare? Dacă nu, rămâi pe monolit modular. Dacă da, extrage acea componentă ca microserviciu; restul rămâne monolit modular.

Dacă răspunsul la toate cele trei întrebări e „nu”, nu ai încă un motiv real să adaugi microservicii. Poți reveni oricând peste șase luni sau un an, când situația se schimbă.

Cum decizi, practic, pentru propria aplicație B2B

Pornește de la fluxul real al afacerii, nu de la o arhitectură citită undeva. Notează ce parte a sistemului are cel mai mare risc de a avea nevoie de scalare izolată sau de o echipă separată în următoarele 12-18 luni. Dacă răspunsul e „nicio parte, deocamdată”, monolitul modular te lasă să livrezi mai repede și să cheltui bugetul pe funcționalități, nu pe infrastructură. Verifică apoi dacă ai deja capacitatea de a opera infrastructură distribuită, monitorizare și alerte incluse; fără asta, orice discuție despre microservicii e prematură, indiferent cât de „modernă” pare pe hârtie.

Concluzia practică

Monolitul modular câștigă discuția pentru majoritatea aplicațiilor web custom B2B, nu pentru că microserviciile ar fi o modă depășită, ci pentru că rezolvă o problemă (scalare izolată, echipe independente) pe care puține proiecte noi o au din prima zi.

Dacă nu ești sigur dacă afacerea ta are nevoie de o aplicație custom, pasul dinainte de discuția de arhitectură e semnele că ai nevoie de o aplicație custom. Odată clarificat că da, arhitectura pe straturi separate rămâne punctul de plecare corect, fie că ai nevoie de un monolit modular, fie, ca la Titan, de servicii separate pentru domenii tehnice specifice.