A Beginner's Guide to a Microservices Architecture

Learn the Microservices overall Architecture, Building Blocks, Key Advantages, Challenges and
Industry Case Studies

Created by Idan Gabrieli

udemy.com
Complex Release Cycles
Bilo koja aplikacija je dobra dok se nešto ne promeni. Dolaze novi zahtevi, nove forme sa zahtevima od strane korisnika,
nove tehnologije. Svi znamo da sve softverske aplikacije je potrebno da budu ažurirane na jedan ili drugi način. Glavno
pitanje ili glavni problem je vezan za vremenski interval između ovih verzija (ažurianja).
Možete zamisliti da kod koncept deljenog koda (shared code) i deljenih podataka (shared data) koji se koristi u monolitnoj
aplikaciji kreira čvrstu povezanost (tightly coupled) između modula, tako da nadolazeće softverske verzije će biti za celu
aplikaciju. Ok, svi moduli su zajedno jedan blok, kao jedan monolit.
Ukoliko iskoristimo naš sistem za prodaju karata za letove kao primer, zamislimo da se zahteva nova karakteristika (feature)
u specifičnom modulu i razvojni tim koji je brzo kreirao pomenutu karakteristiku, za par dana, ali ovaj modul je mođusobno
povezan sa drugim modulima, npr. sve komponente koriste istu bazu podataka i ukoliko izmenimo strukturu baze podataka
ili metapodatke, to može da utiče na veći broj komponenti. U tom scenariju aplikacija treba da bude testirana sa kraja na
kraj (end-to-end testing), da bi se videlo da li sve radi i funkcioniše kako se očekuje, čak iako je u pitanju veoma mala
karakteristika (feature). Takođe potrebno je da ponovno deploy-ujemo (redeploy) celu aplikaciju u produkciono okruženje
što znači da će biti više vremena kada sisitem ne radi (dowtime), veći broj nadogradnji (upgrade) i veći broj pritužbi
(complaints) od krajnjih korisnika kada sistem nije dostupan i više rizika da se nešto razvali tokom sisitemske nadogradnje.
Ukoliko pitate bilo kojeg sistema administratora, to je velika glavobolja da se ažurira veliki složen softver. To je razlog zašto
buduća verzija softvera za takav nivo aplikacije koji odgovara preduzeću (enterprise) će biti jednom u dužem vremenskom
periodu ili možda dva puta godišnje, jer su godišnji ciklusi u verziji softvera povezani zajedno jer ima smisla da se pakuju
male promene, u mnogo karakteristika, u većem broju modula zajedno i da se sačeka sledeči veliki softverski ciklus za
ažuriranje (release cycle).
Ključni nedostatak jeste da će velika monolitna aplikacija biti prepreka čestim deployment-ima. Svaki sledeći deployment
će biti kompleksan da se zakaže (schedule), složen za izvođenje i sa većim rizikom na uticanje na taj sisitem, koji će na
kraju obeshrabriti ljude da rade česta ažuriranja, au softverskom biznisu česta ažuriranja (update-ovi) su moranje, jer se
stvari menjaju veoma brzo. Kompanije bi htele da korist koncept neprekidne isporuke (continuous delivery) softverskih
ažuriranja. Takav pristup u kome se sprovode ciklusi od jednogodišnjeg ciklusa isporuke softvera su manje efektivni za
mnoge kompanije i organizacije koje bi htele da imaju više softverskih alata i ako je neka važna karakteristika potrebna
sada zašto čekati jednu godinu radi te karakteristike.
Kompanije bi želele da koriste koncept kontinualne isporuke (continous delivery) softverskih ažurianja i monolitne aplikacije
nisu dizajnirane da mogu da podnesu takva česta ažuriranja.

Scaling the Team

Pričajmo sada o drugom scenariju. Pretpostavimo da se novi developer pridružio firmi i želi da doda novu karakteristiku
(feature). To neće biti jednostavno. Developer treba da potroši mnogo vremena da bi shvatio šta se dešava. On mora da
potroši mnogo vremena da bi shvatio nepoznate međuzavisnosti između modula, pre nego što krene u kodiranje, jer u
suprotnom on će nešto pokvariti.
Situacija je još komplikovanija kada imamo veći broj developer-a koji idu po istoj aplikaciji. Svaki developer dodaje jedno
parče koda i kod postaje sve veći i veći. Zato što ne postoje jasne i specifične granice između modula, možda će se
sistemska modularnost slomiti vremenom. Vratimo se u naš primer i želimo da dodamo RatingCapability da bi omogućili
kupcima povratnu informaciju o procesu kupovine karata i o usluzi tokom leta, sugestije od samih kupaca i td. Videli smo
da je naša aplikacija podeljena u module, kao osnovne gradivne blokove, jedan modul će biti korisnički interfejs, sledeći
modul će biti proces bukiranja letova, proces plaćanja, a naredni modul će se baviti rejtingom i feedback-om od krajnjih
korisnika. Tim za razvoj će kreirati Java kod i razviti potrebne karakteristike (features), možda kao novi modul. Ipak da bi
bili u mogućnosti da razviju karakteristike (features) tokom vremena, procenili smo drugi tim za razvoj koji će biti priključen
projektu, pretpostavimo da i taj tim ima oko 10 ljudi. Sada imamo 20 ljudi koji radi na toj aplikaciji. Ukoliko premotamo na
nekoliko godina u budućnost ove aplikacije, što više karakteristika (features) bude dodavano u aplikaciju, više će ljudi biti
uključeno u taj projekat, veći broj developer-a, veći broj product manager-a, veći broj QA Engineer-a, veći broj Operation
Engineer-a, DevOps Engineer-a i td. Dakle, kako se kompleksnost aplikacije povećava, sve veći broj ljudi se pridružujei
koordinacija postaje mnogo složenija između njih. Problem sa monolitnom (monolithic) aplikacijom jeste da sprečava timove
za razvoj da rade nezavisno. Timovi moraju pažljivo da koordiniraju svoje razvojne napore.
Zamislite aplikaciju koja je krenula sa 10 developer-a, a koja je sada došla na 100 developer-a. To je kompletno drugačija
priča. Ovo je drugi važan nedostatak monolitnih aplikacija. U nekom trenutku će postati izazov da tim skalira, a da pri tome
bude i dalje efektivan.
2
Scaling the System
Treći glavni problem kod monolitnih aplikacije je vezan za skalabilnost ili bolje rečeno je ograničena skalabilnost.
Skalabilnost je sposobnost da se uvećaju ili smanje dostupni IT resursi, da bi se bolje prilagodilo traženom opterećenju. U
slučaju da postoji usko grlo u monolitnoj aplikaciji, rešenje može biti podeljeno na 2 glavne opcije: prvo se zove vertikalno
skaliranje (scale up) – što znači dodavanje više resursa na postojećem čvoru, zamislite Web server koji je pokrenut na
specifičnoj virtuelnoj mašini, mi možemo uvećati resurse virtuene mašine kao što je dodavanje više memorije, CPU snage,
kapaciteta storage-a, brzine mreže i td. To se zove ili scale up ili scale down. I dalje u nekom trenutku vremena mi
dostignemo neki limit, kao što je maksimalna količina memorije ili maksimalna količina opsega mreže. Dakle, ene može da
skalira zauvek.
Mi imamo drugu opciju za skaliranje, koja se naziva horizontalno skaliranje ili scale in ili scale out. U tom slučaju ćemo rešiti
usko grlo, kreiranjem druge paralelne instance istog čvora, npr. ukoliko imamo 1 Web server, sada imamo 2 Web server-a
i balansiramo saobraćaj između njih upotrebom komponente kao što je load balancer. Ne podržavaju sve komponente
ovakve skalirajuće opcije, ali postaje veoma popularna i korisna opcija kada govorimo o automatskom i dinamičkom
skaliranju u Cloud okruženju. Sve je savršeno sa ove 2 opcije za skaliranje ? Ne zapravo sa stanovišta monolitnih aplikacija,
jer je kod njih skaliranje granularnosti (scaling granularity) ograničeno. Zamislimo da imamo 5 modula kao deo neke
aplikacije, koje su pokrenute na istom aplikacionom serveru. Recimo da jedan modul, kao što je modul B, kreira veoma
veliki load na serveru koji utiče na sve module koji su pokrenuti na tom serveru. Iako je problem povezan samo sa jednim
specifičnim modulom, potrebno je da skaliramo sve module na aplikacionom serveru kao jedan entitet. U situaciji da želimo
da koristimo horizontalno skaliranje, tada još jedna full-replica aplikacionog servera će biti kreirana. To je rešenje, ali ne i
optimalno rešenje. Ovaj tip skalabilnosti je trošenje računarskih resursa u svetu elastičnog Cloud computing-a. Ukoliko
možemo da podelimo sistem u male komponente, skaliranje na različitim It resursima će biti mnogo više fokusirano na
specifične lokalna uska grla. Ukoliko možemo da pokrenemo samo modul B, kao odvojen IT resurs, tada imamo opciju da
skaliramo samo taj resurs. Takođe cloud-nativne aplikacije, bi trebalo da budu pokrenute unutar kontejnera, a ne virtuelnih
mašina. Ponovo, monolitne aplikacije nisu dobri kandidati da koriste takav tip virtualizacione tehnologije, kao što su
kontejneri.

Summary
Kao brzo ponavljanje želim da zapamtite da monolitne arhitekture su i dalje veoma korisne metode razvoja softvera za
small-medium size software project. I mnogi projekti će koristiti ovaj razvojni stil u budućnosti na mnogim use-case-ovima.
Kako god, postoje glavni nedostavi ovakvog pristupa, kada pričamo o velikim i kompleksnim aplikacijama koje bi trebalo da
se menjaju češće i da su sposobne da efektivno koriste cloud okruženje.