Микросервиси или модуларни монолит?

Kada planiramo novu internet prodavnicu, sistem za upravljanje narudžbinama ili integracioni sistem za proizvodnju, pitanje "mikroservisi ili modularni monolit" retko je samo tehnološka rasprava. Izbor će uticati na brzinu izdavanja, praćenje grešaka, operativno opterećenje, pouzdanost integracije i koliko se sistem uklapa u stvarno poslovanje kompanije. Loše tempirana arhitektonska odluka možda neće odmah izazvati probleme, ali može godinama uticati na troškove razvoja i operacija.

Granice sistema su važnije od tehnološke etikete

Dva pristupa se često pojednostavljuju. Monoliti se opisuju kao zastareli, teško promenljivi sistemi, dok se mikroservisi smatraju automatski skalabilnim, modernim ciljnim stanjima. Ovo je obmanjujuće. Dobro izgrađen modularni monolit može biti transparentan, testabilan i održiv poslovni sistem na duge staze. Slično tome, nepotrebno fragmentirano okruženje mikroservisa može predstavljati trajne rizike sa mrežnim greškama, sinhronizacijom podataka i mnogim odvojenim jedinicama za implementaciju.

Pravo pitanje je gde se nalaze prirodne granice poslovnih procesa. Na primer, obrada narudžbina može povezivati rezervaciju zaliha, određivanje cena, prenos faktura, logističku organizaciju i komunikaciju sa klijentima. Ako ovi koraci čine blisku poslovnu transakciju, rano razdvajanje može značajno povećati složenost. Međutim, ako se menjaju različitim tempom, različiti timovi ih obrađuju ili imaju različite zahteve dostupnosti i opterećenja, razdvajanje može imati poslovno opravdanje.

Arhitektura treba da služi opravdanom poslovanju, a ne organizacionoj modi. Cilj nije imati što više komponenti, već brzo utvrditi šta se dogodilo, gde se dogodilo i kako se proces može kontrolisano obnoviti u slučaju greške narudžbine, kasnih podataka dobavljača ili prekida veze sa ERP-om.

Kada je korisno započeti sa modularnim monolitom?

Modularni monolit je jedna aplikacija koja se može implementirati, gde su funkcije organizovane u jasno odvojene poslovne module. Primeri uključuju katalog proizvoda, upravljanje narudžbinama, procesi skladišta, integracije partnera ili upravljanje pristupom. Aplikacija radi kao celina, ali moduli imaju sopstvenu odgovornost, pravila upravljanja podacima i dobro definisane unutrašnje interfejse.

Ovo je posebno dobar početak za srednje velike poslovne sisteme, gde je potrebno ujediniti više unutrašnjih i spoljašnjih procesa, ali razvojna i operativna organizacija još ne opravdava postojanje desetina nezavisnih usluga. Na primer, u platformi za narudžbine i logistiku, konzistentnost podataka, praćenje procesa i brza poslovna prilagodljivost često su važniji od pokretanja svake funkcije u zasebnom kontejneru.

Prednost modularnog monolita je što je upravljanje transakcijama jednostavnije, potrebno je manje sistema za otklanjanje grešaka, a lanac implementacije je lakše pregledan. Interakcije poslovnih pravila mogu se upravljati u jednoj verziji izdanja. To ne znači da sistem može postati neuređena masa koda sa zajedničkim tabelama baze podataka. Naprotiv, granice modula treba disciplinovano upravljati od prvog dana.

Ograničenja pristupa postaju vidljiva kada jedno funkcionalno područje dobija vrlo različita opterećenja, razvija se u različitim životnim ciklusima ili koordinacija izdanja postaje nesrazmerno spora. U takvim slučajevima, ceo sistem ne mora biti ponovo napisan; umesto toga, treba ispitati koji moduli su zreli za razdvajanje.

Kada su mikroservisi opravdani?

Arhitektura mikroservisa pruža stvarne prednosti kada su nezavisne usluge autonomne i sa poslovnog i sa operativnog aspekta. Usluga ima jasnu odgovornost, sopstveni interfejs, po mogućstvu sopstveno vlasništvo nad upravljanjem podacima i zaseban proces implementacije. Ne radi se samo o tome da se delovi postojeće aplikacije stave u odvojene procese ili kontejnere.

Može biti opravdano, na primer, razdvajanje usluge sa velikim prometom informacija o proizvodima i cenama, ako se koristi na različite načine u internet prodavnicama, B2B portalima, tržištima i internim prodajnim sistemima. Slično tome, sloj za integraciju dobavljača koji komunicira sa više dobavljača, a zahteva sopstvena pravila za ponovno pokušavanje, beleženje i obradu, može biti nezavisno područje. U ovim slučajevima, odvojeno skaliranje, nezavisna izdanja i ciljana obrada grešaka mogu stvoriti opipljivu poslovnu vrednost.

Međutim, troškovi su značajni. Mrežna komunikacija između usluga može se pokvariti ili odložiti. Ono što je ranije bila jednostavna transakcija baze podataka, postaje upravljanje porukama, obrada događaja, ponovljena obrada i ponekad privremeno različita stanja podataka. Identifikacija usluge, kontrola pristupa, centralizovano beleženje, prikupljanje metrika, upozorenja, upravljanje konfiguracijom, sigurnosne kopije i kompatibilnost verzija su zadaci koji se moraju rešiti. Ovo nisu dodatni zadaci, već deo arhitekture.

Mikroservisi ili modularni monolit: koje dokaze treba da vode našu odluku?

Odluku treba izvesti iz stvarnog poslovanja, a ne iz pretpostavljene buduće veličine. Činjenica da kompanija želi da raste sama po sebi ne opravdava mikroservise. Rast često prvo zahteva čiste osnovne podatke, pouzdane integracije, konzistentne modele pristupa i merljive procese.

Prvo, treba odrediti koja poslovna područja se često i nezavisno menjaju. Ako svaka promena u logici skladišta zahteva potpuno izdanje za portal klijenata, fakturisanje i određivanje cena, granice su verovatno preuske. Međutim, ako se funkcije obično menjaju kao deo poslovnog procesa, odvojena implementacija može doneti više koordinacije nego koristi.

Drugo, treba ispitati vlasništvo nad podacima. Mnoge arhitekture postaju teško upravljive jer više usluga direktno menja iste podatke o narudžbinama, klijentima ili zalihama. U mikroservisima, svaki kritični objekat podataka treba da ima jasnog vlasnika. Drugi sistemi mogu tražiti podatke ili pokretati procese putem interfejsa ili događaja. Ovo zahteva veću disciplinu, ali čini odgovornost predvidljivijom.

Treće, operativnu zrelost treba realno proceniti. Da li postoji jedinstveno beleženje i praćenje? Može li se poslovna transakcija pratiti kroz više sistema? Da li se tajne i pristupi bezbedno upravljaju? Da li su procesi testiranja i izdavanja automatizovani sa mogućnostima vraćanja? Ako ovo još nije uspostavljeno, vredi ojačati osnove pre nego što se uvedu mikroservisi.

Postepeno razdvajanje obično nosi manji rizik

Arhitektura nije jednokratna, konačna odluka. Disciplinovani modularni monolit pogodan je za kasnije ciljano razdvajanje funkcija, gde se potrebe za nezavisnošću opravdavaju. U postepenom pristupu, prvo se uspostavljaju stabilne unutrašnje granice modula, dokumentovani interfejsi i odvojene odgovornosti. Zatim, konkretno, područje visoke vrednosti—kao što je prenos podataka o partnerima ili obrada obaveštenja—može postati nezavisna usluga.

Razdvajanje treba povezati sa merljivim problemima. To mogu biti trajno različiti profili opterećenja, česte i nezavisne poslovne promene, specifični tehnološki zahtevi ili izolacija grešaka u spoljašnjoj integraciji. "Jednog dana će se dobro skalirati" nije dovoljan razlog ako se pritom pogoršava dnevna operativna transparentnost.

U mnogim slučajevima, hibridno rešenje je najbolje. Centralni poslovni procesi ostaju u modularnom monolitu, dok asinkrona, velika količina ili intenzivna komunikacija sa spoljnim sistemima funkcionišu kao odvojene usluge. Ovo je posebno relevantno za ERP, internet prodavnice, integracije skladišta i dobavljača, gde pouzdanost spoljašnjih veza i upravljanje ponovnom obradom zahtevaju nezavisnu pažnju.

Operativnost kao zahtev za dizajn

Bez obzira na izabrani model, operativne zahteve treba definisati u fazi dizajna. Poslovno kritičan sistem mora upravljati grešnim ili nedostajućim porukama, ponovljenom obradom, beleženjem pristupa, sigurnosnim kopijama, praćenjem kapaciteta i kontrolisanim izdanjima. Ovo nisu samo infrastrukturni zadaci; direktno utiču na izvršenje narudžbina, tačnost podataka o zalihama i preciznost finansijskih procesa.

U CGAT pristupu, izbor arhitekture počinje procenom poslovnih procesa, identifikacijom integracionih granica i razjašnjavanjem operativnih zahteva. Vrednost sistema ne određuje broj usluga koje sadrži, već kako služi kompaniji na kontrolisan, održiv način, u skladu sa svakodnevnim poslovanjem, čak i usred promena.

Pre sledeće razvojne odluke, vredi postaviti pitanje, ne koja arhitektura zvuči modernije, već koja struktura čini kritične poslovne procese razumljivijim, prilagodljivijim i operativnijim za godinu dana.