Zašto modularni monolit pobeđuje pre mikroservisa

Moderna inženjerska kultura mikroservise često smatra „profesionalnim“ izborom arhitekture. Timovi slušaju priče o Netflix-u, Amazonu, Uberu i velikim distribuiranim sistemima, pa pokušavaju da kopiraju te arhitekture mnogo prerano.

Rezultat je obično predvidiv: desetine servisa, duplirana logika, krhko puštanje izmena, noćne more pri distribuiranom debagovanju, nejasno vlasništvo nad podacima i infrastrukturni tim koji se davi u operativnoj složenosti.

U praksi, mnogi uspešni sistemi se razvijaju mnogo stabilnijim putem:

Monolit → modularni monolit → mikroservisi tamo gde imaju smisla

Ovaj prelaz je važan jer su problemi arhitekture obično problemi povezanosti, a ne problemi puštanja izmena.

Pravi problem je povezanost

Mnogi stari sistemi deluju ogromno jer svaki deo aplikacije direktno dodiruje svaki drugi deo.

Modul za rezervacije direktno čita tabele plaćanja. Servis za obaveštenja menja podatke o rezervacijama. Zajedničke pomoćne klase tiho postaju zavisnost cele platforme. Šema baze postaje globalno deljeno stanje.

Deljenje ovakvog sistema na mikroservise ne rešava problem magično. Često ga pogoršava.

Umesto jedne čvrsto povezane aplikacije, sada imaš više čvrsto povezanih aplikacija koje komuniciraju preko HTTP-a.

Po čemu je modularni monolit drugačiji

Modularni monolit zadržava jednostavno puštanje izmena, a uvodi čvrste unutrašnje granice.

Umesto da se aplikacija tretira kao jedan ogroman kod, sistem postaje skup izolovanih poslovnih modula sa jasno definisanim ugovorima.

Svaki modul je vlasnik:

• svoje domenske logike
• svojih tabela ili šeme u bazi
• svojih slučajeva korišćenja
• svog javnog API-ja
• svojih internih detalja implementacije

Zvuči jednostavno, ali suštinski menja način na koji timovi razmišljaju o arhitekturi.

Kada moduli prestanu direktno da pristupaju unutrašnjosti jedni drugih, kasnije izdvajanje u posebne servise postaje dramatično lakše.

Granice su važnije od tehnologije

Jedna od najvažnijih ideja Domain-Driven Design-a je koncept ograničenih konteksta (bounded contexts).

Cilj nije da se naprave „mali servisi“. Cilj je da se definišu poslovne granice u kojima odgovornosti ostaju povezane u celinu.

Na primer, platforma za smeštaj može da razdvoji:

• Pretragu
• Rezervacije
• Cene
• Plaćanja
• Recenzije
• Obaveštenja

To nisu samo folderi. To postaju nezavisni poslovni domeni sa kontrolisanim pravilima međusobne saradnje.

Timovi ovde često greše jer dele po tehničkim slojevima:

/controllers
/services
/repositories
/entities

Takva struktura izgleda uredno, ali stvara horizontalnu povezanost kroz ceo sistem.

Modularna arhitektura umesto toga grupiše po poslovnoj sposobnosti:

/modules
  /reservation
  /payment
  /pricing
  /search

Ovakav pristup prirodno otkriva granice vlasništva i čini strategije izdvajanja mnogo jasnijim.

Povezanost kroz bazu je obično najveći problem

Većina monolita nije povezana samo kroz kod. Povezana je kroz bazu.

Deljene tabele postaju nevidljivi API-ji.

Kada više modula direktno čita i menja iste tabele, nezavisan razvoj postaje skoro nemoguć.

Modularni monolit treba odlučno da smanjuje ovu vrstu povezanosti.

Jaki sistemi često uvode pravila kao što su:

• Nema direktnih upita u tabele drugog modula
• Nema deljenih ORM entiteta između modula
• Nema skrivenih sporednih efekata kroz zajedničko skladištenje
• Komunikacija samo kroz javne interfejse

Čak i kad sve i dalje radi u jednoj izvršnoj aplikaciji, ova pravila simuliraju disciplinu koju zahtevaju distribuirani sistemi.

Poruke pre izdvajanja

Jedan od najpametnijih obrazaca u velikim migracijama je uvođenje asinhronih poruka pre nego što se servisi fizički izdvoje.

Umesto direktnih poziva modula, aplikacija počinje da komunicira kroz događaje.

ReservationCreated
PaymentConfirmed
InvoiceGenerated
EmailRequested

U početku se ove poruke i dalje mogu prenositi potpuno unutar procesa.

Bitno je da se model komunikacije promeni pre nego što se promeni infrastruktura.

To je izuzetno moćno, jer kasnije možeš da zameniš prenos u memoriji RabbitMQ-om, Kafkom ili drugim brokerom, bez prepisivanja same poslovne logike.

Izdvajanje treba da bude postepeno

Jedna od najvećih grešaka firmi je pokušaj „prepisivanja na mikroservise“.

Takvi projekti često postanu višegodišnji arhitektonski programi nejasne poslovne vrednosti.

Bezbednija strategija je postepeno izdvajanje.

Počni od modula koji ima:

• veliki saobraćaj
• često puštanje izmena
• sukobe oko vlasništva između timova
• uska grla u performansama
• pritisak da se skalira

Izdvoji jednu sposobnost, usmeri zahteve kroz reverse proxy, pažljivo prati ponašanje i nastavi tek kad se operativni model stabilizuje.

To prati Strangler Fig obrazac:

Zameni sistem postepeno, dok stari i novi postoje paralelno.

Mikroservisi su organizacioni alat

Neprijatna istina u razvoju softvera je da mnogi sistemi prelaze na mikroservise zbog strukture timova, a ne zbog čiste tehničke potrebe.

Nezavisno puštanje izmena, izolovano vlasništvo i paralelna samostalnost timova postaju vredniji kako organizacija raste.

Malim timovima retko trebaju desetine distribuiranih servisa.

Zapravo, dobro organizovan modularni monolit godinama može da nadmašuje mikroservise, a da ostane dramatično jednostavniji za održavanje.

Razlika u operativnom teretu je ogromna.

Sa mikroservisima timovima odjednom trebaju:

• otkrivanje servisa (service discovery)
• distribuirano praćenje zahteva
• centralizovano logovanje
• API gateway-i
• strategije ponovnih pokušaja
• circuit breaker-i
• platforme za orkestraciju
• inženjering otpornosti

To nisu „besplatne nadogradnje skalabilnosti“. To su cele inženjerske discipline.

Kada mikroservisi zaista imaju smisla

Mikroservisi postaju vredni kada poslovna ograničenja ili ograničenja skaliranja opravdavaju dodatnu složenost.

Uobičajeni pokazatelji su:

• više nezavisnih inženjerskih timova
• veoma različiti zahtevi skaliranja po modulima
• odvojeni životni ciklusi puštanja izmena
• potreba za specijalizovanim tehnologijama
• strogi zahtevi za izolacijom otkaza

Ključni uvid je da mikroservisi treba prirodno da proisteknu iz rešenih granica, a ne iz arhitektonske pompe.

Zaključak

Najopasniji deo mikroservisa nije sama tehnologija, već uvođenje složenosti distribuiranih sistema pre nego što organizacija razume sopstvene granice.

Modularni monolit nudi bezbedniji put, jer tera timove da prvo reše osnove arhitekture:

• jasno vlasništvo
• nisku povezanost
• javne ugovore
• izolaciju domena
• kontrolisanu komunikaciju

Kad su ti problemi rešeni, izdvajanje servisa postaje inženjerska odluka, a ne rizično prepisivanje.

Zato mnogi moderni sistemi za veliko opterećenje nisu „monolit protiv mikroservisa“.

To su pažljivo razvijani modularni sistemi koji su izdvojili samo ono što je zaista moralo da bude distribuirano.