Monolitska/mikroservisna arhitektura u startupu?

Jedna od prvih stvari, zajedno s tehnologijama u kojima će se raditi implementacija, koju novopečeni tehnički voditelj startupa mora odlučiti jest početna arhitektura sustava. Više manje svaki tehnološki startup zasniva se na web-tehnologijama (u kojem slučaju govorimo o front end i back end komponentama) ili barem nudi neki set API-ja (sučelja kojim unosimo ili isporučujemo podatke iz naše aplikacije). Oboje povlači potrebu implementacije servisa koji se izvršavaju na nekim serverima i tako doprinose vašem proizvodu.

Spomenuti tehnički voditelj može skočiti na glavu i bez puno razmišljanja početi s implementacijom, ili može ući u duboke kalkulacije i promišljanja o idealnoj arhitekturi i svemu ostalome.
Poučen vlastitim iskustvom, zagovaram potonji pristup, ali uz šaku soli - aplikacija je softver, a softver se konstantno mijenja i evoluira. Stoga isplati se dobro razmisliti o tome koji problem i kako rješava vaša aplikacija, ali isto tako treba imati na umu da (pogotovo u startupu!) ćete ju u narednih nekoliko godina vjerojatno više puta refaktorirati ako ne i čitavu prepisati.

Vraćajući se na arhitekturu, vjerojatno ste više puta naišli na spomen monolitske i mikroservisne arhitekture kao dva oprečna pristupa izradi softvera (konkretno govoreći o serverskim aplikacijama). Ukratko ću opisati oba i dati svoje mišljenje kad koji ima smisla.

Monolitska arhitektura

U monolitskoj arhitekturi, ujedno i najstarijoj, čitava aplikacija je jedinstven komad koda. Neovisno o tome koliko ona zadataka obavlja ili koliko različitih stvari poslužuje.

Kad intuitivno zamislimo web poslužitelj, vjerojatno nam je u glavi jedno veliko računalo sa jednom pozamašnom aplikacijom koja se konstantno vrti na njemu i sluša te odgovara na zahtjeve klijenata sa svih strana svijeta. Ta aplikacija bila bi monolit, i ako nemamo neku specifičnu arhitekturu ili razvojni plan na umu, vjerojatno ćemo prirodno otići u smjeru pisanja monolitske aplikacije.

Velika prednost ovakve arhitekture jest jednostavnost. Lagano ju je postaviti i infrastrukturno je vrlo isplativa. Kao jedinstven kod, monolitska aplikacija je robusnija i lakše je održavati njene komponente u sličnom ili istom stanju razvoja. Standardizacija kroz kod je isto uvelike olakšana.

Nažalost, kako aplikacija raste i dolazi pod veća opterećenja, neki problemi dolaze do izražaja. Ako higijena koda nije na solidnoj razini, održivost postaje teška jer inženjer za svaku izmjenu mora kontrolirati puno spregnutih funkcionalnosti. Isti razlog otežava uvođenje novih inženjera na projekt. Također, veliku monolitsku aplikaciju je sporije i kompleksnije postaviti na server (deploy) jer svaki put se čitava mora testirati, prevesti, upakirati...

Bitno je spomenuti da je skalabilnost aplikacije relativno slaba u monolitskoj konfiguraciji. Uvijek je moguće upogoniti jači serverski stroj (okomito skaliranje), ali tu postoje granice. A vodoravno skaliranje postavljanjem aplikacije na više različitih servera otvara druge probleme isplativosti resursa i duljine trajanja ažuriranja, pokraj kompleksnijih zagonetki vezanih za pohranu podataka i pristupe istoj.

Mikroservisna arhitektura

S druge strane, u mikroservisnoj arhitekturi razlamamo našu aplikaciju na skupinu manjih modula koje nazivamo servisima. Recimo da naša aplikacija služi za pisanje blogova, a osim blogova raspolaže i korisnicima te njihovim komentarima. U mikroservisnoj arhitekturi možda bismo kao jedan servis imali funkcionalnost blogova a kao drugi servis funkcionalnost korisnika i komentara.

Mikroservisi su relativno nov pojam[1], ali jako su dobili na popularnosti u proteklih petnaestak godina. Kako su pojedine velike kompanije dosezale maksimume performansi konvencionalnih arhitektura (poglavito monolitske) zbog posjećenosti njihovih web-aplikacija, tako su više pojam mikroservisa stavljale u prvi plan implementirajući ih samostalno.

Dakle, mikroservisna arhitektura nam očito daje neke benefite naspram monolitske u vidu performansi. Po svojoj prirodi, aplikacije imaju neke dijelove koji su više opterećeni i neke koji su manje.
Ako aplikaciju izvedemo kao skup servisa, onda imamo mogućnost proizvoljno skalirati samo neke od njih. Također, možemo i dodatno optimizirati te servise za koje su nam performanse najbitnije, odabirom primjerenijeg programskog jezika ili pažljivom izvedbom nekog algoritma. Sve ovo bez utjecanja na ostatak naše aplikacije, bez obzira na njenu veličinu.

Mikroservisi nam olakšavaju suradnju među inženjerima odnosno timovima. Dok je za monolitsku aplikaciju realan krov 5-10 aktivnih inženjera u razvoju, mikroservisna arhitektura teoretski nema granicu.
Ako se aplikacija kvalitetno podijeli na servise i svaki od njih pripada jednom timu, produktivnost je višestruko bolja. Također, svaki servis ili skup servisa može imati svoj tempo razvoja, svoje najbolje prakse i pristup razvoju. Jedino oko čega se timovi moraju sporazumjeti jesu sučelja za komunikaciju među servisima.

Vidimo da su mikroservisi fleksibilniji, održiviji i u pravilu imaju bolje performanse (i puno viši krov performansi) od monolitske arhitekture. Ali imaju i neke bitne mane za spomenuti.

Prva i najbitnija je početna barijera. Za postaviti mikroservisnu okolinu i potrebnu infrastrukturu, definirati ugovore (za komunikaciju) među servisima i uopće osmisliti kako kvalitetno i smisleno podijeliti aplikaciju na mikroservise treba jako puno vremena. Također, zbog svoje prirode i realnosti cloud ponude danas, mikroservisi će u pravilu biti infrastrukturno skuplji od monolitske aplikacije za isti set funkcionalnosti.
Zadnje, mikroservisnu arhitekturu lako je odvesti u krajnost u kojoj svaka funkcionalnost opravdava vlastiti servis. Ovo brzo postaje teško pratljivo i teško održivo i mislim da je potrebno konstantno vagati kako najbolje ugraditi nove funkcionalnosti u sustav - često puta je bolje proširiti postojeći servis nego raditi novi.

Što ima više smisla za startup?

Već znate odgovor: "Ovisi."
Ali o čemu ovisi? Ovisi prije svega o prirodi vašeg projekta, odnosno funkcionalnosti koju vaša aplikacija implementira.

Ako sve što vam je potrebno za MVP (više o MVP-u pročitajte u mojoj ranijoj objavi) jest set endpointa koji čitaju i pišu jednostavne podatkovne strukture, i u dogledno vrijeme to će ostati tako, nema razloga da ne koristite monolitsku arhitekturu.
Početak će vam biti ekspresan i implementacija vrlo intuitivna i bezbolna. Ako vaša aplikacija nije sama sebi svrha i služi kao podrška glavnoj prodajnoj strategiji, vjerojatno nikad nećete ni imati potrebu raditi prijelaz na drugačije arhitekture jer će ova biti i više nego dovoljna na dugi rok.

Ima li situacija u kojima se isplati odmah koristiti mikroservisnu arhitekturu? Mislim da ima, i to su situacije u kojima ili imate resurse za to (novčane i ljudske) ili dobro znate da vam to treba.
Primjerice, razvijate platformu za chat, aplikaciju za menadžment resursima koju namjeravate prodavati kao uslugu, fintech aplikaciju... Poanta je da ste otpočetka svjesni da ako vaša aplikacija ne performira i ne skalira se brzo kad je to potrebno, imat ćete propali proizvod.

Imajući ovo na umu, osobno, ako nisam siguran hoće li mi trebati išta kompleksnije od monolita, jednostavno ću početi s monolitom i prilagoditi se kako bude potrebno.
Ključno je biti svjestan ovog odabira za vrijeme razvoja i u pravom trenutku odlučiti napraviti prijelaz na drugačiju, često mikroservisnu, arhitekturu.

Za kraj, spomenut ću još i jednu "hibridnu" situaciju u kojoj vam se čini da vam trebaju mikroservisi zato što jedna komponenta vaše aplikacije zahtijeva fleksibilnost i performanse. Primjerice, sadrži funkcionalnost obrade videa ili uživo procesuira priljev podataka sa neke platforme.
U ovom slučaju i dalje bih pristupio sa monolitom za sve osim te jedne funkcionalnosti, koju bih izdvojio u vlastiti servis, ako je potrebno i na odvojenim serverima.