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

Digitalni mediji

Disney+ je konačno dostupan i kod nas, ali evo šta korisnici u Srbiji ne dobijaju

Od ovog meseca, korisnici iz Srbije i regiona konačno imaju priliku da se pretplate na Disney+ striming platformu, ali uz određena ograničenja.

Startapi i poslovanje

Domaći OTA Sync podigao €250.000 – prva investicija Telekomovog VC fonda

Domaći startap OTA Sync podigao je investiciju u vrednosti od skoro 250.000 evra od strane zajedničkih investitora TS Ventures Fonda, DSI grupe poslovnih anđela i Startup Wise Guys fonda iz Estonije.

Karijere

Bojana Tomić-Brkušanin novi je ‘Chief of Staff’ u web3 kompaniji Polygon

Nakon skoro dve godine provedene u Inicijativi Digitalna Srbija, Bojana Tomić-Brkušanin svoju karijeru nastaviće u oblasti web3 industrije i to na novoj poziciji u kompaniji Polygon čiji je suosnivač Mihailo Bjelić.

Propustili ste

Najava

Solana x Jump Hacker House konferencija o web3 tehnologiji dolazi u Beograd početkom jula

'Solana x Jump Hacker House Beograd', konferencija za softverske inženjere i tehnološke biznise zainteresovane za blockchain i web3 tehnologije biće održana u Beogradu od 02. do 06. jula.

Gaming

Highwater nova je igra srpskog Demagog studija koja ove godine dolazi na konzole i PC

Nakon uspeha video igre 'Golf Club: Wasteland' i najave igre 'The Cub', srpski game dev studio Demagog najavio je svoj novi naslov 'Highwater' koji bi uskoro trebalo da bude dostupan za gejmere širom sveta.

Karijere

Kako započeti karijeru u web3 – saveti programera

Web3 je najbrže rastući ekosistem u Srbiji. Zanimalo nas je kako izgleda karijerni put u ovoj industriji, a to smo otkrili kroz razgovor sa dvojicom web3 programera.

Startapi i poslovanje

Domaći OTA Sync podigao €250.000 – prva investicija Telekomovog VC fonda

Domaći startap OTA Sync podigao je investiciju u vrednosti od skoro 250.000 evra od strane zajedničkih investitora TS Ventures Fonda, DSI grupe poslovnih anđela i Startup Wise Guys fonda iz Estonije.

Tehnologija

Nadomak Barselone zavirili smo u 3 nova električna modela brenda Cupra kojeg vole i auto i tech entuzijasti

U auto industriji Španija nije izgradila ime kakvo je realno mogla da ima. Međutim, nova era traži nove heroje, a ova zemlja na Pirinejima ima važnog igrača koji bi mogao da promeni percepciju države u specifičnom automobilskom svetu.

Analiza

Više od $135 miliona investicija za srpske startape u 2021. godini

Prema godišnjem izveštaju Startup Genome, prošla godina bila je najuspešnija ikada za domaći startap ekosistem, a procentualno gledano u njega je uloženo čak 600% više investicija u odnosu na 2020.