Pucanje monolitnih aplikacija i potreba za mikroservisima

Mikroservisna arhitektura sve više dobija na popularnosti, sa sve više kompanija koje dele pozitivna iskustva u vezi sa njenom primenom. Među prvima koji su usvojili ovu arhitekturu našli su se giganti poput Amazona i Netflixa, kao i kompanije sa ogromnom bazom korisnika kao što je SoundCloud.

Na osnovu profila ovih kompanija i pretpostavke da postoji više kompleksnosti u održavanju i razvoju više stvari nego jedne aplikacije, mnogi smatraju mikroservisnu arhitekturu zanimljivom idejom koja se ipak ne odnosi na njih. Ona je nešto čemu će obični smrtnici dorasti tek u dalekoj budućnosti, a možda ni tada.

Ipak, čekanje pravog trenutka retko se ispostavi kao dobra strategija u životu. Korisnije je naučiti kako da prepoznate trenutak u kojem postaje jasno da suprotni pristup (monolitna aplikacija) više nije optimalan.

Kod preraslih monolita javljaju se dve vrste problema: opadanje performansi i stabilnosti sistema i spori razvojni ciklusi. Ono što radimo dolazi iz želje da izbegnemo ove probleme.

Tačka pucanja

Tipični monolitni sistemi nastali su kao web aplikacije napisane u nekom MVC frameworku, kao što je Ruby on Rails. Ove sisteme karakteriše jedna tačka pucanja, ili zabrinjavajuća uska grla koja nastaju pod opterećenjem.

Naravno, potencijalna uska grla, ili celi sistemi koji su single point of failure nisu nužno problem. Kada ste u trećem mesecu pravljenja vašeg MVP-a, ovo je prihvatljivo. Kada ste u timu od nekoliko developera koji za klijenta rade na projektu koji opslužuje 100 korisnika, ovo je prihvatljivo. Kada veći deo funkcionalnosti vaše aplikacije čine dobro dizajnirane CRUD operacije bazirane na ljudskom inputu koji se linearno uvećava, sve će biti u redu još dugo vremena.

Takođe, ne postoji ništa samo po sebi loše u vezi sa velikim aplikacijama. Ako radite na jednoj takvoj aplikaciji i nikada se niste susreli ni sa jednim od navedenih problema, nema razloga da menjate svoj pristup. Ne treba da koristite mikroservise samo da biste učinili aplikaciju manjom, jer nema smisla popravljati ono što već dobro radi.

Problemi nastaju kada vaš single point of failure počne da puca pod opterećenjem.

U tom trenutku, spoljno opterećenje počeće da drži vaš tim u konstantnom stanju uzbune. Na primer:

• Preopterećenje u obradi sporednih podataka obara ceo vaš sajt. Sa Semaphore-om, imali smo situacije gde je monolith obrađivao callbackove od više CI servera, i kada bi taj deo sistema pao, sa sobom je vukao ostatak aplikacije.

• Premestili ste sve vremenski zahtevne taskove u jednu veliku grupu pozadinskih procesa i potreban je ceo jedan tim developera kako bi ih održao stabilnim.

• Promene na jednom delu sistema neočekivano utiču na neki drugi deo sistema iako oni nisu logički povezani, što dovodi do nekih neprijatnih iznenađenja.

Kao posledica ovoga, vaš tim troši više vremena na rešavanje tehničkih problema nego na pravljanje kul stvari za vaše korisnike.

Spori razvojni ciklusi

Drugi veliki problem nastaje kada uvođenje bilo kakve promene u aplikaciju počne da oduzima previše vremena.

Dobro pitanje koje bi trebalo da postavite jeste koliko vašem timu treba vremena da isporuči hotfix u produkciju. Vaši korisnici će lako osetiti odsustvo brzog pajplajna u slučaju neke nezgode.

Ono što je manje očigledno jeste kako spori razvojni ciklusi utiču na vašu kompaniju tokom dužeg vremenskog perioda. Koliko je vremena potrebno vašem timu da stigne od ideje do nečega što korisnik može da koristi? Ukoliko je odgovor u nedeljama ili mesecima, konkurenti bi lako mogli da vas prešišaju.

Niko to ne želi, ali upravo tome vodi konstantno povećavanje složenosti u monolitne aplikacije.

Spori CI bildovi: sve duže od par minuta vodi ka neproduktivno iskorišćenom vremenu i nepotrebnom multitaskingu. Kao standard za web aplikacije preporučujemo postavljanje ograničenja na 10 minuta i zapravo vam prikazujemo tu liniju. Spori CI bildovi jedan su od prvih simptoma preraslog monolita, ali srećom postoje CI alati koji vam mogu pomoći u ispravljanju ovoga.

Spora isporuka: ovo je tipičan problem monolitnih aplikacija koje su vremenom nakupile mnogo aseta i zavisnosti. Često postoji više instanci aplikacije, a na nama je da zamenimo svaku bez downtime-a. Prelazak na razvoj u kontejnerima može dodatno zakomplikovati stvari, dodajući vreme potrebno za bildovanje i kopiranje kontejner image-a.

Visok bas faktor za starije članove tima i dug onboarding za novajlije: nekome ko je nov u timu potrebno je nekoliko meseci da bi se osećao slobodnim da napravi netrivijalni doprinos velikoj bazi koda. Opet, sav novi kod je samo kap u moru onog već postojećeg, a preterana osetljivost starog koda ograničava novi kod koji se na njega nadograđuje. Ovo samo dodatno povećava odgovornost starijih developera koji su tu još od nastanka aplikacije. Simptom ovoga je, na primer,  situacija u kojoj pet developera čeka jednu osobu da im pregleda pull requestove.

Menjanje konteksta izazvano hitnim situacijama: počeli ste rad na novom delu aplikacije, ali iznenadnim prekidom rada aplikacije isplivala je greška u vašem sistemu. Tako proces krpljenja nedostatka postaje vaš prioritet, a tim mora da preusmeri fokus na ovaj problem. Dok se vrate na ono što su inicijalno počeli da rade, unutrašnji ili spoljni faktori učinili su taj deo projekta zastarelim ili umanjili njegovu vrednost.

Promena tehnologije je preteška: može se ispostaviti da framework i alati koje trenutno koristite nisu idealan izbor za izazove sa kojima se suočavate. Za monolite nije neuobičajeno ni da zavise od zastarelog softvera. GitHub je prešao na Rails 3 tek četiri godine nakon što je objavljen. Spora reaktivnost ograničava naše izbore alata i stvara dodatne obaveze oko održavanja. Kada biblioteka koju koristite prestane da bude ažurirana od strane njenog kreatora sami morate da nađete način da je krpite.

Dekompozicija za korist i zabavu

Iako uspeh proizvoda može da da vetar u leđa timu, susretanje sa navedenim problema može značajno da umanji moral ekipe.

Sve ovo se dešava nezavisno od kvaliteta koda, a praktikovanje razvoja podstaknutog ponašanjem korisnika nije rešenje za probleme sa skaliranjem.

Suština problema je jednostavna. Unutar monolitne aplikacije raste još nekoliko podaplikacija koje se onda susretnu sa mnogo saobraćaja i velikim obimom podataka.

Najbolji pristup velikim problemima jeste da ih razbijemo na manje probleme koji su lakše rešivi. Osnovna inženjerska ideja ovde je da podelimo monolitne aplikacije u manje servise, a kasnije i u mikroservise.

Konačni cilj je vratiti se kreativnom radu i ostvarivanju uspeha, omogućavajući timu da razvija korisne proizvode što je brže i lakše moguće.

Članak je prvobitno objavljen na Semaphore blogu i preveden i objavljen na Startitu uz dozvolu autora.