Iako govorimo o podeli posla, DevOps koncept zapravo povezuje razvoj i operacije u jedinstvenu celinu. Poenta nije u razdvajanju, već u sponi koja povezuje dva nekad suprotstavljena procesa.

U poslednjih nekoliko godina pojavio sa čitav niz novih (ili relativno novih, inoviranih) koncepata u vezi sa razvojem, isporukom i održavanjem softvera koji, uzeti zajedno, imaju potencijal da potpuno preobraze softversku scenu. Kako Pat Gelsinger, CEO kompanije VMware, s pravom ističe, ovo je vrlo poseban trenutak u razvoju IT-ja u celini: posle više od četrdesetak godina razvoja, kockice se polako slažu kao nikad pre. Pred nama se u jedinstvenu, integrisanu celinu slažu naoko potpuno disparatni koncepti.

Pogledajmo ih malo bliže: aplikacije rođene u oblaku (cloud-native), mikroservisi, agilne metode razvoja, neprekidna isporuka i integracija, kontejneri i kontejnerske platforme, virtuelizacija (svega: servera, sistema za skladištenje podataka, mreža, aplikacija, korisničkih radnih mesta), cloud (javni, hibridni, privatni, multi-cloud platforme)… i konačno: DevOps. Da se zaustavimo samo na onim konceptima/rešenjima koja najviše obećavaju i koja pomažu da se kockice konačno sklope.

Dev i Ops: podela odgovornosti

Šta omogućava sinergetično delovanje ovih koncepata? Osnovni cilj je koliko jednostavan, toliko, kako se kroz istoriju pokazalo, teško dostižan: brz, efikasan i ekonomičan razvoj, isporuka i održavanje aplikativnog softvera koji zadovoljava funkcionalne zahteve korisnika i koji je sposoban da promptno i pouzdano odgovori na promene koje zahteva poslovni model korisnika. Takođe, koji garantuje, kroz pouzdan i automatizovan postupak testiranja i isporuke, adekvatne performanse i visoku raspoloživost i sposobnost oporavka u slučaju otkazivanja (i katastrofa).

Zašto smo posebno, ali tek na kraju, naveli DevOps? I šta to uopšte predstavlja? Gelsingerovo slaganje kockica možemo pročitati na sledeći način: napokon imamo koncepte i alate koji nam omogućavaju da uspostavimo novu podelu rada u IT-ju, jasno razgraničenje između razvoja i operacija. Pri tome, iako govorimo o podeli posla, DevOps zapravo povezuje razvoj i operacije u jedinstvenu celinu. Priložena slika to vrlo jasno i nedvosmisleno prikazuje. Poenta nije u razdvajanju, već u sponi koja povezuje dva nekad suprotstavljena procesa.

Iz perspektive razvoja posmatrano, prvi put razvoj raspolaže alatima kojima može da proizvede artefakte i u njih upakuje svoja aplikativna rešenja, i pri tome bude siguran da će se u izvršenju ponašati istovetno kao u razvojnom i test okruženju – reč je o kontejnerima. Sadržaj kontejnera, tj. aplikacije potpuno su izolovane od spoljnog okruženja i neželjenih uticaja. Pri tome, kontejneri se jednostavno mogu isporučiti (Docker kaže: build-ship-run – izgradi, pošalji, pokreni) i integrisati u operativnu infrastrukturu.

Operacije (Ops), s druge strane, kontejnere tretiraju kao infrastrukturno agnostične, nepromenljive (immutable) i mobilne entitete, kojima se upravlja kao atomima nove IT infrastrukture. Za Ops gotovo idealna situacija: upravljanje infrastrukturom je potpuno nezavisno od aplikativnog domena i bilo kakvih internih zavisnosti među aplikativnim modulima.

Dev vidi kontejnere kao svoju infrastrukturu i nema više potrebe da se spušta na niže infrastrukturne slojeve da bi osigurao ispravan rad aplikacija. Ops nema potrebe da „ulazi“ u kontejnere i stara se o bibliotekama, programskim okvirima, upravljanjem verzijama aplikacija/platformama za razvoj, programskim jezicima, kompajlerima, aplikativnim greškama.

Dakle, nova podela posla počiva na gotovo perfektnoj izolaciji domena/aplikacija od infrastrukture. Stoga, mnogo je lakše podeliti odgovornost između Dev i Ops, izolovati i rešiti uočene probleme u radu aplikacija i omogućiti njihov rast u skladu sa potrebama poslovanja. Aplikacija „zapakovana“ u kontejner(e) je potpuno prenosiva i pogodna za izvršavanje u novom multi-cloud okruženju.

Virtuelizacija i kontejneri kao komplementarni procesi

Kontejneri se nisu pojavili niotkuda. Oni su infrastrukturni odgovor na pojavu koncepta mikroservisa, koji smatramo ključnim doprinosom i ogromnom šansom za uspostavljanje softverskog ekosistema koji pruža odgovore na rastuće zahteve modernog poslovanja. Reklo bi se, dugim putovanjem ka razvoju aplikacija „industrijskim“ putem, napravili smo pun krug i priznali da je razvoj softvera, pre svega, „manufaktura“: posao za agilne, male, fokusirane, ali s druge strane, dobro orkestrirane timove/projekte. Megaaplikacije monolitnog tipa, sa više miliona ili desetina miliona linija koda, pred našim očima se raspadaju na orkestrirane grupe nezavisnih i labavo povezanih mikroservisa. Pri tome mikroservisi svoje funkcije izlažu preko dobro definisanih API-ja, čime postaje potpuno irelevantna (za spoljnjeg korisnika, naravno) njihova unutrašnja struktura i tehnologija implementacije.

Mikroservisi upakovani u kontejnere jednostavno se „sele“ u operativnu infrastrukturu (multi-cloud), gde nalaze potrebne resurse za svoj pouzdan rad i rast.

Na neki način, istorija virtuelizacije se ponavlja u svetu kontejnera, pa sledeća analogija nije neumesna: virtuelna mašina potpuno apstrahuje hardversku infrastrukturu na kojoj radi (postaje nezavisna), dok kontejneri enkapsuliraju razvojno/radno okruženje aplikacija i čine ga nezavisnim od bilo kakve infrastrukture (virtuelnih mašina, na kojima kontejneri gotovo isključivo rade, ili samog hardvera). Važno je uočiti različitu granularnost: ako na jednom fizičkom hostu po pravilu radi desetak i više virtuelnih mašina, u svakoj VM radi desetak i više kontejnera. Pri tome su kontejneri nezavisni od VM isto kao što su VM nezavisne od hardverske platforme na kojoj rade; drugim rečima: mogu se lako kopirati/klonirati, premeštati, uništavati i dr.

S druge strane, virtuelizacija i kontejneri nisu suprotstavljeni, već komplementarni procesi. Problemima koje rešava virtuelizacija ne mora da se bavi kontejnerska infrastruktura. Ovim je stvorena mogućnost (koja se obilato koristi) da se ta dva infrastrukturna sloja nezavisno razvijaju/inoviraju. Primer: VMware vSphere platforma za virtuelizaciju, koja je istovremeno i platforma za Pivotal PKS (Kubernetes Services) – opet perfektna podela posla, slično kao kod pomenutih Dev i Ops.

Da ne ulazimo u sve detalje i sve slojeve moderne IT infrastrukture: jasno se uočava ključni koncept. Pretpostavljam da je Gelsinger mislio: infrastruktura se kristalizuje i preuzima gotovo sve funkcije koje se tiču upravljanja resursima, raspoloživošću, skalabilnošću, bezbednošću, korisnicima (njihovim identitetima i uređajima), ostavljajući aplikacijama (i onima koji se bave njihovim razvojem) da se pre svega koncentrišu na domensko znanje koje aplikacije treba da materijalizuju i njegovu evoluciju u budućim verzijama. Dev sada mirno može da se koncentriše na to kako da znanje iz korisničkog domena prevede u softverski/programski domen i da računa da će infrastruktura (Ops) automatski za njega obaviti sav ostali posao.

U tome je jedinstvenost ovog trenutka u razvoju IT-ja: danas je to po prvi put moguće!

Mogući pravci transformacije

Sve bi bilo prilično ružičasto da nije dve stvari: nasleđa i rastuće kompleksnosti (u svim domenima). Nasleđe, u vidu monolitnih, često i hardverski zavisnih aplikacija, sa nejasnom istorijom/razvojnom dokumentacijom je težak kamen oko vrata današnjeg IT-ja, ali ovaj tekst ne zagovara njegovo odbacivanje, već pre svega ukazuje na moguće i poželjne pravce transformacije i prelaska iz tekućeg, nimalo ružičastog stanja, u buduće, koje omogućava da se nađu odgovori na rastuće potrebe poslovanja u pogledu softverske podrške. „Stare“ aplikacije se mogu upakovati ne samo u virtuelne mašine, što je uglavnom već i urađeno, već i u kontejnere, što nas čeka uskoro, da bi na kraju bile dekomponovane u mrežu labavo povezanih mikroservisa, gde će napokon (?) naći svoju ultimativnu formu.

Rastuća kompleksnost (generalno) je problem druge vrste: ne može se poreći da „dodavanjem“ kontejnera, platformi za njihovu orkestraciju i drugih neophodnih komponenata koje se tiču mrežnog povezivanja, bezbednosti, dostupnosti i sl., sama IT infrastruktura postaje značajno kompleksnija nego što je bila. Slično tome, virtuelizacija, koja je omogućila „standardizaciju“ hardverske infrastrukture (dakle, pojednostavljenje), dodala je i dosta kompleksnosti postojećem IT stack-u.

Odgovor na dva napred navedena problema je gotovo nemoguće naći u izolaciji. Neophodna je integracija u globalni softverski ekosistem – multi-cloud ili, kako to IBM voli da kaže, API ekonomiju. API ekonomija je prilično jednostavna stvar: vrlo je verovatno da je funkcija koja vam je potrebna u razvoju vaše aplikacije već raspoloživa na internetu. Ako je izložena preko dobro definisanog API-ja i poseduje druge važne karakteristike, kao što je, na primer, bezbednost (u šta ovde nećemo detaljnije ulaziti), lako se može integrisati u mrežu mikroservisa koji čine predmetnu aplikaciju.

I tu dolazimo do novog koncepta sa brojnim implikacijama: aplikacija je mreža! Aplikacija (kao grupa kooperativnih mikroservisa) živi u internet ekosistemu i svaki pokušaj da je vratimo nazad u kutiju (data centar) biće osuđen na neuspeh. S druge strane, aplikacija izložena na internetu sa svojim sopstvenim API-jem je komercijalni entitet od interesa za spoljni svet: kupce, dobavljače, potrošače i samog isporučioca – sve češće viđamo kompanije koje su uspešno monetizovale svoje API-je i jedino preko njih komuniciraju sa okruženjem (zaboravite na EDI i slična „stara“ rešenja).

Naravno, API-ji nisu „spoljašnji“ koncept – mikroservisi, čak i okviru jedne aplikacije, morali bi da komuniciraju isključivo preko API-ja. Pored perfektne separacije domena i odgovornosti, API-ji stvaraju platformu za sveopštu automatizaciju. Automatizacija je jedan od temeljnih „kamičaka“ u velikoj slagalici koji nam omogućava održiv i ekonomičan razvoj novog softverskog ekosistema. Ona leži u osnovi svih modernih koncepata vezanih za infrastrukturu, kao što su: softverski definisan data centar, softverski definisane mreže, infrastruktura kao kod, orkestracija kontejnera (Kubernetes), alati za kontinualni razvoj i integraciju (CI/CD), uključujući i alate za automatsko testiranje softvera.

Na izloženi koncept Ops bi mogao da zavrti glavom: ko može da garantuje kvalitet i bezbednost tako isporučenih usluga (infrastrukture)? Ops, na sreću, ne mora sam da se bavi problemima koje „stvaraju“ nova rešenja. Može kao servise u multi-cloud-u iznajmiti aplikacije za upravljanje i nadzor koje „znaju“ da rade sa modernim distribuiranim multi-cloud aplikacijama i tako deo tereta i odgovornosti prenese na eksterne partnere.

To nas vodi ka još jednoj složenoj i neizbežnoj temi koja traži hitan odgovor: outsourcing-u IT usluga (bilo Dev, bilo Ops, bilo DevOps). Njom se i inače bavimo u svakom broju našeg časopisa, ali ćemo je ubuduće izlagati u skladu sa DevOps konceptom.

Miroslav Kržić