Key takeaways – šta je najbitnije u ovom tekstu:
-
Puko prebacivanje starih aplikacija na „oblak“ (lift-and-shift) nije cloud-native razvoj. Pravi pristup zahteva suštinsku promenu arhitekture, alata i načina razmišljanja celokupne IT organizacije.
-
Četiri glavna stuba ove arhitekture su mikroservisi, kontejneri, CI/CD procesi i DevOps kultura. Bez sinergije ova četiri elementa, agilnost ostaje samo prazna reč na papiru.
-
Cloud-native pristup direktno utiče na poslovne rezultate (time-to-market). Kompanije koje primenjuju ove principe isporučuju nove funkcionalnosti klijentima deset puta brže od konkurencije zaglavljene u tradicionalnim razvojnim ciklusima.
-
Budućnost donosi još veću apstrakciju infrastrukture. Kroz integraciju veštačke inteligencije u DevOps procese, serverless tehnologije i WebAssembly (Wasm), inženjeri će se konačno fokusirati isključivo na pisanje koda koji donosi poslovnu vrednost.
Da se ne lažemo, IT tržište nikada nije bilo surovije. Živimo u eri digitalnog darvinizma, gde ne preživljavaju ni najveći ni najbogatiji, već oni koji mogu najbrže da se prilagode. U takvom ekosistemu, reč „agilnost“ se toliko izlizala od svakodnevne upotrebe u korporativnim prezentacijama da je gotovo izgubila pravo značenje. Svi žele da budu brzi, svi žele da budu agilni, ali kada zagrebete ispod površine, vidite inženjerske timove koji se bore sa softverskim monolitima starim po deset godina, čija isporuka (deployment) u produkciju traje danima i zahteva nadljudske napore celog tima.
Ako vaša kompanija i dalje funkcioniše na ovaj način, imamo loše vesti: vi ne trčite trku, vi se davite. Rešenje za ovaj problem odavno nije u novim metodologijama vođenja projekata, već u dubokoj, strukturnoj tehnološkoj promeni. Ta promena se zove cloud-native razvoj.
U ovom tekstu ćemo bez ulepšavanja secirati šta cloud-native zaista znači, zašto polovična rešenja vode u propast i kako ova arhitektura suštinski predstavlja jedini pravi temelj za agilno IT poslovanje današnjice.
Velika iluzija: zašto „lift-and-shift“ vodi u propast
Jedna od najčešćih i najopasnijih zabluda u modernom IT-ju jeste ideja da ste „prešli na cloud“ samim tim što ste zakupili virtuelne mašine na AWS-u, Azure-u ili Google Cloud-u i na njih preselili svoj stari, glomazni kod. Ovaj pristup, u industriji poznat kao lift-and-shift (podigni i preseli), ekvivalentan je kupovini najsavremenijeg pametnog telefona da biste na njemu koristili samo aplikaciju za kalkulator.
Kada staru monolitnu aplikaciju prebacite na „oblak“ (cloud), vi ne dobijate cloud-native sistem. Dobijate isti onaj spori, krhki sistem koji je sada samo hostovan na nečijem tuđem računaru, uz veliku verovatnoću da će vas mesečni troškovi infrastrukture neprijatno iznenaditi.
Pravi cloud-native (razvoj izvorno prilagođen oblaku) nije pitanje gde se vaš softver izvršava, već kako je napravljen. Cloud-native aplikacije su od prvog dana dizajnirane tako da iskoriste sve prednosti distribuiranog računarstva. One su napravljene da budu elastične, otporne na greške, lako skalabilne i upravljive putem automatizovanih procesa. Prema definiciji koju daje uticajna CNCF – Cloud Native Computing Foundation, ovaj pristup omogućava organizacijama da grade i pokreću skalabilne aplikacije u modernim, dinamičnim okruženjima kao što su javni, privatni i hibridni oblaci.
Četiri stuba cloud-native arhitekture
Da bi se postigla stvarna agilnost, IT organizacija mora da usvoji i sinhronizuje četiri ključna tehnološka stuba. Ako jedan od ovih stubova nedostaje, vaša arhitektura će pre ili kasnije početi da puca po šavovima.
1. Mikroservisi: razbijanje iluzija i koda
Kao što smo detaljno obradili u članku na ITNetwork-u koji se bavi temom mikroservisa i agilnosti, mikroservisi (microservices) predstavljaju arhitektonski stil u kom se aplikacija gradi kao kolekcija malih, nezavisnih servisa. Svaki servis je zadužen za jednu konkretnu poslovnu funkciju i komunicira sa ostalima preko jasno definisanih API-ja (Application Programming Interface).
U monolitnom sistemu, sve je spakovano u jedan ogroman proces. Ako funkcija za naplatu (billing) padne zbog prevelikog broja zahteva, pada i cela aplikacija. Kod mikroservisa, funkcija za naplatu može da se skalira nezavisno, ili čak i ako padne, funkcija za pretragu proizvoda će nastaviti da radi neometano. Ovo direktno omogućava agilnim timovima da rade autonomno, izbegavajući situacije u kojima deset različitih programera pokušava da spoji svoj kod u isti repozitorijum, moleći se da ne izazovu konflikt.
2. Kontejneri i orkestracija: standardizacija haosa
Mikroservisi bi stvorili logistički pakao da ne postoje kontejneri (containers). Kontejnerizacija, čiji je najpoznatiji predstavnik Docker, omogućava inženjerima da spakuju kod, njegove zavisnosti (dependencies) i konfiguraciju u jedan standardizovan, prenosiv paket.
Rečenica koja je decenijama zadavala glavobolje operativnim timovima – „Na mojoj mašini to radi!“ – konačno odlazi u istoriju. Kontejner se izvršava identično na laptopu developera, u testnom okruženju i u produkciji.
Međutim, kada imate stotine ili hiljade kontejnera, ne možete njima upravljati ručno. Tu na scenu stupa Kubernetes, de fakto standard za orkestraciju kontejnera. Kubernetes automatizuje postavljanje (deployment), skaliranje i upravljanje kontejnerizovanim aplikacijama. On se brine da, ukoliko jedan kontejner padne, odmah bude zamenjen novim, čime se obezbeđuje visoka dostupnost (high availability) sistema bez ljudske intervencije.
3. CI/CD procesi: automatizuj ili zatvori firmu
Agilnost zahteva brzinu, a brzina zahteva automatizaciju. Continuous Integration i Continuous Deployment (kontinuirana integracija i isporuka) predstavljaju praksu u kojoj se promene u kodu automatski testiraju, integrišu i isporučuju u produkciju, ponekad i više puta dnevno.
U cloud-native svetu, manuelno testiranje i ručno kopiranje fajlova na server su apsolutno zabranjeni. Kvalitetan CI/CD pajplajn (pipeline) funkcioniše kao neumorna fabrička traka. Kada developer završi kucanje novog koda (commit), sistem ga automatski preuzima, pokreće stotine automatizovanih testova, proverava bezbednosne propuste i, ukoliko je sve zeleno, isporučuje novu verziju korisnicima bez ijedne sekunde prekida u radu (zero-downtime deployment).
4. DevOps kultura: rušenje zidova
Sve gore navedene tehnologije su potpuno beskorisne ukoliko zadržite tradicionalnu organizacionu strukturu. Dugo su razvojni timovi (Dev) pisali kod i prebacivali ga preko zida operativnim timovima (Ops) sa porukom „Ovo je sada vaš problem“.
DevOps nije samo titula inženjera; to je kulturološka transformacija koja briše granice između onih koji prave softver i onih koji ga održavaju. U cloud-native ekosistemu preovladava mentalitet: „You build it, you run it“ (Ti ga napraviš, ti ga i održavaš). Timovi su kros-funkcionalni i u potpunosti poseduju svoj proizvod, od prve linije koda do monitoringa u produkciji.
Biznis ugao: šta CEO zapravo dobija ovim?
IT arhitektura se ne menja zato što inženjeri žele da koriste nove i moderne alate, već zato što biznis to zahteva. Prelazak na cloud-native model zahteva značajna početna ulaganja u edukaciju, restrukturiranje i infrastrukturu, pa je sasvim legitimno postaviti pitanje: šta poslovanje ima od toga?
Odgovor je jednostavan: vreme izlaska na tržište (time-to-market).
Zamislimo lokalnu banku koja koristi nasleđeni (legacy) IT sistem. Konkurencija izbaci novu funkcionalnost za mobilno bankarstvo, recimo instant deljenje računa u restoranu. Agilnoj, cloud-native neo-banci će biti potrebne tri nedelje da dizajnira, testira i u bezbednim kontejnerima izbaci istu funkcionalnost. Našoj tradicionalnoj banci biće potrebno šest meseci, tri komiteta za odobravanje, zakazivanje vikenda u kom će ceo bankarski sistem biti nedostupan radi apdejta, i tim inženjera u predinfarktnom stanju. U današnjoj ekonomiji, tih šest meseci razlike znači trajni gubitak korisnika.
Osim brzine, tu je i FinOps aspekt (optimizacija finansija u cloudu). Cloud-native aplikacije, kroz auto-skaliranje, troše resurse isključivo onoliko koliko im je u tom trenutku potrebno. Tokom „Crnog petka“, web prodavnica će se automatski proširiti na hiljade kontejnera kako bi izdržala navalu kupaca. Već u subotu ujutru, sistem će se skupiti na minimum, drastično obarajući troškove računarstva. Kod tradicionalnih servera, vi taj kapacitet plaćate 365 dana u godini, bez obzira da li ga koristite.
Otpornost sistema (resilience): dizajniranje za neuspeh
Jedan od najintrigantnijih koncepata cloud-native razvoja jeste premisa da će se greške neminovno desiti. Hardver će crći, mreža će se prekinuti, baza podataka će usporiti. Tradicionalni IT je pokušavao da izgradi sisteme koji nikada ne padaju – što je nemoguća misija.
Cloud-native inženjering ne pokušava da spreči neuspeh, već pretpostavlja da će do njega doći i dizajnira sistem tako da se automatski oporavi. Ovaj princip se najbolje vidi u praksama poput inženjeringa haosa (Chaos Engineering), koji je popularizovao Netflix. Oni su kreirali softver zvani Chaos Monkey koji namerno gasi servere u njihovoj produkciji u sred bela dana. Cilj? Testiranje otpornosti sistema. Ako pad nekoliko kontejnera može da vam obori celu platformu, to znači da sistem nije dobro dizajniran. Ograničavanjem radijusa udara (blast radius) putem mikroservisa, greška u jednom modulu ostaje izolovana i ne utiče na celokupno korisničko iskustvo.
Bezbednost koja ne usporava razvoj: DevSecOps
Brzina koju donosi cloud-native može biti izuzetno opasna ako bezbednost ostane naknadna misao (afterthought). Ostaviti bezbednosne provere za sam kraj razvojnog ciklusa znači potpuno poništiti benefite agilnosti.
Zbog toga se danas sve više primenjuje DevSecOps pristup. Bezbednost (Security) se integriše direktno u CI/CD pajplajn – od prvog dana. To podrazumeva automatsko skeniranje Docker imidža u potrazi za ranjivostima pre nego što se oni uopšte postave na server, statičku i dinamičku analizu koda u realnom vremenu, kao i striktno upravljanje identitetima i pristupima (IAM) za svaki pojedinačni mikroservis. U cloud-native svetu, mreža unutar klastera se smatra kompromitovanom, te se primenjuje model nultog poverenja (Zero Trust architecture).
Pogled u budućnost: Serverless, WebAssembly i moć veštačke inteligencije
Cloud-native ekosistem je jedan od najdinamičnijih segmenata IT industrije. Ako posmatramo stručne podatke i pravce razvoja, jasno je da se klatno pomera ka još većoj apstrakciji infrastrukture.
Dok Kubernetes trenutno vlada tržištem, Serverless arhitektura preti da preuzme primat za određene tipove opterećenja. U serverless modelu, inženjeri više uopšte ne razmišljaju o kontejnerima ili serverima; oni pišu samo funkcije (poput AWS Lambda), a cloud provajder preuzima apsolutno sav posao oko skaliranja i alokacije resursa.
Tu je i WebAssembly (Wasm), tehnologija koja se polako probija iz web pretraživača u backend sisteme, obećavajući izvršavanje koda u skoro izolovanom okruženju, brže i sa manjim sigurnosnim rizicima od standardnih kontejnera.
Međutim, prava revolucija leži u integraciji veštačke inteligencije u razvojni proces. AI asistenti danas već uveliko generišu konfiguracione fajlove, pronalaze bagove u logovima mikroservisa i optimizuju potrošnju resursa unutar klastera. Da bi vaši inženjeri ostali relevantni i maksimalno iskoristili ove alate, neophodno je kontinuirano usavršavanje. Kroz platforme posvećene stručnoj IT edukaciji, kakva je Joombooz platforma, vaši timovi mogu naučiti kako da etički, bezbedno i efikasno primenjuju generativnu veštačku inteligenciju kako bi dramatično ubrzali dizajn i implementaciju cloud-native rešenja.
Da li je vaša kompanija zaista spremna za ovo? (Zaključak)
Cloud-native razvoj nije samo još jedan tehnološki trend (buzzword) kojim ćete ukrasiti stranicu kompanije na LinkedIn-u. To je fundament za izgradnju agilne organizacije koja može da se takmiči u 21. veku.
Međutim, tranzicija je brutalna. Zahteva odbacivanje alata koje ste koristili decenijama, promenu načina na koji vaši timovi komuniciraju, i suočavanje sa strmom krivom učenja (learning curve) koju donose Kubernetes i mikroservisi. Surova istina je da mnoge kompanije dožive neuspeh pri prvoj migraciji baš zato što softver menjaju, a kulturu ostavljaju istom.
Ne postoji prečica. Vaš biznis ne može biti agilan ako vam IT diktira tempo kornjače. Cloud-native arhitektura je platforma koja inženjerima vraća moć da brzo i sigurno isporučuju vrednost vašim klijentima. Jedino pitanje koje sebi kao IT lideru danas treba da postavite nije „da li ćemo preći na cloud-native“, već „koliko tržišnog udela ćemo izgubiti dok to ne uradimo?“
FAQ
Šta je tačno cloud-native razvoj? Cloud-native je pristup izgradnji i pokretanju aplikacija koji u potpunosti koristi prednosti modela računarstva u oblaku (cloud computing). Oslanja se na mikroservise, kontejnere, dinamičku orkestraciju i kontinuiranu isporuku (CI/CD) kako bi se postigla maksimalna agilnost i skalabilnost.
Koja je razlika između cloud-native i cloud-hosted (lift-and-shift) aplikacija? Cloud-hosted aplikacije su stari, monolitni sistemi koji su samo prekopirani sa lokalnih servera na cloud virtuelne mašine, bez menjanja arhitekture. Zadržavaju sve mane starog sistema. Cloud-native aplikacije su od samog početka dizajnirane iz manjih, nezavisnih modula koji optimalno koriste cloud resurse.
Zašto se mikroservisi uvek pominju uz cloud-native? Mikroservisi su arhitektonski stil koji deli kompleksnu aplikaciju na manje, nezavisne funkcije. Ovo je savršeno za cloud-native okruženje jer omogućava da se svaki servis skalira, popravlja i unapređuje nezavisno, čime se drastično ubrzava isporuka (time-to-market).
Šta je uloga Kubernetesa u celoj priči? Kada imate desetine ili stotine kontejnera u kojima se vrte vaši mikroservisi, potreban vam je softver koji će njima upravljati – pokretati ih, gasiti, skalirati u slučaju gužve i pratiti njihovo zdravlje. Kubernetes je upravo taj „dirigent“ (orkestrator) za kontejnere.
Da li cloud-native znači da naša bezbednost opada zbog brzine? Ne, ukoliko se primeni DevSecOps pristup. Bezbednost se integriše u sam proces razvoja kroz automatska skeniranja i validacije na svakom koraku CI/CD pajplajna. U cloud-native arhitekturi primenjuju se principi nultog poverenja (Zero Trust) koji znatno podižu nivo bezbednosti u odnosu na tradicionalne sisteme.
Koliko je teško preći na cloud-native arhitekturu? Tehnička implementacija je izazovna, ali je najveća prepreka kulturološka promena u kompaniji. Prelazak zahteva usvajanje DevOps kulture, velika ulaganja u obuku zaposlenih i reorganizaciju razvojnih i operativnih timova kako bi mogli samostalno da upravljaju celokupnim životnim ciklusom softvera.
