Key takeaways – šta je najbitnije u ovom tekstu:
- Arhitektura nije čarobni štapić. Sama primena mikroservisa bez suštinske promene organizacione kulture i strukture timova ne dovodi do agilnosti, već stvara operativna uska grla.
- Konvejev zakon (Conway’s law) ostaje neumoljiv. Ako dizajnirate mikroservise u kompaniji sa strogim silosima, dobićete „distribuirani monolit“ koji zadržava sve mane starog sistema uz dodavanje mrežnog kašnjenja.
- Skrivena cena kognitivnog opterećenja. Razvojni timovi danas troše disproporcionalno veliku količinu vremena na održavanje infrastrukture, Kubernetes klastera i praćenje grešaka, umesto na pisanje koda koji donosi vrednost.
- Platformski inženjering (Platform engineering) je jedini izlaz. Da bi kros-funkcionalni timovi zaista bili agilni, organizacija mora izgraditi interni platformski tim koji će preuzeti infrastrukturni teret sa leđa programera.
- Moduli umesto mikroservisa kao budućnost. Praksa velikih igrača na tržištu pokazuje da je prelazak na dobro strukturiran „modularni monolit“ često pametnije, brže i jeftinije rešenje za preko 80% današnjih poslovnih potreba.
U savremenom svetu IT industrije, reč „agilnost“ je postala mnogo više od pukog metodološkog termina – ona je postala ultimativni cilj svake organizacije, od malih inovativnih startapa do multinacionalnih korporacija sa decenijskim nasleđem. U toj neprestanoj trci za bržim izbacivanjem novih softverskih funkcionalnosti na tržište, formirao se jedan veoma snažan narativ koji tvrdi da agilnost nije moguća bez potpune tehnološke transformacije. Na čelu te transformacije, kao neprikosnoveni spasitelj i arhitektonski sveti gral, nalaze se mikroservisi.
Obećanje je od starta zvučalo gotovo idilično. Rečeno nam je da ćemo, ako razbijemo našu ogromnu i nepreglednu monolitnu aplikaciju u stotine sitnih, potpuno nezavisnih servisa, konačno uspeti da oslobodimo timove. Svaki razvojni tim moći će da preuzme vlasništvo nad jednim specifičnim delom koda, da bira programski jezik i bazu podataka koja im najviše odgovara, i najvažnije od svega – moći će da isporučuje svoj kod u produkciju po nekoliko puta dnevno. Sve to zvuči kao savršeno otelotvorenje onoga što agilni razvoj softvera zagovara u svojoj suštini.
Ipak, stvarnost na terenu je često radikalno drugačija i bolna. Mnogi direktori IT sektora i tehnološki lideri se danas, nakon godina mukotrpne tranzicije, desetina hiljada utrošenih inženjerskih sati i stravično probijenih budžeta za infrastrukturu, suočavaju sa otrežnjujućom činjenicom. Funkcionalnosti se isporučuju sporije nego ranije, pronalazak uzroka grešaka (debugging) podseća na traženje igle u plastu sena, a inženjeri su isfrustrirani jer više vremena provode čitajući konfiguracione fajlove nego što zaista programiraju. Postavlja se zato vrlo ozbiljno pitanje: da li su mikroservisi zaista katalizator agilnosti, ili su postali jedan od najvećih generatora operativnog haosa u modernom IT-ju?
Demistifikacija prošlosti – zašto smo uopšte zamrzeli monolit?
Da bismo zaista razumeli problematiku modernih softverskih arhitektura, moramo se na trenutak vratiti unazad i sagledati od čega smo mi to zapravo bežali. Tradicionalna, monolitna arhitektura podrazumeva sistem u kom su korisnički interfejs, poslovna logika, sloj za pristup podacima i pozadinski procesi duboko integrisani u jednu jedinstvenu bazu koda. Cela ova struktura se pakuje i pokreće kao jedan masivni proces na serveru.
U početnim fazama razvoja proizvoda, monolit je bio fantastično rešenje. Bio je neverovatno jednostavan za postavljanje lokalnog razvojnog okruženja, proces testiranja od početka do kraja aplikacije (end-to-end testing) je bio pravolinijski, a pronalazak grešaka se svodio na praćenje jednostavnog niza poziva funkcija (stack trace) u memoriji jednog računara.
Međutim, kako je poslovanje raslo, tako je i baza koda bujala, često potpuno van kontrole. Stotine programera su svakodnevno menjale isti sistem, što je dovelo do stvaranja „špageti koda“ – stanja u kom je svaka komponenta sistema čvrsto uvezana sa svakom drugom komponentom. U takvom okruženju, čak i najsitnija izmena u modulu za obradu slika mogla bi, iz potpuno neobjašnjivog razloga, da sruši modul za naplatu karticama. Isporuka novih verzija u produkciju pretvarala se u prave male noćne more, obično zakazivane za vikende duboko u noć, kada bi celi timovi nervozno posmatrali ekrane čekajući da sistem negde otkaže.
Skaliranje je bio još jedan veliki izazov. Nismo mogli da skaliramo samo onaj deo sistema koji je pod najvećim opterećenjem, već smo morali da umnožavamo celu tu ogromnu aplikaciju na više servera, što je bilo izrazito rasipnički iz ugla resursa. Monolit je tako, usled manjka discipline, postao sinonim za tromost i tehnički dug.
Lažno obećanje mikroservisa – šta se dešava kada teorija udari u praksu
Suočena sa problemima monolita, softverska industrija je rešenje pronašla u arhitektonskom obrascu mikroservisa. Koncept nalaže striktno deljenje sistema na male komade, pri čemu svaki servis mora biti autonomno rasporediv i odgovoran isključivo za jedan poslovni domen (na primer, odvojeni servisi za obradu plaćanja, korisničke profile, inventar, notifikacije). Umesto direktnog pozivanja funkcija unutar istog koda, ovi servisi sada razmenjuju podatke preko mreže, najčešće kroz REST API pozive ili sinhrone i asinhrone poruke.
Na papiru, ovo je delovalo kao ostvarenje sna za agilne timove. Teorija kaže da jedan mali kros-funkcionalni tim sada može u potpunosti da kontroliše svoj mali servis. Kada product owner zatraži novu funkcionalnost, tim je razvije, istestira i izbaci na tržište bez da mora da sinhronizuje svoj proces isporuke sa deset drugih timova. Ali, upravo na ovom koraku mnoge IT organizacije doživljavaju bolan sudar sa realnošću.
Sistem se ne menja i ne osamostaljuje isključivo pukom arhitektonskom odlukom. Tehnički dizajn sistema je u direktnoj srazmeri sa načinom na koji ljudi unutar te kompanije komuniciraju. Ako želite da vidite konkretan primer iz prakse i analizu sličnih trendova u industriji, možete posetiti portal ITNetwork, gde se često raspravlja o ključnim arhitektonskim promenama današnjice.
Zaboravljeni konvejev zakon – organizaciona kultura jede arhitekturu za doručak
Melvin Konvej (Melvin Conway) je davne 1967. godine postavio zakon koji glasi: „Organizacije koje dizajniraju sisteme ograničene su da proizvode dizajn koji je doslovna kopija komunikacionih struktura tih organizacija“. Ovaj zakon se pokazao kao apsolutno nezaobilazna prepreka za svaku kompaniju koja u mikroservise ulazi sa pogrešnom organizacionom kulturom.
Šta to praktično znači? Ako vaša kompanija i dalje funkcioniše u starim, nasleđenim silosima – gde imate potpuno odvojen tim za frontend, odvojen tim za backend, odvojen tim administratora baze podataka i izolovan tim za infrastrukturu – prelazak na mikroservise će biti ravan katastrofi.
U takvoj kulturi, svaka i najmanja promena funkcionalnosti zahvata više servisa istovremeno. Da bi se izbacio jedan novi prozorčić na veb stranici, potrebno je otvoriti zahteve (tikete) kod tri različita tima. Sada više nemate jedan monolit koji održavate, već trideset malih servisa, pri čemu svaka sitna promena zahteva masovne sastanke, usaglašavanje API formata i čekanje da drugi timovi odrade svoj deo posla. Vaša agilnost je, tehnički gledano, u debelom minusu.
Razorni sindrom distribuiranog monolita
Kada se mikroservisi loše isplaniraju, kompanija završi sa stanjem koje je u industriji poznato kao „distribuirani monolit“. To je najgore moguće agregatno stanje u kom softver može da se nađe. Vaši servisi su tehnički i fizički odvojeni u različite mrežne kontejnere, ali su logički toliko čvrsto uvezani da je apsolutno nemoguće izmeniti bazu podataka Servisa A, a da se pritom ne mora prekodirati i restartovati Servis B i Servis C.
Sve prednosti distribuiranih sistema nestaju, ali zato dobijate sve njihove mane. Umesto običnog poziva funkcije u RAM memoriji servera (što traje nekoliko nanosekundi), vaš sistem sada komunicira preko računarske mreže. To unosi mrežnu latenciju, povremena zagušenja i pakete podataka koji mogu da se izgube. Vaša aplikacija odjednom mora da se nosi sa složenim mehanizmima kao što su povratni pokušaji (retries), vremenska ograničenja (timeouts) i složene distribuirane transakcije preko takozvanog „Saga“ šablona. Ono što je do juče bio običan upis u jednu bazu, sada postaje mukotrpan mrežni inženjering.
Kognitivno opterećenje – tihi ubica produktivnosti programera
Jedan od najčešće zanemarivanih aspekata uvođenja moderne arhitekture jeste pitanje koliko jedan prosečan inženjer zapravo može informacija da drži u svojoj glavi. Prelazak sa monolitne na distribuiranu arhitekturu eksponencijalno povećava kognitivno opterećenje.
Danas se od razvojnih inženjera očekuje ne samo da znaju svoj programski jezik, već moraju da razumeju Docker kontejnere, da pišu kompleksne konfiguracione fajlove za Kubernetes orkestraciju, da razumeju mehanizme za rutiranje saobraćaja u servisnoj mreži (Service Mesh) i da kopaju po logovima stotine servisa pokušavajući da uhvate onu jednu nit greške koja putuje kroz mrežne čvorove. Za obuku timova u radu sa ovako kompleksnim modernim ekosistemima, platforme specijalizovane za napredne digitalne strategije i SEO usluge, poput agencije Joombooz, savršeno ilustruju koliko je specifično tehničko usavršavanje odskočna daska za moderni biznis, čak i kada su u pitanju usko specijalizovani tehnološki problemi.
Ovo opterećenje doslovno isisava energiju. Umesto da tim isporučuje takozvanu poslovnu vrednost i fokusira se na želje klijenata, senior inženjeri provode nedelje debagujući nasumične padove mrežnih portova i rešavajući infrastrukturne zagonetke.
Primeri iz prakse – povratak modularnom monolitu i pragmatizmu
IT industrija konačno počinje da se suočava sa ovim problemima na zreo i otvoren način. Sve je više dokaza da mikroservisi nisu univerzalni lek i da je na određenim nivoima potrebno okrenuti se zdravom razumu.
Nedavni studijski primer giganta kao što je Amazon, tačnije inženjerskog tima za Amazon Prime Video, snažno je uzdrmao industriju. Tim je javno objavio i dokumentovao kako su, nakon prelaska sa potpuno serverless mikroservisne arhitekture nazad na klasičnu monolitnu arhitekturu za svoj modul analize video snimaka, uspeli da drastično pojednostave održavanje koda i pritom smanje troškove cloud infrastrukture za neverovatnih 90 procenata. Shvatili su da su u tom konkretnom podsistemu, mrežni pozivi između naizgled „nezavisnih“ mikroservisa postali toliko učestali i teški, da su potpuno zagušili sistem i podigli račun na nepodnošljiv nivo.
Kako pomiriti arhitekturu i agilnost?
Da bismo bili jasno shvaćeni, mikroservisi apsolutno nisu mrtvi, niti su inherentno loši. Za organizacije veličine Netflixa, Ubera ili globalnih banaka, oni ostaju neophodan mehanizam za preživljavanje ogromnog mrežnog saobraćaja i koordinaciju nekoliko hiljada inženjera. Međutim, za 80 posto preduzeća na globalnom tržištu, postoje dva drastično bolja načina za postizanje tehničke agilnosti u narednim godinama:
- Strogi modularni monolit: Vi ne morate razdvajati kod na fizički različite servere da biste imali čist dizajn. Kroz primenu dizajna vođenog domenom (Domain-driven design), moguće je kreirati kod koji se vrti kao jedan proces, ali su njegovi interni moduli savršeno razdvojeni jasnim interfejsima i barijerama. Razvojni timovi u ovom okruženju mogu da zadrže veliku brzinu isporuke i izbegnu sav infrastrukturni bol koji donose distributivni sistemi.
- Platformski inženjering (Platform engineering): Ako organizacija zaista mora da ide putem mikroservisa, neophodno je formiranje snažnog internog platformskog tima. Cilj ovog tima nije da stvara proizvod za klijente, već da razvija interne alate i automatizovane procedure za same programere. Ovaj pristup stvara takozvanu „zlatnu stazu“ (Golden path) – put kojim će agilni tim sa par klikova dobiti spreman repozitorijum, podešene baze podataka i konfigurisan CI/CD proces, a da inženjer koji taj kod piše nikada ne mora da razmišlja o postavkama mrežnih rutera ili Kubernetes podova.
Zaključak – agilnost kao stanje svesti
Moderna mikroservisna arhitektura definitivno ima potencijal da drastično poveća agilnost vaše organizacije, ali pod jednim veoma strogim uslovom – morate biti organizaciono zreli za nju.
Mikroservisi su kao vožnja bolida Formule 1. Oni mogu ići neverovatno brzo i prestići svaku konkurenciju, ali ako ih date neiskusnom vozaču na neravnom lokalnom putu prepunom rupa i blokada, rezultat neće biti brzina, već potpuni spektakl u kom se sve raspada, uz enormnu finansijsku štetu.
Prava agilnost ne leži u slepom praćenju hajpa i preslikavanju arhitekture najvećih svetskih giganata. Ona leži u donošenju pragmatičnih odluka, stalnoj borbi protiv kognitivnog opterećenja svojih timova, pažljivom restrukturiranju načina na koji ljudi komuniciraju unutar vaših sektora i korišćenju pravog alata, za tačno određeni poslovni problem. Vaša tehnologija je samo ogledalo vašeg načina razmišljanja.
FAQ
Šta su to mikroservisi i po čemu se razlikuju od monolita?
Mikroservisi predstavljaju način razvoja softvera gde se jedna velika aplikacija deli na više malih, logički odvojenih servisa koji komuniciraju preko mreže. Kod monolitne aplikacije, celokupan kod, sve poslovne funkcije i dizajn su spojeni i izvršavaju se kao jedan jedinstveni sistemski proces na serveru.
Zašto se mikroservisi često povezuju sa operativnim haosom?
Problem nastaje kada sistem deli svoj kod na mikroservise bez stvarnog razumevanja zavisnosti između njih. Održavanje ovakvog sistema zahteva kompleksno praćenje mreže, otpornost na prekide u komunikaciji i naprednu infrastrukturu, što drastično oduzima vreme programerima, preusmeravajući njihov fokus sa izrade proizvoda na dešifrovanje grešaka na serverima.
Šta znači „distribuirani monolit“?
To je antipatern u arhitekturi, situacija u kojoj ste fizički odvojili servise, ali su oni logički toliko povezani da promena u jednom zahteva kaskadno prilagođavanje i ažuriranje u nizu drugih. Rezultat je sistem koji je težak i spor za promenu (kao tradicionalni monolit), ali nestabilan i osetljiv na kvarove usled stalne mrežne komunikacije.
Kako koncept „Platformskog inženjeringa“ spašava moderne razvojne timove?
Platformski inženjering podrazumeva poseban tim u kompaniji koji gradi interne alate za automatizaciju infrastrukture. Umesto da programeri sami konfigurišu servere ili Kubernetes sisteme, oni koriste interno napravljene šablone (golden paths), što im dramatično smanjuje pritisak (kognitivno opterećenje) i omogućava fokus na poslovnu stranu kodiranja.
Da li se velika preduzeća zaista vraćaju na monolitnu arhitekturu?
Da, sve češće se viđaju primeri iz globalne industrije gde velike kompanije napuštaju komplikovane i izrazito skupe mikroservisne arhitekture u specifičnim delovima sistema (poput Amazon Prime Video analitike). One pronalaze meru prelaskom na strukturisane, tzv. modularne monolite, koji drastično smanjuju troškove hostinga i vraćaju lakoću testiranja celokupnog softvera.
