Većina kompanija ne želi da migrira legacy aplikacije u Oblak jer su mišljenja da neće imati nikakve značajne prednosti ako postojeći monolit samo prebace u Cloud (tzv. lift and shift taktika)… Tako onda čekaju da aplikacija “ode u penziju” prirodnim tokom od silnih godina korišćenja ili da se refaktoriše u potpunosti što se verovatno neće desiti nikad jer je isuviše komplikovano i skupo, i pitanje je da li to uopšte ima smisla. Istina je da su tzv. cloud-native aplikacije, odnosno aplikacije sa mikroservisnom arhitekturom najpodobnije za Oblak. Glavna prednost mikroservisa je njihova nezavisnost, i obično se oslanjaju na kontejnere za izvršavanje, čija je glavna karakteristika autonomnost. Mikroservisi upakovani u kontejnere u Oblaku dolaze do punog izražaja jer mogu da se oslone na enormne kapacitete, distribuiranost i agilnost platforme kakvu imaju hyper-scale provajderi kao što su Amazon, Google i dr.
Međutim, kod aplikacija, slično kao i kod živih organizama, još nešto osim DNK-a utiče na njihovu vitalnost i progres. To je, naravno, okruženje. Aplikacija koristi resurse iz okruženja i u skladu sa tim ima određeno ponašanje (performanse). Takođe, oslanja se na stalno postojanje resursa kako bi opstala (dostupnost). Tako da samim izmeštanjem aplikacija u (kvalitetno) Cloud okruženje dobijamo veće performanse i veću pouzdanost, jer je jako teško za potrebe tipične aplikacije postići u sopstvenoj režiji nivo infrastrukture jednog Google-a. U većini slučajeva dobijamo i veću bezbednost jer Cloud provajderi imaju mnogo više operativnog iskustva i kvalitetnijih kadrova, što im je omogućilo da kroz vreme “utegnu i zakrpe” sistem. Takođe, tokom izmeštanja možemo da svedemo potrebne resurse (CPU, RAM, …) na optimalnu meru i time smanjimo troškove.
Ali tu nije kraj. Iako ne menjamo arhitekturu i kod aplikacije, možemo da je evoluiramo tako što ćemo modernizovati njene delove. Čak i monolitne aplikacije su sastavljene od više komponenti — u najmanju ruku od tri tradicionalna sloja: web server, aplikativni server i baza podataka. Tokom samog procesa planiranja i testiranja migracije naučili smo prilično o načinu funkcionisanja Cloud platforme. To nam daje samopouzdanje da u kasnijim fazama, polako optimizujemo komponente sistema, za početak bez menjanja koda same aplikacije. Na primer možemo da umesto održavanja sopstvenog load-balancer-a, pređemo na korišćenje load-balancer-a kao usluge i time dobijemo kvalitetniji servis i pritom uštedimo sopstveno vreme i energiju. Kasnije, možemo da refaktorišemo periferne, “pozadinske” delove aplikacije koristeći moderniju platformu i Cloud alate, i postepeno preusmeravamo korisnički saobraćaj kako bismo se uverili da sve funkcioniše nesmetano.
Putovanje od hiljadu milja počinje prvim korakom.
Lao Ce, kineski filozof
Dugoročno gledano, Cloud provajderi postaju pravi rasadnici servisa — pogledajmo samo eksploziju AWS servisa kao verovatno najeklatantniji primer. Drugim rečima, Cloud okruženja postaju aplikativni i servisni ekosistemi, koje tako treba posmatrati i upotrebljavati. Aplikacije i njihove komponente se rađaju, komuniciraju, evoluiraju… i nije svejedno u kakvom su okruženju.
Napomena: Iskorišćena ideja za analogiju između biljnog i aplikativnog ekosistema od Stivena Orbana, Amazon AWS.
Ako želiš da budeš u toku sa mitovima, trendovima i novostima iz sveta računarstva u Oblaku, prijavi se na Bilten “Ko se boji Klauda još?”.