Iako je razvoj softvera vrlo propulzivna industrija u kojoj ne nedostaje inovacija, svako toliko se poklope naizgled nepovezani faktori i stvore uvjeti za “savršenu oluju”: radikalnu promjenu u načinu dizajniranja i izgradnje IT sustava. Jednoj takvoj oluji smo svjedoci zadnjih 5-6 godina, a radi se o mikroservisnoj arhitekturi IT sustava.
Mikroservisna arhitektura podrazumijeva građenje složenih IT sustava međusobnim povezivanjem manjih komponenti koje još nazivamo i mikroservisima.
Mikroservisi su dakle male, atomarne jedinice poslovne logike koje se neovisno izvršavaju, a surađujući zajedno pružaju punu funkcionalnost sustava.
Kako je do ove savršene oluje uopće došlo?
De-facto standardna monolitna arhitektura ima svojih nedostataka koji postaju posebno izraženi nakon što aplikacija preraste neke svoje predviđene gabarite. Rastom aplikacije raste i količina koda. Sve manje ljudi poznaje cijelu aplikaciju i javlja se zadrška prema implementaciji novih funkcionalnosti kako se ne bi uvele regresijske greške. Rastom aplikacije raste i broj timova. To povlači dodatne koordinacijske i komunikacijske napore pa potrebno uvesti i dodatnu razinu managementa. Sve to utječe na rast kompleksnosti sustava te u konačnosti na pad kvalitete i brzine isporuke. Velike monolitne aplikacije su u konačnici vrlo nezgrapne za upravljanje i skaliranje u slučaju opterećenja.
Brojne organizacije se mogu poistovjetiti s tehničkim i organizacijskim izazovima koje donosi monolitna arhitektura. Mikroservisna arhitektura adresira upravo te izazove uvođenjem veće modularnosti i fleksibilnosti među komponentama sustava.
Dekomponiranje velike aplikacije na više manjih, neovisnih, labavo povezanih servisa omogućuje svakom timu da radi na svom vlastitom servisu, odnosno na svom programskom kodu, bez straha od gaženja drugim timovima po prstima. To dodatno omogućuje svakom timu da se fokusira na manji komad programskog koda, a ne nužno na cijelu aplikaciju. Manje servise je lakše razviti, lakše ih je testirati, a ako su dobro osmišljeni mogu se i ponovno iskoristiti. Manjim servisima je lakše upravljati i mogu se elegantno skalirati slučaju opterećenja. Čini se da je sve na strani mikroservisne arhitekture!
No kao što to obično biva, skloni smo gledati samo pozitivne stvari, a postoji i čitav niz izazova i dodatne kompleksnosti koju mikroservisna arhitektura donosi u nekim drugim područjima.
Prvenstveno tu mislimo na sposobnost sagledavanja što se točno u sustavu događa te na nadziranje sustava. I dok je detektiranje i dijagnosticiranje grešaka u monolitnoj aplikaciji bilo poprilično jednostavno i svodilo se na nadzor aplikacije i analiziranje aplikativnog loga, u mikroservisnoj arhitekturi se zbog povećanog broja neovisnih komponenti ta aktivnost bitno komplicira. Sada više nije dovoljno gledati samo jedan aplikativni log već je potrebno gledati aplikativne logove svih neovisnih servisa.
Dodatno, potrebno je te logove korelirati i razumjeti kako je izvršavanje korisničkog zahtjeva teklo kronološki kroz svaki pojedini servis. Ne pomaže ni činjenica da odjednom mreža igra veliku ulogu jer mikroservisi međusobno komuniciraju upravo preko mreže, za razliku od monolita unutar kojeg je sva komunikacija tekla međuprocesnim mehanizmima. Mreža je sama po sebi vrlo volatilna i nepredvidiva, posebice u cloudu, pa je zbog toga potrebno primijeniti posebne defanzivne mehanizme dizajniranja sustava.
Navedeni izazovi razumijevanja ponašanja mikroservisnog sustava popularno se nazivaju “observability“.
Kad pričamo o observabilityju obično mislimo na monitoring, tj. nadziranje metrika koje sustav šalje kako bi provjerili njegovo opće zdravstveno stanje. No monitoring je rijetko dovoljan da bi riješili misterij. Treba nam bolja vidljivost kroz mehanizme logginga i tracinga.
Pod loggingom podrazumijevamo kreiranje zapisa o diskretnim događajima koji su se tijekom vremena dogodili u sustavu. Tracing je s druge strane bilježenje svih događaja koji su se dogodili u sustavu kao posljedica obrade jednog korisničkog zahtjeva.
Drugim riječima, monitoring otkriva zdravstveno stanje sustava, logging bilježi događaje iz perspektive jednog mikroservisa, a tracing bilježi događaje iz perspektive jednog korisničkog zahtjeva. Iako se informacije koje navedene tehnike bilježe mogu doimati sličnima, ipak postoji suptilna razlika i potrebne su nam sve tri perspektive kako bi rekonstruirali potpunu sliku funkcioniranja sustava, posebice u slučaju greške.
O navedenim tehnikama nadziranja distribuiranih sustava na .debugu će pričati Denis Jajčević, softverski arhitekt u CROZ-u. Denis se u CROZ-u dugo bavi dizajniranjem distribuiranih sustava i njihovim izvršavanjem na kontejnerskoj platformi Red Hat OpenShift, a kroz svoje predavanje će ispričati vlastito iskustvo u primjeni dostupnih alata za što bolje razumijevanje ponašanja distribuiranih sustava.
Ako ste pročitali članak do kraja – čestitamo, stvarno vas zanima ova tematika! Pretplatite se na CROZ-ov 0800-DEVOPS newsletter, svaki broj donosi intervjue s poznatim facama i zanimljive teme iz svijeta DevOpsa.
I naravno, ne propustite Denisovo predavanje na .debugu!
Više o svemu saznajte na .debug konferenciji 12. i 13. prosinca 2019.
