Mainstream stručnjak odgovara na vaša pitanja o mikroservisima

Mainstream stručnjak odgovara na vaša pitanja o mikroservisima – šta treba znati pre upuštanja u ovu avanturu?

Postoji dosta pitanja koje treba da postavite sebi pre nego što uopšte i krenete u avanturu zvanu razvoj aplikacije bazirane na mikroservisnoj arhitekturi.

Pretpostavljam da znate šta je aplikacija bazirana na mikroservisnoj arhitekturi – to je aplikacija koja je pravljena kao skup labavo vezanih servisa koji implementiraju funkcionalnosti aplikacije, a sami su nezavisno razvijani i nezavisno implementirani, komuniciraju preko mreže dobro definisanim i standardizovanim protokolom (obično HTTP).

Mikroservisi obezbeđuju enkapsulaciju funkcionalnosti i podataka koju ostatak aplikacije vidi kao jedinstvenu celinu bez zalaženja u to kako je ta celina implementirana i kako radi.

Vodite računa da je ovaj tekst pisan iz ugla nekog ko se bavi DevOps-om i DevSecOps-om, a dolazi iz Ops dela. Detalji vezani za korišćenje najbolje biblioteke ili okruženja za razvoj mikroservisa nisu predmet ovog teksta.


Napomena: U tekstu se izrazi ‘mikroservis’ i ‘servis’ se upotrebljavaju kao sinonimi. Izraz ‘mikroservis’ je pomalo pogrešan naziv jer implicira da postoji ‘servis’ koji je značajno veći u obimu od ‘mikroservisa’. U stvarnosti, ne postoji tačka gde ‘servis’ prelazi u ‘mikroservis’ i obrnuto.


Kako znati da li je mikroservis najbolji način za izgradnju aplikacije?

Mikroservisi donose niz prednosti pri pravljenju aplikacije:

  • Složenu aplikaciju možete razbiti na manje delove i onda te delove nezavisno i paralelno razvijati kao samostalne aplikacije. Naravno, prethodno je u fazi projektovanja potrebno definisati način na koji će mikroservisi pričati međusobno, ali nakon toga sama implementacija jednog mikroservisa je stvar tima koji radi na njemu – oni određuju algoritme, strukture podataka, koju i kakvu bazu će koristiti, u kojem jeziku će implementirati dati mikroservis i sl.
  • Mikroservisi se mogu nezavisno implementirati i ažurirati, najčešće bez uticaja na ostatak aplikacije, uključujući i kontinuiran rad ostatka aplikacije dok se dati mikroservis ažurira.
  • Razvoj celokupne aplikacije je ubrzan, implementacija izmena i novih funkcionalnosti je olakšan, automatizacija kroz DevOps/DevSecOps tehnologije je u osnovi mikroservisa.

No, ništa nije za džabe, pa tako ni mikroservisi. Ovakva arhitektura donosi i neke dodatne komplikacije koji obično postanu izvor problema:

  • Osnovna ideja mikroservisa je da se razvijaju nezavisno jedni od drugih, najčešće paralelno, od strane malih timova programera. No, mali timovi programera puta broj mikroservisa čini da na aplikaciji baziranoj na mikroservisima ipak radi veliki broj ljudi.
  • Mikroservisi se nezavisno pokreću jedan od drugog, što zahteva komunikaciju preko mreže. Komunikacija preko mreže je značajno sporija u odnosu na komunikaciju elemenata aplikacije bazirane na monolitnoj arhitekturi tako da uneseno intrinsično kašnjenje u komunikaciji može da značajno unazadi vašu aplikaciju.
  • Mikroservisi u teoriji onogućavaju princip jedinstvene odgovornosti (Single Responsibility Principle) koji je jedan od esencijalnih elemenata SOLID arhitekture. No, usitnjavanje postojećih servisa ili uvođenje novog servisa koji bi jedinstveno bio odgovoran za datu funkcionalnost lako može dovesti do nagomilavanja servisa i stvaranja komplikovane veze među njima koje onda povećavaju kompleksnost celog sistema.
  • Svaki mikroservis zahteva da bude izolovan i odvojen od ostalih mikroservisa, što značajno komplikuje implementaciju celog sistema.

Dakle, kako znati da li je mikroservisna arhitektura pravo rešenje za vas? Ako je vaša aplikacija inicijalno vrlo kompleksna, sa gomilom različitih funkcionalnosti i, možda i najvažnije, za koju očekujete da će rasti kako u širinu (dodavanjem novih funkcionalnosti) tako i po broju korisnika, onda ima smisla razmišljati o upotrebi mikroservisa u dizajnu vaše nove aplikacije.

Razlika između monolitne arhitekture i mikroservisa. dev.to

No, ako vaša aplikacija nije toliko kompleksna, imate mali tim i relativno ograničena sredstva za početak možda je bolje krenuti od monolitne arhitekture jer smanjuje troškove angažovanja većeg broja programera i inicijalne troškove eksploatacije. Ukoliko aplikacija krene da raste, onda će se pojaviti potreba za refaktorisanjem postojeće monolitne aplikacije u mikroservisnu arhitekturu, što se u praksi pokazalo kao bolja i jeftinija varijanta nego da se odmah krene u razvoj mikroservisne arhitekture.

Treba li manje firme i startapi da koriste mikroservise?

Ovo pitanje je vezano za prethodno – da li uopšte kretati sa mikroservisnom arhitekturom. Kao što sam rekao, sve zavisi šta će biti sa vašom aplikacijom u budućnosti. Ako pretpostavljate da će aplikacija sigurno rasti u širinu, non-stop dobijati nove funkcionalnosti i prepravljati postojeće, kao i da će postajati kritična za ceo biznis (što implicira da dauntajm bude minimalan) onda ima smisla krenuti sa mikroservisima.

No kao što sam rekao, iako svi startapi žele da kreiraju svoje servise/aplikacije tako da opslužuju globalno tržište, to se neće desiti sa većinom i onda je, zbog nižeg inicijalnog ulaganja, bolje krenuti sa monolitnom aplikacijom koja je dobro dizajnirana i koja može prilično dobro da skalira nagore i napolje, nego odmah ići sa mikroservisima. Ako bude sreće, u nekom trenutku će ograničenja monolitne arhitekture doći do izražaja u kom slučaju će biti potrebno refaktorisati aplikaciju u mikroservisnu arhitekturu. Ali, u tom slučaju će mala firma i startap već porasti dovoljno da više nisu mala firma i startap pa će moći da sebi priušte posao oko refaktorizacije.

Šta određuje idealnu veličinu mikroservisa?

Logika nalaže da se aplikacija razbije na osnovne servise koji primenjuju SRP. Dakle, servis mora da ima samo jedan razlog za izmenu. Primer: servis koji pravi i štampa izveštaje može biti menjan zbog toga što se sadržaj izveštaja mora promeniti ili što se format izveštaja mora promeniti. Teorija zahteva da u tom slučaju ovaj servis treba biti razbijen na dva manja servisa, jedan koji kreira sadržaj izveštaja i drugi koji zadati sadržaj formatira u traženi oblik.

Mikroservisi moraju biti ‘pametni’ jer se za veze među mikroservisima koriste ‘glupe’ cevi. Što je više servisa to je i više veza između njih koje onda postaju usko grlo aplikacije. Iz tog razloga, odluka gde ‘preseći’ i reći: ‘dosta je usitnjavanja’ je iskreno, na plećima glavnog arhitekte sistema i njegovom iskustvu. Na žalost, ne postoji neka formula koja mu može pomoći da donese svoju odluku.

Koja je uloga kontejnera u mikroservisima?

Svaki mikroservis treba biti izolovan, sa svojim sistemom za čuvanje podataka, koji treba da imaju mogućnost skaliranja nezavisno od ostatka aplikacije. To znači da mikroservis zahteva svoje izolovano okruženje koje se postiže nekom vrstom virtualne mašine. No, pošto su servisi uglavnom mali po obimu, korišćenje prave virtuelne mašine bi bilo preterano, kako sa stanovišta resursa koji zahtevaju tako i sa stanovišta brzine startovanja nove instance servisa kada se za to ukaže potreba.

Iz tog razloga najoptimalnije rešenje za implementaciju mikroservisa su kontejneri. Kontejneri obezbeđuju optimalno korišćenje resursa i brzinu reakcije, a sistemi za upravljanje kontejnerima mogu da obezbede neke operativne funkcionalnosti koje su neophodne mikroservisinim arhitekturama kao što su otkrivanje servisa (service discovery) i API gejtveji.

Dodatno, kontejneri obezbeđuju automatizaciju testiranja i implementacije (deployment) koja je esencijalna za mikroservisnu arhitekturu.

Kako se postiže bezbednost mikroservisa?

Mikroservisi donose dodatne bezbednosne izazove u odnosu na monolitnu arhitekturu jer, u osnovi, povećavaju površinu napada (attack surface) koja se mora braniti. Razdvajanje aplikacije na manje, nezavisne delove koji komuniciraju preko mreže jedni sa drugima donosi osnovni problem da mikroservis mora da pouzdano potvrdi ko je sa druge strane komunikacionog kanala. U slučaju monolitnih aplikacija taj problem ne postoji jer je komunikacija između delova aplikacije kompletno interna.

Ključna stvar za projektovanje aplikacija baziranih na mikroservisnoj arhitekturi je da se o bezbednosti sistema mora voditi računa još u fazi projektovanja. Potrebno je implementirati komunikacione kanale koji obezbeđuju da se strane koje komuniciraju mogu autentifikovati i autorizovati, a da to ipak ne poveća kompleksnost samog komunikacionog protokola. Potrebno je primeniti princip ‘odbrane po dubini’ (defense in depth) gde postoje slojevi zaštite oko pojedinih mikroservisa. DevSecOps alate je potrebno uključiti u tok kontinualnog razvoja mikroservisa kako bi se pojedini bagovi otkrili na vreme.

Zaključak

Ovaj članak bi trebalo da vam pomogne da odredite da li je isplativo uči u avanturu zvanu mikroservisna arhitektura, kao i da izbegnete neke glavne probleme u vezi implementacije mikroservisa. Kao što ste možda primetili, mikroservisna arhitektura nije idealno rešenje za sve probleme, ali je, u pravim prilikama, dobro rešenje koje vam može doneti dosta benefita.

Odgovori

Tvoja e-mail adresa neće biti objavljena.

Popularno

Office Talks Podcast

Matorci vs. Milenijalci – problem generacijskog jaza

Glavna tema 44. epizode Office Talks podcasta bila je diskusija o problemu koji sve vidljiviji generacijski jaz nosi sa sobom. Može li se životno iskustvo naših roditelja primeniti u eri digitalizacije i pandemije?

Karijere

Jovan Jovanović otkriva šta čeka domaće IT-jevce koji žele posao u norveškoj tehnološkoj industriji

Jovan Jovanović, QA inženjer u kompaniji Tidal, u Oslu živi već tri godine i kao aktivan učesnik u tom sektoru veoma je dobro upoznao norvešku tehnološku industriju. O njoj razgovaramo u nastavku teksta.

Startapi i poslovanje

Novosadski Anari AI dobio investiciju od $2.000.000 za proizvodnju AI čipova u cloudu

Ova srpsko-američka kompanija je za dva meseca zatvorila investicionu 'seed' rundu vođenu od strane nemačkog fonda Earlybird VC, koji je po prvi put investirao u jedan srpski startap. U investiciji su učestvovali i fondovi Acequia Capital i Serbian Entrepreneurs kao i Erica Ries, osnivač Lean Startup-a.

Propustili ste

E-commerce

Pošta Srbije i eCommerce Asocijacija potpisale Memorandum o razumevanju

Saradnja sa Poštom Srbije u programskim sadržajima eCommerce Asocijacije ključna je za razvoj i unapređenje internet poslovanja u Srbiji - pre svega kroz razmenu iskustva radi edukacije mikro i malih preduzeća.

Kultura 2.0

Kako da ne budete Dositej Obradović u Employer Brandingu?

IT kompanije jesu u fokusu ovog članka, jer je interesovanje za ovu temu u toj industriji najveće. Ali često, Employer Branding jednostavno ne radi ono što bi zaista trebalo.

Office Talks Podcast

Kako prodati vaš proizvod? (gost Ilija Ćosić)

Tema 45. epizode Office Talks podcasta bila je prodaja putem digitalnih kanala tj. kako efikasno prodavati proizvode putem interneta. Naš gost bio je Ilija Ćosić, Head of Sales u startapu Skylead koji se bavi automatizacijom prodajnih procesa. 

Kultura 2.0

Takmičenje FIRST LEGO League dolazi u Srbiju – 23. maja u Prvoj kragujevačkoj gimnaziji

Takmičenje 'FIRST LEGO League' za decu i mlade ima za cilj da učesnicima obezbedi iskustvo u rešavanju stvarnih problema kroz vođeni globalni program robotike.

Karijere

Mihailo Ponjavić imenovan za direktora prodaje Euronews mreže u Srbiji

Nakon skoro tri godine u e-commerce sektoru, Mihailo Ponjavić vraća se u medijski biznis i staje na čelo prodajnog sektora televizijske mreže Euronews u Srbiji koja uskoro kreće sa radom.

E-commerce

Kako do Internet prodavnice za manje od 24 časa?

Vladan Dobrenov pokrenuo je Cartizz kao odgovor na komplikovan i dugotrajan proces izrade web prodavnice. U razgovoru za Netokraciju otkriva nam kako servis funkcioniše i kome je namenjen.