Najveću opasnost za organizacije ne predstavlja samo postojanje tehničkog duga, već njegovo neplaćanje i gomilanje.

Od čega zavisi uspeh implementacije novih tehnologija i IT projekata? Iz strogo tehničkog ugla posmatrano, uspeh bismo mogli oceniti na osnovu realizacije tehničkih karakteristika koje tehnologije implementirane projektom donose, npr. određeni mrežni protok, vreme oporavka od katastrofe, količina i performanse storidž prostora ili broj korisnika koje aplikacija može da opslužuje istovremeno. Međutim, na sličan način kao što organizacije ne žive i ne prosperiraju direktno od svojih biznis modela, već od njihove efektivnosti i efikasnosti, tako se i IT tehnologije i projekti njihove implementacije mogu posmatrati i procenjivati kroz svoj uticaj na tehnički dug.

Termin tehnički dug (eng. technical debt) prvi je upotrebio programer Vard Kaningam 1992. u izveštaju za jednu konferenciju, kao objašnjenje budućeg troška za organizaciju koji je izazvan u sadašnjosti, publikovanjem neoptimalnog programskog koda. Kaningam je u svom izveštaju posebno istakao da najveću opasnost ne predstavlja samo postojanje duga, već njegovo neplaćanje i gomilanje, koje ga pretvara od malog do potencijalno kolosalnog problema za organizaciju.

U svetlu današnjeg razvoja IT tehnologija i rasprostranjenosti njihove primene, postavlja se pitanje da li se tehnički dug odnosi samo na kod aplikacija? Zapravo, tehničkim dugom možemo obuhvatiti čitav IT, tj. platformu, aplikacije, administraciju i procese. Svaka neoptimalnost u njima dovodi do tehničkog duga, malog kada se pojavi, a velikog kada se ne popravlja dovoljno uspešno, već nastavlja da raste i gomila se.

Termin tehnički dug prvi je upotrebio programer Vard Kaningam 1992. kako bi objasnio budući trošak koji je izazvan u sadašnjosti, publikovanjem neoptimalnog programskog koda

Uticaj DevOps tehnologija na tehnički dug

Pre nego što konceptom tehničkog duga obuhvatimo DevOps tehnologije, ukratko ćemo ih pojasniti. Pod DevOps tehnologijama podrazumevamo mikroservisne aplikacije i servise koje one koriste (npr. Single Sign On, API management, Message broker), platformu za izvršavanje kontejnerizovanih mikroservisnih aplikacija (najčešće Kubernetes) i rešenja za postizanje CI/CD, tj. kontinualnu integraciju (CI) i kontinualno publikovanje (CD). Nesuđen – i za uspeh implementacije obavezan – saputnik tih tehnologija je visok stepen automatizacije njihove administracije i procesa. Neophodna je i bliska saradnja programera (Dev) i sistem administratora i inženjera (Ops). Dev i Ops saradnja može se ostvariti pomoću dedikovanih DevOps inženjera kao mostova, ali to nije nužno – važno je da Dev i Ops između sebe mogu da komuniciraju efektivno i efikasno, odnosno da nijedan tim nema osećaj da ovaj drugi sa njim komunicira na nekom nepoznatom jeziku ili da drugi tim nema razumevanja za njihove zahteve i probleme koji su njihov izvor.

Raspon efekata implementacije DevOps tehnologija na tehnički dug kreće se od pozitivnog, smanjujućeg, do negativnog, tj. uvećavajućeg. Naše iskustvo sa izvedenim projektima sugeriše da je efekat uvek bio pozitivan. Uticaj na tehnički dug platforme bio je uvek izrazito pozitivan jer je korišćenjem etabliranih Kubernetes platformi renomiranih vendora, kakav je Red Hat, obezbeđena infrastruktura koju odlikuje stabilnost u funkcionisanju i nadograđivanju, vertikalna i horizontalna proširivost resursa (u odgovarajućim okolnostima sa mogućom automatizacijom operacija proširivanja) i deklarativno upravljanje putem definisanja konfiguracije kodom.

Mikroservisne aplikacije sastoje se iz mnoštva servisno razdvojenih komponenata (kontejnera), kojima se, zahvaljujući platformi kao što je Kubernetes, može obezbediti visoka dostupnost kroz više replika i imutabilnost, tj. nepromenjivost u toku života. Jedan od najbitnijih efekata na tehnički dug ima mogućnost izmene koda pojedinačnih servisa i njegovo brzo republikovanje u vidu novih kontejnera, bez remećenja funkcionalnosti ostalih servisa aplikacije. Možemo reći da mikroservisne aplikacije prihvataju neminovnost postojanja tehničkog duga, ali su zahvaljujući svoj arhitekturi predisponirane za lak rad na njegovom otklanjanju, mnogo lakše i bezbolnije nego tradicionalne monolitne aplikacije.

Za starije monolitne aplikacije, u odgovarajućim uslovima, postojii mogućnost njihove refaktorizacije u kontejnerizovanu ili mikroservisnu. U više projekata koje je COMING realizovao ovo se odrazilo pozitivno na stabilnost, dostupnost i brzinu publikovanja izmena koda, a samim tim i na tehnički dug.

Zahvaljujući svojoj arhitekturi, mikroservisne aplikacije su predisponirane za lako otklanjanje tehničkog duga, mnogo lakše i bezbolnije nego tradicionalne monolitne aplikacije

Značaj kvalitetne saradnje

Administracija mikroservisnih i kontejnerizovanih aplikacija i platforme na kojoj se one izvršavaju zahteva od administratora i inženjera sticanje novih znanja i ovladavanje njihovom primenom. Međutim, kada se jednom ovlada znanjem, princip primene je isti. Ovde je od ključnog značaja podrška korisniku, najčešće kroz prilagođene obuke i asistenciju prilikom administrativnih operacija. To je nešto na šta COMING obraća posebnu pažnju i što se pokazalo kao značajno za umanjenje tehničkog duga koji je posledica neoptimalne administracije.

Najbitniji proces koji DevOps tehnologije donose je CI/CD, uprošćeno rečeno automatizovano građenje aplikacije ili mikroservisa iz izvornog koda i njihovo testiranje i publikovanje u odgovarajućoj sredini, npr. test ili produkcionoj. CI/CD implementiramo u vidu pajplajnova. Oni su neophodni za lak rad programera na razvijanju i poboljšanju mikroservisnih aplikacija. Za njihovo kreiranje neophodno je poznavanje tehnologije koja se koristi za CI/CD i arhitekture aplikacije i sredine na kojima se publikuje. Optimalno kreirani CI/CD pajplajnovi se, jednom kada se naprave, izuzetno retko menjaju. I ovde se pokazalo da podrška korisnicima prilikom implementacije povećava pozitivan efekat CI/CD procesa.

Za kraj, ponovo skrećemo pažnju na neophodnost uspostavljanja procesa kvalitetne komunikacije između Dev i Ops timova. Poželjno je da u implementaciju od samog početka budu uključena oba tima ili barem njihovi predstavnici, bez obzira na to da li se radi npr. o aplikativnom (Dev) ili sistemskom (Ops) delu projekta. Takođe, važno je i ohrabriti iznošenje potencijalnih nedoumica i pitanja koje neki od timova može da ima. Jedan od načina za inicijalizaciju dobre komunikacije može biti sastanak na početku implementacije na kome Dev tim predstavlja arhitekturu mikroservisne aplikacije i zahteve koje platforma mora da ispuni. Iako uspostavljanje ovog procesa na početku može ići malo teže, uz malo truda i razumevanja obe strane on se može pokazati izrazito pozitivnim za smanjenje tehničkog duga.

Miloš Vukmirović, COMING