Razbiti monolit ili stabilizirati? Kriteriji za odluku pri modularnoj modernizaciji

Ponedjeljak ujutro, 9:10: Jedan poslovni odjel prijavljuje „malo prilagođenje“ u procesu naručivanja. IT kratko pogleda tekst tiketa, čini se izvedivim. Dvije sata kasnije raspoloženje je drugačije. Build traje duže nego što je planirano, pomoćni posao ovisi o istom release-paketu, a pogled u bazu podataka otkriva: ova promjena pogađa više tablica i triggera nego što se očekivalo. Najkasnije sada pojavljuje se pitanje koje mnoge timove redovito muči: Raspad monolita ili stabilizacija?

Tko na to refleksno odgovori „Mikroservisi!“, često propušta suštinu: nije riječ o arhitektonskom etiketu, nego o sposobnosti isporuke i sigurnosti u radu. Ovaj praktični vodič vodi kroz pragmatičnu provjeru, pokazuje kriterije odlučivanja za modularnu modernizaciju i opisuje izvedive korake. Uz to navodi tipične pogreške te jasne točke prekida i eskalacije – kako modernizacija ne bi postala dugotrajni projekt bez mjerljivog učinka.

Raspad monolita ili stabilizacija: prvo simptom, pa arhitektura

„Monolit je kriv“ zvuči nedvosmisleno, ali rijetko je dovoljno precizno za odluku. Monolit (aplikacija kao zajednički deployment-artifikat) može vrlo pouzdano raditi – ili stvoriti stalno trenje. Isto vrijedi: Mikroservisi (mnogo malih, odvojeno rasporedivih servisa) mogu smanjiti vrijeme isporuke, ali nužno donose više operativnih zadataka.

Martin Fowler realnost suzdržano svrstava: Microservices su prije svega drugačiji operativni otisak – dakle drugačiji operativni napor s više komponenti, više deploymenta, više izvora pogrešaka i većom potrebom za automatizacijom.^[Izvor] Ograničenje ove tvrdnje: ona ne zamjenjuje analizu vašeg sustava. Praktičan zaključak je ipak jasan: tko proglasi „Microservices“ ciljem prije nego što je usko grlo jasno opisano, brzo modernizira na pogrešnom mjestu.

Kriteriji za odluku: Kada razdvajanje zaista pomaže – a kada ne

Pritisak za modernizacijom je stvaran: zahtjevi za sigurnošću rastu, broj sučelja se povećava, timovi se mijenjaju, i poslovni softver treba istovremeno nastaviti raditi i razvijati se. Razdvajanje može biti smislen korak – ali samo ako adresira usko grlo, a ne samo uljepšava dijagram arhitekture.

Kriterij 1: Operativna zrelost – može li vaše poslovanje podnijeti operativni otisak?

S svakom dodatnom jedinicom koja se može deployati raste potreba za urednom isporukom i nadzorom: CI/CD (automatizirani lanac build/test/deploy), Observability (metrike, logovi i traces za dijagnostiku), procesi za incidente, runbookovi i jasne odgovornosti. AWS to formulira kao procjenu: finija segmentacija može donijeti prednosti za pouzdanost i skaliranje, ali povećava operativnu složenost s rastom broja komponenti.^[Izvor] Ograničenje: to je smjernica, a ne jamstvo uspjeha. Zaključak: Ako danas već imate poteškoća stabilno izvesti deployment, okruženje s više servisa će taj problem pomnožiti.

Konkretne provjere koje se ne smiju zanemariti:

• Sposobnost izdanja: Rollback/Backout je definiran, vremenski prozori za održavanje i komunikacija su uspostavljeni.
• Monitoring & alarmiranje: alarmi su usmjereni na djelovanje (ne „sve crveno“), izvori pogrešaka se mogu izolirati.
• Postupanje s incidentima: postoji ritam za postmortem analize i mjere, ne samo ad-hoc gašenje požara.
• Ownership: Tko odlučuje o sučeljima, tko prioritizira, tko odgovara za operacije i kvalitetu?

Kriterij 2: Odvajanje promjena – blokiraju li se zahtjevi međusobno?

Razdvajanje se isplati ako se neovisne promjene u monolitu redovito međusobno ovisno vežu, iako su funkcionalno odvojene. Tipičan obrazac: područje portala treba česte prilagodbe, dok područje obračuna rijetko smije biti mijenjano i zahtijeva visoku pažnju. Ako se oba uvijek nađu u istom izdanju, koče jedno drugo.

S druge strane, razdvajanje je često autogol kada gotovo svaka promjena prolazi kroz mnoga područja (ovlasti, logika cijena, reporting, čišćenje podataka). Tada se stvara promet preko sučelja umjesto razdvajanja – i koordinacija raste umjesto da opada.

Kriterij 3: Povezanost podataka – skriva li se složenost u bazi podataka?

Mnogi sustavi su više povezani kroz podatke nego kroz kod: zajedničke tablice, triggeri, transakcijski procesi i batch poslovi. Sam Newman ističe u svojim uzorcima dekompozicije da je stvarni izazov često strategija podataka i integracije – i da su Big-Bang-projekti pri tome osobito rizični.^[Quelle]

Praktičan zaključak za operacije: Ako nekoliko komponenti bez pravila piše u iste tablice, nastaju nuspojave koje je teško čisto vratiti. Modularna modernizacija zato zahtijeva rane odluke o nadležnosti nad podacima, konzistenciji i razdvajanje izvještavanja.

Kriterij 4: Stabilnost i stručna vrijednost – što se mora sačuvati?

U razvijenim digitalnim poslovnim rješenjima često je sadržana mnogo ispravno modelirane domenske logike: posebni slučajevi, komercijalna pravila, iznimke u procesima, povijesno nastala čišćenja podataka. To nije „legacy-smeće“, već često razlog zašto posao uopće funkcionira. Modernizacija postaje ekonomski opravdana kada ne odbaci taj vrijednosni sloj olako – i istovremeno identificira mjesta koja rad i daljnji razvoj čine nerazmjerno skupima.

Odabir: Tri ciljna pristupa koja funkcioniraju u poduzećima

Između „sve ostaje“ i „sve postaje Microservices“ postoje praktični ciljni modeli koji modernizaciju čine planiranom. AWS Prescriptive Guidance izričito preporučuje prije dekompozicije provjeriti koji dijelovi uopće trebaju biti dekomponirani i preferirati inkrementalne pristupe.^[Quelle]

Praktični vodič: Od provjere do provedbe (s Stop/Go točkama)

1) Učiniti granice sustava vidljivima – dovoljno male da ih se koristi

Ne trebate 80-straničnu sistemsku dokumentaciju da biste mogli odlučiti. Korisna je kompaktna karta: glavni procesi, kritične sučelnice (npr. portali, EDI, izvoz datoteka, REST-APIs), batch-jobovi, kao i mjesta s visokom podložnošću kvarovima. Cilj: moći donositi odluke, ne arhivirati znanje.

Pokazalo se korisnim sagledavanje koje spaja operativu i poslovnu jedinicu: „Koji je segment procesa poslovno kritičan i o čemu on tehnički ovisi?“ Tada brzo postane vidljivo gdje bi ekstrakcija bila rizična – i gdje bi ona zapravo mogla donijeti olakšanje.

2) Baseline-Metriken definieren – sonst bleibt es eine Glaubensfrage

Modernizacija bez baseline-a je kao optimizacija performansi bez mjerenja. Presudne su metrike koje obuhvaćaju i Delivery i operativu: Deployment-Frequenz, Lead Time (od zahtjeva do produktivnog stanja), Change Failure Rate (poteškoće nakon promjena), MTTR (Mean Time to Recovery) i ponavljajuće klase incidenata. Metrike ne moraju biti akademski savršene – ali moraju se dosljedno prikupljati, da bi Stop/Go bio moguć.

3) Kandidaten schneiden – nach Domäne, nicht nach Technikschichten

Čest pogrešan početak je rez po slojevima („UI-Service“, „DB-Service“). To stvara nove ovisnosti umjesto da ih smanjuje. Rez po domeni znači: modul je odgovoran za poslovno područje uključujući pravila i podatke. To je timovima obično konkretnije nego čisto tehnička podjela.

Ako ne možete imenovati poslovne granice, to nije razlog za brže rezanje – nego signal da se prvo stabilizira i modularizira unutar monolita: razjasniti pojmove, razumjeti tokove podataka, identificirati poprečne funkcije.

4) Strangler statt Big Bang – kontrolliert umleiten, konsequent abschalten

Kad je dostupnost važna i rizike treba kontrolirati, Strangler-Fig-Pattern je pouzdan put: funkcije se postupno zamjenjuju pokraj postojećeg sustava; promet se kontrolirano preusmjerava dok se stare staze ne isključe.^[Quelle]

Važna je disciplina iza uzorka: jasne odluke o routingu, kompatibilnost podataka i sučelja, monitoring preko oba puta – i stvarno „Done“, kad je stara staza uklonjena. Inače paralelni rad postane trajno stanje.

5) Rano definirati strategiju podataka i izvještavanja

U praksi se modernizacija često odlučuje na temelju dva pitanja: tko „posjeduje“ koje podatke – i kako se izvještava? Ako izvještavanje izravno pristupa operativnim tablicama, to blokira promjene. Ako više komponenti „dijeli“ podatke bez pravila, nastaju nekonzistentnosti.

Stoga eksplicitno planirajte:

• Vlasništvo nad podacima: koji modul je vodeći za koju entitetu (kupac, narudžba, račun …)?
• Zahtjevi konzistentnosti: gdje je potrebna snažna konzistentnost, gdje je dovoljna eventualna konzistentnost?
• Odvajanje izvještavanja: kako se osiguravaju analize bez očvršćivanja operativnih modela?

6) Definirati sigurnost i operacije po modulu – ne naknadno dodavati

S svakom novom komponentom povećava se površina napada: komunikacija između servisa, tajne, dopuštenja, audit-trailovi. Rano razjasnite kako se autentikacija (npr. centralno preko SSO) i autorizacija (na temelju uloga/prava po domeni) međusobno uklapaju. Za svakodnevni rad važno je i: logovi moraju biti dijagnostički korisni, ali ne smiju kršiti pravila o zaštiti podataka i čuvanju. Ti elementi pripadaju u runbookove i operativnu dokumentaciju – ne samo u arhitektonske prezentacije.

8-koraka kontrolna lista za pouzdanu Go/No-Go odluku

1. Naznačiti usko grlo: Što točno treba biti bolje (trajanje releasa, stabilnost, skaliranje, paralelni razvoj)?
2. Mjeriti bazu (Baseline): Koji pokazatelji opisuju trenutno stanje (Lead Time, Change Failure Rate, MTTR itd.)?
3. Provjeriti operativnu sposobnost: CI/CD, monitoring, alarmiranje, runbookovi, incident-procesi, vlasništvo.
4. Ocrtati presjek domena: Gdje su prirodne stručne granice? Što su poprečne teme?
5. Izraditi strategiju podataka: vlasništvo nad podacima, konzistentnost, izvještavanje, migracijski putevi.
6. Inventarizirati ovisnosti: poslovi, sučelja, izvoz datoteka, skupine korisnika, dopuštenja.
7. Planirati slice: mali isporučivi paket uključujući rollback i ciljeve monitoringa.
8. Odrediti Stop/Go kriterije: Koji signali zaustavljaju razdvajanje ili nameću korak stabilizacije?

Tipični obrasci grešaka – ovako izgledaju u radu

Greška 1: Više komponenti, ali bez vlasništva

Ako nitko nije odgovoran end-to-end (prioriteti, kvaliteta, operacije), razdvajanje postaje problem usklađivanja. U slučaju incidenta to vodi do dugih krugova, nejasnih odluka i refleksa da se ponovno „sve zajedno“ deploya. Protumjera: za svaki modul jasan krug vlasnika, definirana predavanja i zapisnik odluka za sučelja i vlasništvo nad podacima.

Greška 2: Dijeljeni podaci bez pravila

Ovo anti-pattern je poznato: servisi su odvojeni, ali i dalje pišu u iste tablice ili koriste izravne pristupe bazi podataka preko domena. To krši izolaciju, otežava audite i čini rollbackove nepouzdanima. Protumjera: pristupi podacima preko definiranih sučelja, jasna odgovornost za podatke i – gdje je potrebno – kontrolirana sinkronizacija (npr. eventi).

Greška 3: Mrežna latencija i kaskade grešaka se „planiraju“, ali se ne testiraju

Ono što je u monolitu bio in-process poziv, u distribuiranim arhitekturama postaje mrežni poziv s timeoutima, ponovnim pokušajima i potencijalnim kaskadama. Bez jasnih timeouta, korelacije (Request-IDs) i realističnih end-to-end testova analiza grešaka postaje znatno složenija. Protumjera: jasni SLOs (mjerljivi ciljevi servisa), definirani timeouti, korelacija traceova i load testovi duž kompletnih tokova procesa.

Pogreška 4: Rezanje po organigramu umjesto po domenskoj logici

Ako servisi prvenstveno preslikavaju granice timova, a funkcionalno prolaze poprijeko kroz procese, povezanost ostaje — samo na drugoj razini. Protumjera: rez koji odgovara domeni, iako to isprva izaziva trenje. Ako je to organizacijski nemoguće, modularni monolit je često bolji međukorak.

Točke prekida i eskalacije: Kada stabilizacija postaje bolja odluka

Projekt modernizacije treba pravila za zaustavljanje, inače pojede budžet i pažnju. Sljedeći signali su snažni razlozi da se svjesno prebacite:

• Operativno preopterećenje: poplava alarma, rastući MTTR, dežurstva se više ne mogu pokriti.
• Nema mjerljivog poboljšanja: Lead Time, Change Failure Rate ili stabilnost se ne poboljšavaju jasno.
• Kompleksnost sučelja eksplodira: verzioniranje nejasno, Breaking Changes se gomilaju, otklanjanje pogrešaka postaje pogađanje.
• Sukobi podataka: inkonzistentnosti, kontradiktorne/duple istine, teško objašnjive razlike u izvještajima.
• Vlasništvo ostaje nejasno: odluke dugo traju, nitko ne snosi odgovornost za rad i daljnji razvoj.

Eskalacija tada ne znači „povratak u staro“, već: dati prioritet stabilizaciji. Tipične mjere su: provesti regresijska ispitivanja za ključne procese, poboljšati Observability, konsolidirati pristupe podacima, izoštriti granice modula u monolitu – i tek nakon toga ponovno provjeriti donosi li ekstrakcija stvarnu korist.

Što „stabilizirati“ konkretno znači – i zašto često djeluje brže

Stabilizacija nije kozmetičko pospremanje. U radu se očituje kao manje iznenađenja i predvidljiviji releasi. Konkretni poluge koje timovi odmah osjete:

• Release-Mechanik: reproducibilan Build, konzistentna okruženja, uvježban rollback-put.
• Transparentnost: standardi logiranja, klasifikacija grešaka, korelacija zahtjeva kroz tokove procesa.
• Testfokus: Ende-zu-Ende-regresija za ključne tokove (ne samo izolirani testovi).
• Modulgrenzen im Monolithen: definirani interni APIs, discipliniran pristup podacima, jasne odgovornosti.
• Datenhygiene: jedinstveni izvori osnovnih podataka, dokumentirane nuspojave poslova, smanjena logika za posebne slučajeve.

Rezultat je često robustan modularni monolit: softver ostaje upravljiv kao cjelina, ali interno jasnije razdijeljen. Time timovi već dobivaju mnogo od onoga što očekuju od razdvajanja – bez trenutnog umnožavanja operativne složenosti.

Zadnje kontrolno pitanje prije odluke

Ako biste danas razdvajali: možete li sutra ujutro pri incidentu brzo reći, koji dio je odgovoran, tko reagira, koja metrika potvrđuje pogrešku i kako vratiti promjene? Ako ovo pitanje neugodno ostane otvoreno, odluka obično nije „više arhitekture“, nego „više operativne sigurnosti“.

Ako želite strukturirano procijeniti svoju polaznu poziciju i postaviti put modernizacije s jasnim Stop/Go-punkten, možete nas za to jednom i ciljano kontaktirati:

Za ovu temu su također važni modernizacija legacy sustava i obrazac Strangler-Fig. Članak ove aspekte jasno razjašnjava i pokazuje na što treba obratiti pozornost u svakodnevnom radu.

Razgovarajte o projektu ili modernizacijskom pothvatu s Net-Base.