Od monolita preko Self-contained sistema do mikroservisa

Share

Monoliths

Image001

Većina projekata počinje kao monolit. Ovako je bilo i u mom slučaju dok sam radio na aplikaciji za krajnjeg korisnika ispunjavajući zahteve velikog telekomunikacionog provajdera iz Holandije. Ideja je bila da imamo odvojenu aplikaciju gde ćemo pružiti pristup REST API servisima za klijentsku stranu napravljenu u Angular 1 framework-u. Ova aplikacija koju smo nazvali consumer-services je služila kao most između CRM-a i SOAP web servisa i klijentske aplikacije. Bez poznavanja jasnih granica našeg domena i opsega do koga će rasti počeli smo sa razvojem REST servisa koristeći ovaj pristup. Stvari su izgledale obećavajuće.

Onda, šta je to monolit?

Monolit sadrži veći broj stvari unutar jednog sistema. Razni domeni i korisnički interfejsi, poslovna logika, sloj za čuvanje podataka. I dodato na to mnogo modula, komponenti i biblioteka.

Prednosti monolita su:

  • Jednostavan za razvijanje
  • Jednostavan za testiranje
  • Jednostavan za deploy-ment
  • Jednostavan za skaliranje
  • Jednostavan za nadgledanje

Sve ove prednosti su prisutne u startu projekta ali kao što znamo monoliti imaju tendenciju da rastu, kako sama aplikacija tako i tim koji je razvija. Kako je vreme odmicalo i u našem slučaju počeli su da se ispoljavaju dobro poznati problem ovog arhitekturalnog pristupa:

  • Skaliranje – problem nastaje jer se ne može skalirati sa povećanjem u obimu podataka. Svaka kopija aplikacije će pristupati svim podacima.
  • Kontinuriani deployment – da bismo dodali novu komponentu cela aplikacija mora biti ponovo deploy-ovana
  • U slučaju rasta tima – ova arhitektura sprečava timove da rade nazavisno
  • Dugoročna vezanost za određeni set tehnologija
  • Preopterećena aplikacija za razvoj softvera – IDE
  • Preopterećen web kontejner
  • Veliki broj linija koda – predstavlja problem za nove članove tima

Šta raditi sada?

Odgovor:

Self-Contained sistemi

Image001

Počeli smo sa monolitom, aplikacija se pokazala kao veoma uspešnom i korisna za svakodnevne operacije servis centra, prodaje i kranjih korisnika. Ali sa rastom aplikacije i svega što prati životni ciklus gore pomenuti problemi počinju da isplivavaju. Stiglo je vreme za rastavljanje. Čak iako je vaš dugoročni cilj mikroservis arhitektura – a mi smo imali indikacije da bi nam taj pristup odgovoarao, možete razmotriti da počnete sa self-contained sistemima (SCS). To je ono što smo mi uradili.

Onda, šta je to SCS?

  • Autonomna web aplikacija(uključuje UI, lokigu i podatke)
  • Daje prednost integraciji na nivou UI umesto na nivou API-ja
  • Preferira se asihrona integracija
  • Svaki SCS se može samostalno deploy-ovati
  • Vlasništvo nad jednim SCS-om ima jedan tim

Po SCS arhitekturi postojeći monolit bi trebalo rastaviti na vertikale. To znači da SCS sadrži front-end(može biti GUI i/ili API), backend i sloj za perzistovanje podataka. Kod između SCS-a se ne deli (osim na nivou biblioteka) i svaki SCS ima svoju bazu podataka. Ako vam trebaju podaci iz druge vertikale postoje dve opcije, možete replicirati podatke u svoju bazu podataka ili možete zvati API koji pripada tom SCS-u. Tim može posedovati jedan ili više SCS-ova, ali više timova ne može deliti jednu vertikalu. Ovo timu daje mnogo autonomije zato što je jedini način da drugi timovi imaju interakciju sa vašim sistemom je kroz dobro definisan API ili isto tako dobro definisan način replikacije.

Čak i self-contained sistemi mogu postati preveliki i habasti vremenom. Neke vertikale će postajati sve kompleksnije i nove će se uvoditi. U našem slučaju javila se potreba za obezbeđivanjem visoko performantnog API-a za preprodavače telekom usluga. Ovo može biti znak kada se te vertikale koje predstavljaju uska grla mogu refaktorisati, ovoga puta u mikroservise.

Mikroservisi

Photo 3

Mikroservisi – ili mikroservis arhitektura – je arhitekturalni stil koji struktuira aplikaciju kao kolekciju slabo povezanih servisa, koji implementiraju poslovnu logiku i zahteve. Ova arhitektura omogućava kontinuiranu isporuku i deployment velikih, kompleksnih aplikacija. Takođe daje mogućnost organizaciji da unapredi tehnologije koje koristi.

Postoje mnogi razlozi zašto timovi mogu da se okrenu ka mikroservisima kao izabranoj arhitekturi. Na primer, manji timovi mogu koristiti mikroservise zato što je kontinuriana isporuka mnogo lakša kada se radi sa manjim jedinicama za deployment. Takođe mogu biti skalirani individualno umesto skaliranja velike monolitne aplikacije. Veći projekti mogu koristiti ovaj pristup da skaliraju agilne procese. Svaki tim može samostalno razvijati i deploy-ovati svoje mikroservise bez mnogo koordinacije sa drugim timovima. Mogu dostaviti nove funkcionalnosti u produkciju nezavisno. Takođe, skoro sve tehničke odluke mogu da se donose u okviru jednog tima. Jako malo koordinacije je potrebno – kako za tehnologiju tako i za nove funkcionalnosti. Na ovaj način mnogo veći sistemi mogu biti razvijeni zato sto je komunikacija često ograničavajući factor.

Kao što možemo primetiti mikroservisi rešavaju neke od isti problema koje SCS pristup rešava ali ključne razlike su:

  • Mikroservisi su manje jedinice od SCS-a
  • Najčešće ima manje SCS-a nego mikroservisa
  • U idealnom slučaju SCS-i neće komunicirati između sebe dok je to validan pristup u mikroservisima
  • SCS ima UI
  • SCS bi trebalo da daje prednost integraciji na nivou UI-a dok mikroservisi najčešće rešavaju integraciju na logičkom nivou

Zaključak

Ni jedan od pristupa/arhitektura nije srebrni metak ili univerzalno rešenje i sva tri imaju svoje mesto u različitim projektima i njihovim ciklusima. U slučaju da iz bilo kojih razloga hoćete da razvijete svoju aplikaciju iz monolita u mikroservise trebalo bi da razmotrite SCS kao među korak koji će vas odvesti do cilja ili se pokazati kao zadovoljavajuće rešenje. U slučaju o kome pišem se pokazalo kao mnogo lakše razbiti monolit u SCS prvo pa onda razviti one vertikale za koje se pokazala potreba (fleksibilnije skaliranje, kontinuirana isporuka manjih celina…) nego odmah skočiti na prebacivanje čitavog sistema u mikroservise. Mikroservisi su svestraniji dok SCS rešava problem specifično za arhitekturu i organizaciju velikih projekata. Morate shvatiti šta odgovara vašim specifičnim potrebama. U našem slučaju kranje stanje je kombinacija između SCS-a i mikroservisa i to se pokazalo kao odgovarajuće. SCS je ostao na onim vertikalama gde smo imali UI a razvili smo u mikroservise one vertikale koje su postale prevelike i koje su bile potrebne za naš REST API tako da smo mogli da iskoristimo prednosti kao što su manje jedinice za deploy-ment, visoka raspoloživost i granulirano skaliranje.

Share

Prijavi se da prvi dobijaš nove blogove i vesti.

Оставите одговор

Jovan Vulin

Java Developer @ NTT Data
mm

Jovan je senior software developer sa 6+ godina iskustva. Radio je sa velikim brojem tehnologija kako na backend tako i na klijentskoj strani, i u timovima različitih velicina na pozcijama developer-a i team lead-a. Sertifikovani je scrum master i imao je priliku da komplementarno development-u obavlja i tu rolu. Uglavnom radio po agilnim metodologijama. Dobar timski igrač, full stack developer-om, a Java mu je language of choice.

Prijavi se da prvi dobijaš nove blogove i vesti.

Категорије