Odgovori na vaša pitanja o mikroservisima – šta treba znati pre upuštanja u ovu avanturu?

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.

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.

The post Odgovori na vaša pitanja o mikroservisima – šta treba znati pre upuštanja u ovu avanturu? appeared first on Netokracija.rs.