Razvoj mikroservisa
Arhitektura mikroservisa – osnovne usluge
Mikroservis je arhitekturni pristup razvoju softvera gde se aplikacije sastoje od manjih, slabo povezanih i nezavisno primenljivih servisa koji komuniciraju korišćenjem standardnih protokola (npr. HTTP) i funkcionišu kao jedan sistem. Obično se svaki od mikroservisa fokusira na jednu funkciju i koristi minimalnu količinu informacija za komunikaciju sa drugim servisima.
Ovakva organizacija softvera organizacijama omogućava da brže implementiraju nove funkcionalnosti i prilagode se zahtevima tržišta, daleko efikasnije nego u slučaju monolitne arhitekture, u kojoj je čitava aplikacija izgrađena kao jedna celina. Osnovne karakteristike mikroservisa obuhvataju
Autonomnost
Svaka komponenta servisa u arhitekturi mikroservisa može se razvijati, primeniti, upravljati i skalirati bez uticaja na funkcionisanje drugih usluga i mogu se ažurirati bez uticaja na ostatak aplikacije. Usluge ne moraju da dele kôd ili implementaciju sa drugim uslugama.
Specijalizacija
Svaka usluga se fokusira se na rešavanje određenog problema. Ako developeri dodaju više koda u uslugu tokom vremena i ona zato postane složena, može se podeliti na komponente manje složenosti.
Agilnost
Mikrousluge neguju organizaciju malih, nezavisnih timova koji preuzimaju vlasništvo nad svojim servisima. Timovi deluju u malom i dobro razumljivom kontekstu, i mogu da rade nezavisnije i brže. Ovo skraćuje vreme razvojnog ciklusa.
Fleksibilno skaliranje
Mikroservisi omogućavaju da svaka usluga bude nezavisno skalirana kako bi se zadovoljila potražnja za aplikacijskom funkcijom koju podržava.
Jednostavnu integraciju
Mikroservisi omogućavaju kontinuiranu integraciju i kontinuiranu isporuku, što olakšava isprobavanje novih ideja, olakšava ažuriranje koda i ubrzava vreme do puštanja novih funkcija na tržište.
Slobodu izbora tehnološkog pristupa
Arhitekture mikroservisa ne prate pristup „jedna veličina za sve“. Timovi imaju slobodu da izaberu najbolji alat (različite programske jezike) za rešavanje svojih specifičnih problema.
Višekratnu upotreba koda
Usluga napisana za određenu funkciju može se koristiti kao gradivni blok za drugu funkciju. Razvojni timovi mogu da kreiraju nove mogućnosti bez pisanja koda od nule.
Elastičnost
Nezavisnost usluge povećava otpornost aplikacije na neuspeh. U monolitnoj arhitekturi, ako jedna komponenta otkaže, to može prouzrokovati neuspeh cele aplikacije. Sa mikrouslugama, aplikacije se nose sa potpunim neuspehom usluge tako što degradiraju funkcionalnost i ne ruše celu aplikaciju.
Poslovne i organizacione prednosti mikrousluga:
(1) Kôd se može lakše ažurirati – nove funkcije ili funkcionalnost se mogu dodati bez dodirivanja cele aplikacije.
(2) Timovi mogu da koriste različite tehnološke stekove i različite programske jezike za različite komponente.
(3) Komponente se mogu skalirati nezavisno jedna od druge, smanjujući tako troškove povezane sa skaliranjem čitavih aplikacija.
Sve u svemu, mikroservisna arhitektura tako čini aplikacije lakšim i bržim za razvoj, olakšavajući inoviranje i ubrzavajući vreme do aktivacije novih funkcija. Među prvima koji su usvojili ovu arhitekturu našli su se giganti poput Amazona, Ubera i Netflixa, kao i kompanije sa velikom bazom korisnika kao što su SoundCloud, Twitter i PayPal.
Mikroservisi vs SOA
razlike servisno-orijentisane u odnosu na arhitekturu mikroservisa; naglasiti prednosti korišćenja arhitekture mikroservisa
Svakome ko radi u IT ili u oblasti računarstva u oblaku poznata je debata o prednostima mikroservisa i agilnih aplikacija u odnosu na arhitekturu orijentisanu na usluge (Service-oriented Architecture, SOA). SOA obuhvata tradicionalnu strukturu za izgradnju aplikacija prema monolitnoj arhitekturi: ona razlaže komponente na manje delove/usluge, a zatim te usluge međusobno komuniciraju kako bi ispunile poslovne ciljeve. Svaki modul u SOA-i manji je od monolitne strukture i može da se koristi za druge svrhe, ali zbog manje fleksibilnosti implementacija nije jednostavna. S druge strane, mikroservisi predstavljaju naprednu verzija SOA, gde su usluge međusobno nezavisne i detaljno razrađene. Ako bilo koja aplikacija ili funkcija u mikroservisu zakaže, ostale aplikacije i sistem u celini će neometano nastaviti da funkcioniše.
Komunikacija
U arhitekturi mikroservisa, svaka usluga se razvija nezavisno, sa sopstvenim komunikacionim protokolom, dok SOA podrazumeva da svaka usluga mora da deli zajednički komunikacioni mehanizam (uslužna magistrala preduzeća, ESB); istovremeno, mikroservisi koriste jednostavnije protokole za razmenu poruka kao što su HTTP/REST i JMS
Brzina
Koristeći prednosti deljenja zajedničke arhitekture, SOA pojednostavljuju razvoj i rešavanje problema. Međutim, ovo takođe dovodi do toga da SOA rade sporije od arhitekture mikroservisa, koje minimizuju deljenje u korist ponavljanja.
Upravljanje
Priroda SOA-e, koja uključuje zajedničke resurse, omogućava primenu zajedničkih standarda upravljanja podacima u svim uslugama. Nezavisnost mikroservisa obezbeđuje veću fleksibilnost za svaku uslugu, što može da podstakne bolju saradnju u celoj organizaciji.
Skladištenje
SOA i mikroservisi se takođe razlikuju u pogledu načina na koji se resursi za skladištenje dodeljuju. SOA arhitektura obično uključuje jedan sloj skladištenja podataka koji dele sve usluge u okviru date aplikacije, dok će mikroservis posedovati server ili bazu za skladištenje podataka za bilo koju uslugu kojoj je to potrebno.
Migracija tradicionalnih aplikacija na arhitekturu mikroservisa – izazovi i neophodna ekspertiza
Pored rastuće kompleksnosti u svim domenima IT infrastrukture, najveći izazov s kojim se IT stručnjaci suočavaju prilikom migracije sa tradicionalnih aplikacija na strukturu mikroservisa odnose se, u najvećoj meri, na nasleđena, projektantski prevaziđena rešenja koja podrazumevaju monolitnu strukturu glomaznih, hardverski zahtevnih aplikacija sa nepotpunom razvojnom dokumentacijom. Pravac kojim se ovi problemi rešavaju podrazumevaju transformaciju tradicionalno koncipiranih aplikacija, njihovo pakovanje u virtuelna mašine, a zatim i u kontejnere, da bi se na kraju struktuirale u mrežu povezanih mikroservisa.
Međutim, dok su prednosti koje pruža arhitektura mikroservisa, kao što su agilnost, skalabilnost i dostupnost, još uvek nepobitne, postoji veliki broj različitih neoptimalnih implementacija mikroservisnih arhitektura. Brojne zamke i izazovi na tom putu dovode do suboptimalnih primena ove arhitekture, što može dovesti do toga da timovi počnu da misle kako su mikroservisi još jedan prolazni hir.
Veliki broj timova koji razvijaju sisteme zasnovane na arhitekturi mikroservisa imaju manje ili više iskustva u SOA-i. I dok SOA iskustvo pomaže u razvoju uslužno orijentisanog pristupa, ono može imati i negativan uticaj i uvesti u zamke kao što su suboptimalna granularnost usluge, prekomerno komuniciranje (tzv. chatty aplikacije koje se u radu oslanjaju na veliki broj servisa) i konstrukcije baze podataka deljenih resursa (npr. ako je više mikroservisa vezano za iste tabele u bazu podataka, čime će svaka promena u šemi rezultirati kaskadnim promenana u drugim mikroservisima, što je u suprotnosti sa osnovnom svrhom mikroservisa). Dalje, stalna tehnološka poboljšanja dovela su do toga da neki timovi upadnu u zamku striktno tehnološkog razmišljanja, koja dovodi do dodatnog usložnjavanja i pada performansi mikroservisa.
Zbog toga preporučujemo da vodite računa o ovim potencijalnim problemima i da se proaktivno bavite izazovima kako bi se sve prednosti mikrousluga mogle efikasno iskoristiti, odnosno da za ove potrebe angažujete saradnike čija potvrđena ekspertiza pruža garanciju za ispravnu implementaciju mikroservisne arhitekture.