„Pakao“ kognitivnog tereta: Zašto je DevOps „slagao“ developere i zašto je Platform Engineering jedini spas

Sećate se, ne tako davno, postojala je jasna linija. Postojali su „Devs“ (programeri), kreativni genijalci u duksevima koji piju Red Bul i pišu kod. I postojali su „Ops“ (operacije), mrzovoljni „sistemdžije“ u zagušljivoj server sobi, čiji je posao bio da kažu „ne, ovo ne može na produkciju“. Između njih je stajao „Zid Konfuzije“ (Wall of Confusion).

A onda je stigao DevOps. Došao je kao spasilac. Filozofija, kultura, set alata. Obećanje je bilo magično: srušićemo zid! Saradnja! Automatizacija! CI/CD (Continuous Integration/Continuous Deployment)! Brže ćemo isporučivati softver, bićemo agilniji, srećniji.

Srpska IT scena, gladna rasta i vođena outsourcing „zlatnom groznicom“, oberučke je prihvatila ovo. Postalo je pitanje prestiža. „Mi nismo obična firma, mi smo DevOps firma.“

Godina je 2025. Vreme je za mamurluk.

Na portalu ITNetwork.rs, gde se tehnologija gleda pravo u oči, moramo biti surovo iskreni: DevOps, u načinu na koji ga je većina kompanija implementirala, nije uspeo.

Zid nije srušen. Samo je premešten. A cena tog premeštanja je plaćena najskupljom valutom: mentalnim zdravljem i produktivnošću samih programera.

Stvorili smo novu generaciju „glorifikovanih administratora tiketa“ i, što je još gore, opteretili smo svoje najvrednije inženjere poslom koji niti razumeju, niti žele da rade. Ovo nije tekst o tome da je DevOps kao filozofija mrtav. Ovo je oštra, i nadamo se, provokativna analiza zašto je njegova implementacija pošla po zlu i zašto se upravo sada, iz tog pepela, rađa novi, moćniji koncept koji konačno ispravlja grešku.

Dobrodošli u eru Platform Engineering-a (Platformskog Inženjeringa). Ovo je priča o tome kako smo prestali da teramo programere da budu „svaštare“ i konačno počeli da im gradimo „auto-put“.

Poglavlje 1: Anatomija „prevare“ – Kako je „Shift-Left“ uništio developera

Da bismo razumeli zašto nam treba Platform Engineering, moramo da seciramo „leš“ propale DevOps implementacije. Kako je san o saradnji postao noćna mora?

Problem leži u jednoj frazi koja je postala mantra: „Shift-Left“ (Prebaci ulevo).

• Ideja (na papiru): Hajde da probleme (bezbednost, testiranje, infrastrukturu) pomerimo ranije u proces razvoja, „ulevo“ na vremenskoj liniji. Neka programer misli o bezbednosti dok piše kod, a ne kada kod stigne na produkciju.
• Kako je prevedeno u praksi: „E, programeru, pošto smo sad ‘agilni’ i ‘DevOps’, evo ti. Ti si sad odgovoran i za Kubernetes, i za Terraform skripte, i za AWS bezbednosne polise, i za CI/CD YAML fajlove. Srećno.“

Desile su se dve katastrofe istovremeno.

Katastrofa #1: DevOps tim postaje „usko grlo“ (The Bottleneck) U mnogim firmama, „DevOps tim“ nije postao partner, već novi šalter. Postali su „grobari produktivnosti“.

• Realnost: Programer Pera u Beogradu završi svoj feature (novu funkcionalnost). Da bi to postavio na staging (testno) okruženje, on ne može sam. On mora da otvori tiket (ticket).
• Taj tiket ide DevOps timu, koji je zatrpan sa 100 drugih tiketa. Oni moraju ručno da mu „provizijoniraju“ bazu, otvore portove, podese pipeline…
• Rezultat: Pera čeka tri dana. Za to vreme, on je neproduktivan. Njegov kod „stari“. Menadžment je nervozan. „Agilnost“ je umrla u redu za tikete.

Katastrofa #2: Kognitivni teret (The Cognitive Load) Ovo je srž problema. U pokušaju da reše „usko grlo“, menadžeri su uradili „Shift-Left“. Natovarili su sve na leđa programera.

• Očekivanje: Programer (developer) sada mora da bude ekspert za:
  1. Biznis logiku (svoj stvarni posao).
  2. Pisanje koda (npr. Java/Spring Boot).
  3. Pisanje frontend-a (React).
  4. Baze podataka (PostgreSQL optimizacija).
  5. A sada i: Docker i kontejnerizaciju.
  6. Kubernetes (Šta je Pod? Šta je Service? Zašto mi deployment puca?).
  7. Terraform/IaC (Infrastructure as Code).
  8. CI/CD (Pisanje kompleksnih .gitlab-ci.yml ili GitHub Actions fajlova).
  9. Cloud (AWS/Azure/GCP servisi, IAM polise, VPC mreže…).
  10. Monitoring (Prometheus, Grafana…).
  11. Bezbednost (DevSecOps): A da, moraš da znaš i šta je SAST, DAST, OPA…

Ovo nije realno. Ovo je put u „burnout“ (sindrom sagorevanja). Uveli smo termin Kognitivni Teret (Cognitive Load). To je količina mentalnog napora potrebna da se obavi zadatak. Kada programer 50% svog vremena troši na YAML fajlove umesto na Javu, njegov kognitivni teret eksplodira. On postaje frustriran, spor, i počinje da pravi greške (i u kodu i u infrastrukturi).

„Shift-Left“ nije osnažio programere. Udavio ih je u kompleksnosti.

Poglavlje 2: Spasilac – Šta je, dođavola, Platform Engineering?

Platform Engineering (Platformski Inženjering) nije „DevOps 2.0“. To nije zamena za DevOps. To je, konačno, pravilna implementacija DevOps filozofije.

To je odgovor na pitanje: „Kako da dobijemo brzinu i automatizaciju DevOps-a, a da ne nateramo programere da kolektivno polude?“

Odgovor je radikalno jednostavan, a opet genijalan: Tretirajte svoju internu platformu kao PROIZVOD, a svoje programere kao KUPCE.

• Platformski Tim (Platform Team): Ovo je novi „DevOps“ tim. Ali njihov posao NIJE da rešavaju tikete. Njihov posao je da grade i održavaju proizvod.
• Proizvod: Taj proizvod se zove Interna Developerska Platforma (Internal Developer Platform – IDP).
• Kupci (Customers): Programeri (tj. stream-aligned timovi, ako koristimo Team Topologies terminologiju).

Šta je IDP? IDP je, u suštini, „zlatna staza“ (The Golden Path). To je sloj apstrakcije. To je „auto-put“ koji Platformski Tim gradi za programere. Programer i dalje može da ide „kozjim stazama“ (off-road) – da sam podešava svoj Kubernetes. Ali, Platformski Tim mu nudi auto-put sa 6 traka (IDP) koji je brz, bezbedan, osvetljen i vodi ga tačno tamo gde treba (u produkciju). 99% programera će izabrati auto-put.

Cilj Platform Engineeringa nije da oduzme alatke od programera. Cilj je da im sakrije nepotrebnu kompleksnost.

Poglavlje 3: „Zlatna Staza“ – Kako IDP zaista radi u praksi

Hajde da ovo učinimo konkretnim. Kako se menja život programerke Ane?

SCENARIO (STARI NAČIN – „Pakao Tiketa“):

• Dan 1: Ana (developer) dobija zadatak: „Napravi novi mikroservis za preporuke.“
• Dan 1 (Popodne): Ana otvara 5 tiketa:
  1. Tiket za Sistem Admina: „Kreiraj mi novi Git repozitorijum.“
  2. Tiket za DevOps Tim: „Podesi mi CI/CD pipeline.“
  3. Tiket za DBA Tim: „Treba mi nova PostgreSQL baza, evo ti parametri.“
  4. Tiket za Security Tim: „Otvorite mi port 5432 na firewall-u.“
• Dan 2-5: Ana čeka. Zove ljude. Moli. Eskalira. DevOps tim se buni jer je zaboravila da navede resource limits u tiketu.
• Dan 6: Ana konačno dobija pristup i počinje da piše stvarni kod.
• Vreme do prve linije koda: 6 dana.

SCENARIO (NOVI NAČIN – Platform Engineering):

• Dan 1 (9:00 ujutru): Ana dobija isti zadatak.
• Dan 1 (9:01): Ana otvara interni portal (IDP). (Najpoznatiji primer ovakvog portala je Spotify-jev alat Backstage, koji je sada open-source).
• Dan 1 (9:02): Ana klikne na „Software Templates“ (Šabloni Softvera).
• Dan 1 (9:03): Izabere šablon: „Java Spring Boot servis sa PostgreSQL bazom“.
• Dan 1 (9:04): Upisuje ime servisa: recommendation-service. Klikne „Kreiraj“.
• Dan 1 (9:05 – 9:10): Dok Ana pije kafu, Platforma (IDP) u pozadini automatski radi:
  1. Kreira novi Git repozitorijum sa već spremnim template kodom (sa podešenim logging-om, monitoring-om…).
  2. Automatski kreira CI/CD pipeline u GitLab-u ili GitHub Actions-u.
  3. Automatski, preko Terraform skripte, provizioniše staging i production bazu u Amazon RDS (ili gde god).
  4. Automatski kreira namespace u Kubernetes-u.
  5. Automatski postavlja default bezbednosne polise i monitoring dashboard u Grafani.
  6. Šalje Ani Slack poruku: „Sistem recommendation-service je spreman. Link do repozitorijuma je ovde. Srećno kodiranje.“
• Vreme do prve linije koda: 10 minuta.

Šta je Platformski Tim uradio? Nije radio posao za Anu. On je automatizovao posao. Napravio je „zlatnu stazu“ koja je 100% samouslužna (self-service). Anin kognitivni teret je sada nula. Ona ne mora da zna Kubernetes. Ne mora da zna Terraform. Ona samo treba da zna Javu – svoj posao.

Poglavlje 4: Pomeranje „Sec“ iz DevSecOps-a – Bezbednost po difoltu

A gde je „Sec“ (Security) u svemu ovome? U klasičnom DevSecOps modelu, „Shift-Left“ je značilo: „Ana, molim te, koristi SAST skener pre nego što commit-uješ kod.“ Opet teret na developeru.

U Platform Engineering modelu, pretnja se menja. „Shift-Left“ je zamenjen sa „Built-in Left“ (Ugrađeno ulevo), ili kako se to lepše kaže: „Paved Road, Secure by Default“ (Popločan put, bezbedan po difoltu).

Platformski Tim ugrađuje bezbednost u „zlatnu stazu“.

• Primer #1: Ana ne može da napravi pipeline koji nema bezbednosno skeniranje. Pipeline koji joj je IDP dao već sadrži SAST (Static) i DAST (Dynamic) skenere kao obavezan korak. Ona ne može da ga preskoči.
• Primer #2: Ana ne mora da brine o Kubernetes Network Policies (mrežnim pravilima). Platforma je automatski podesila njen servis da po difoltu ne može da priča ni sa kim, osim sa bazom koju mu je dodelila.
• Primer #3: Ana ne mora da brine o tajnama (lozinke za bazu, API ključevi). Platforma joj je automatski podesila HashiCorp Vault (ili sličan alat) i ubacila tajne na bezbedan način.

Rezultat: Ana (developer) je bezbedna, a da nije ni znala da se bavi bezbednošću. Kognitivni teret je nula. Bezbednost više nije nečija odgovornost; ona je karakteristika platforme.

Poglavlje 5: Surova realnost – Zašto Srbija kasni (i zašto mora da požuri)?

Hajde da spustimo loptu u Srbiju. Ako je ovo ovako genijalno, zašto sve firme u Beogradu, Novom Sadu i Nišu ne rade ovako?

Problem #1: „Gazda“ mentalitet i kratkoročni ROI (Povrat investicije)

• Izgradnja Interne Developerske Platforme (IDP) je skupa.
• To zahteva da odvojite vaših 5-10 najboljih inženjera (najskupljih „seniora“) da rade na internom projektu.
• Tih 10 inženjera ne donosi direktan prihod. Oni ne rade za klijenta. Oni su, iz ugla „gazde“, čist trošak (overhead).
• Potrebno je 6-12 meseci da se napravi prva verzija IDP-a.
• „Gazda“ koji razmišlja od kvartala do kvartala ne vidi vrednost. On vidi samo trošak.

Problem #2: „Outsourcing“ model (Rat protiv klijenata)

• U outsourcing firmi, vi imate 50 klijenata. Klijent 1 hoće Azure. Klijent 2 hoće AWS. Klijent 3 hoće „goli metal“ (bare-metal). Klijent 4 koristi Javu. Klijent 5 koristi .NET.
• Kako da napravite jedan IDP („zlatnu stazu“) za 50 različitih zahteva?
• Oštra istina: Ne možete. Zato je Platform Engineering mnogo lakši za Product kompanije (koje prave jedan proizvod, npr. Nordeus, 3Lateral, Frame/Nutanix, Microsoft Development Center Serbia) nego za outsourcing.
• Outsourcing firme mogu da grade „mini-platforme“ po klijentu, ali je to mnogo teže.

Problem #3: „Kupićemo gotovo“ (Zabluda o PaaS-u)

• Mnogi misle da je Platform Engineering = „kupiti Heroku“ (ili Vercel, Netlify…).
• Ne. To je PaaS (Platform-as-a-Service). To je deo rešenja.
• Vaš IDP je više od toga. On integriše vaše alate, vašu bezbednost, vaš monitoring, vaš GitLab… PaaS je samo jedna od komponenti koju vaša platforma može da koristi.

Zašto Srbija MORA da požuri? Jer je „zlatna groznica“ gotova. „Tech Winter“ i AI su promenili igru.

• Klijenti više ne plaćaju za „10 ruku“. Oni plaćaju za brzinu isporuke (velocity) i efikasnost.
• Zamislite da se dve srpske firme takmiče za isti posao:
  • Firma A (Stari model): „Trebaće nam 3 nedelje da podesimo okruženje i počnemo.“
  • Firma B (Platform Engineering): „Naš tim može da počne da piše kod za 15 minuta.“
• Ko dobija posao?

Platform Engineering prestaje da bude „luksuz“. Postaje osnovno oružje za preživljavanje.

Poglavlje 6: Budućnost (i AI) – Konverzacija kao novi interfejs

Šta je sledeće? IDP portali kao Backstage su sjajni, ali su i dalje – interfejs. Morate da klikćete. Budućnost Platform Engineeringa je uklanjanje i tog poslednjeg koraka.

• Sada (IDP 1.0): Ana (developer) ide na portal i klika da bi dobila servis.
• Budućnost (IDP 2.0 – koja već počinje): Ana ne ide nigde.
• Ona ostaje u svom omiljenom alatu (npr. Visual Studio Code ili Slack).
• Otvara AI Asistenta (Chatbot-a), npr. GitHub Copilot Chat.
• Ana kuca: „Hej, treba mi novi Go mikroservis za keširanje, spojen na Redis, sa staging i production okruženjem. Postavi ga.“
• AI Agent: „Razumem. Potvrdi ime servisa: go-caching-service.“
• Ana kuca: „Potvrđujem.“
• Rezultat: AI Agent u pozadini poziva API-je Interne Developerske Platforme i odrađuje sav posao (Git, CI/CD, Cloud…).
• Kognitivni teret = NULA.

U ovom modelu, Platform Engineering tim postaje tim koji gradi API-je i alate koje će AI agenti koristiti. AI postaje ultimativni „prevodilac“ između ljudske želje (developera) i mašinske egzekucije (platforme).

Platforma je proizvod, a developer je kralj

Da se vratimo na početak. DevOps kao kultura saradnje je živ i zdrav. Ali DevOps kao implementacija „prebaci sve na developera“ je mrtav. I treba da bude.

„Shift-Left“ je bila katastrofalna greška u prevodu. Davila je naše najvrednije resurse u birokratiji i kompleksnosti koju nisu tražili.

Platform Engineering je ispravka. To je povratak razumu. To je priznanje da programeri treba da rade jedan posao, ali da ga rade savršeno: rešavanje poslovnih problema kodom.

Posao Platformskog Tima je da im omogući da to rade. Da im sagradi „auto-put“. Da im skloni Kubernetes sa očiju. Da ugradi bezbednost „u zidove“.

Kompanije u Srbiji (i svetu) koje ovo shvate će pobediti u narednoj deceniji. Ne zato što imaju bolje programere, već zato što oslobađaju svoje programere da budu briljantni. U novoj eri, Developer Experience (DX) – Iskustvo Programera – nije „benefit“. To je najvažnija poslovna metrika.

Vaša platforma je vaš najvažniji proizvod. A vaš programer je vaš najvažniji kupac. Počnite da ga tretirate kao takvog.