Platformsko inženjerstvo u praksi: Izgradnja internih platformi za razvojne inženjere

Platformsko inženjerstvo prestalo je biti trend i postalo je dokazana praksa. CNCF-ovo istraživanje iz 2025. pokazalo je da 82% korisnika spremnika pokreće Kubernetes u produkciji, no istraživanje CNCF-a i SlashData među razvojnim inženjerima u cloud-native okruženjima pokazuje da samo 28% organizacija ima posvećen platformski tim. Dva podatka dolaze iz istraživanja različitog opsega i populacija, pa razliku između njih treba čitati kao ilustrativni signal, a ne kao dokaz da većina timova vodi modernu infrastrukturu bez interne platforme. Ovaj vodič objašnjava što je interna platforma za razvojne inženjere (IDP), zašto je timovi grade, kako je kadrovski oblikovati i kako je uvesti postupno.

Problem koji IDP rješava

Interna platforma za razvojne inženjere (IDP) integrirana je zbirka mogućnosti ponuđena kao proizvod: API-ji za samoposluživanje, alati, usluge i “zlatne staze” (golden paths) koje smanjuju kognitivno opterećenje programera. CNCF-ova bijela knjiga o platformama (Platforms White Paper) navodi pet razloga za izgradnju: smanjenje kognitivnog opterećenja timova, veća pouzdanost jer se stručnjaci posvećuju konfiguraciji, brža isporuka ponovnom uporabom zajedničkih alata, manji sigurnosni i regulatorni rizik upravljanjem mogućnostima te kontrola troškova oblaka uz dosljedno korisničko iskustvo.

Bez platforme svaki tim iznova gradi isti cjevovod, isti put dodjele resursa i isti monitoring. Rezultat su duplicirani napori, nedosljedna sigurnost i sporo uključivanje novih članova. Nekoliko platformskih timova koji služe mnogim timovima umnožava njihov učinak.

DORA-ino izvješće iz 2024. dodaje važnu ogradu: IDP poboljšava produktivnost pojedinca, uspješnost tima i organizacije, ali može smanjiti stabilnost promjena i propusnost ako se uvede nepažljivo. Cilj je neovisnost razvojnih timova, a ne novo usko grlo.

Platforma kao proizvod

CNCF-ova bijela knjiga navodi sedam obilježja uspješne platforme:

1. Platforma kao proizvod — služi najčešćim slučajevima upotrebe u timovima, s naglaskom na širinu umjesto na niše pojedinih timova.
2. Korisničko iskustvo — dosljedna sučelja: GUI, API, CLI, IDE i portal.
3. Dokumentacija i uključivanje — dokumenti i predlošci koji čine paket zlatne staze.
4. Samoposluživanje — programeri samostalno traže i dobivaju mogućnosti.
5. Smanjeno kognitivno opterećenje — pojedinosti implementacije skrivene su; korisnici ne moraju upravljati uslugama.
6. Neobvezna i sastavljiva — timovi mogu koristiti dijelove platforme ili je u potpunosti napustiti.
7. Sigurno prema zadanim postavkama — usklađenost i provjera slijede organizacijske standarde.

Način razmišljanja o proizvodu važan je jednako kao i alati. DORA preporučuje imenovati voditelja proizvoda za razvojno iskustvo, mapirati kritične korisničke putove (pokretanje nove usluge, otklanjanje greške u produkciji) i graditi strateški plan razvoja na temelju potreba programera. Portal, CLI, API i predlošci čine sučelje platforme; prema njima se treba odnositi kao prema proizvodu za kupce.

Tim i operativni model

Platformski timovi odgovorni su za sučelja i iskustva — portale, API-je, dokumentaciju, predloške i CLI — a ne nužno za upravljanje računalnim resursima, mrežom ili pohranom. CNCF-ova bijela knjiga daje im tri zadaće: istražiti zahtjeve korisnika i planirati razvoj mogućnosti, promovirati vrijednost platforme i upravljati sučeljima. Okvir Team Topologies to opisuje kao platformski tim koji stvara mogućnosti koje mnogi timovi usklađeni s tokovima vrijednosti koriste uz malo dodatnog napora.

Usvajanje se još uvijek oblikuje. Technology Radar CNCF-a i SlashData iz prvog tromjesečja 2026. pokazuje da 41% organizacija koristi suradnju više timova za platformski rad, a samo 28% ima posvećen tim. DORA-ina stranica o platformskom inženjerstvu izvještava o znatno širem usvajanju: 90% organizacija koristi internu platformu, a 76% ima posvećene timove. Dva istraživanja mjere različite populacije, no oba pokazuju isti smjer: platformski rad postaje norma, a zreli model jest posvećen i središnje financiran tim.

Aspekt ulaganja u CNCF-ovom modelu zrelosti opisuje napredak: dobrovoljni timovi (Provisional), posvećen središnje financiran tim (Operational), upravljanje proizvodom s planom razvoja i naplatom (Scalable) te ekosustav u kojem stručnjaci proširuju platformu (Optimizing). Često citirana Gartnerova prognoza očekivala je da će do 2026. 80% velikih organizacija za razvoj softvera osnovati platformske timove, u odnosu na 45% iz 2022. — riječ je o predviđanju, ne o mjerenju.

Zlatne staze i samoposluživanje

Zlatna staza preporučeni je i podržani put do uobičajenog rezultata. Spotify, koji je popularizirao taj pojam, definira je kao put do “izgradnje nečega” — backend usluge, web stranice ili podatkovnog cjevovoda — popraćen uputama korak po korak. Cilj je ukloniti razvoj “vođen glasinama”: timovi slijede isprobani put umjesto da alate slažu iz blog postova i hodničkih priča.

Zlatna staza višekratno je upotrebljiv radni tok za izgradnju, skeniranje, testiranje, implementaciju i praćenje aplikacije, isporučen s početnim predloškom projekta i dokumentacijom. Samoposluživanje znači da programer može zatražiti bazu podataka i dobiti njezinu adresu i vjerodajnice pokretanjem CLI naredbe ili ispunjavanjem web obrasca — bez naloga i čekanja.

Backstage, Spotifyjev portal otvorenog koda za razvojne inženjere, najpoznatiji je primjer prikaza zlatnih staza u katalogu softvera s TechDocs dokumentacijom. Prema CNCF-ovoj stranici projekta, riječ je o projektu u fazi Incubating — ne Graduated — s tisućama suradnika i izvrsnom ocjenom zdravlja projekta.

Izlazni putovi su važni. CNCF-ova bijela knjiga navodi neobveznost i sastavljivost kao obilježje: timovi mogu koristiti dijelove platforme ili je napustiti, ali napuštanje podržanog puta znači gubitak iste razine podrške.

Arhitektura i izbor alata

Platforma bi trebala biti najtanji mogući sloj iznad upravljanih pružatelja usluga i gradivnih blokova otvorenog koda. Domene mogućnosti iz CNCF-ove bijele knjige izravno se preslikavaju u zrele alate otvorenog koda:

• Portali za razvojne inženjere: Backstage, Skooner
• Dodjela resursa i API-ji: Kubernetes, Crossplane, Helm, KubeVela
• Isporuka i GitOps: Argo, Flux, Keptn, Flagger
• Izgradnja i testiranje: Tekton, Buildpacks, ko
• Promatranje (observability): OpenTelemetry, Prometheus, Jaeger, Grafana
• Identitet i tajne: Keycloak, Dex, cert-manager, External Secrets
• Sigurnost i pravila: Falco, OPA, Kyverno, in-toto

Technology Radar iz prvog tromjesečja 2026. svrstava Helm (94% zrelosti s četiri ili pet zvjezdica), Backstage i kro u kategoriju Adopt za isporuku aplikacija, a Argo CD, Buildpacks, GitHub Actions (91% bi ih preporučilo) i Jenkins u Adopt za automatizaciju radnih tokova. U sigurnosnoj kategoriji u Adopt su cert-manager (87% s četiri ili pet zvjezdica), Keycloak i OPA. Isti radar bilježi da 35% organizacija integrira AI radna opterećenja kroz hibridne platforme — signal da dizajn platforme mora prihvatiti nove vrste opterećenja.

Ovisnost o dobavljaču pitanje je dizajna, a ne slučajnosti. Referentne arhitekture postoje — platformengineering.org objavljuje široko korištenu referentnu arhitekturu IDP-a, a AWS-ove smjernice pokrivaju izgradnju takve platforme na njihovu oblaku — no platformski sloj trebao bi ostati tanak i prenosiv. Microsoftov vodič za platformsko inženjerstvo poručuje isto: koristite gradivne blokove više dobavljača i vlastita ulaganja usmjerite na ljepilo koje stvara jedinstvenu vrijednost.

Sigurnosne i usklađene ograde

Sigurnost prema zadanim postavkama jedno je od CNCF-ovih obilježja. Ograde bi trebale živjeti u zlatnoj stazi, a ne u ručnim provjerama: predlošci ugrađuju pravila, skeniranje i zadane postavke identiteta koji se primjenjuju na pokrivene radne tokove. Provedba je jednako široka kao i opseg platforme — timovi izvan nje ili putovi s izričitim iznimkama nisu automatski pokriveni.

Nalazi radara o sigurnosti odražavaju taj obrazac: cert-manager za certifikate, Keycloak za identitet, OPA za pravila, dok alati za sigurnost opskrbnog lanca poput in-toto i Sigstore još sazrijevaju. Usklađenost ugrađena u predloške i mogućnosti automatizira i provodi pokrivene kontrole na podržanom putu, a budući da se pravila, skeniranje i provjere identiteta izvršavaju kroz platformu, moguće ih je revidirati. Usklađenost i dalje ovisi o tome što platforma pokriva, koje iznimke timovi dobiju i što provode temeljni pružatelji usluga.

Mjerenje uspjeha: promatranje i razvojno iskustvo

CNCF-ova bijela knjiga grupira metrike platforme u tri kategorije: zadovoljstvo i produktivnost korisnika (aktivni korisnici, zadržavanje, NPS, SPACE), organizacijska učinkovitost (latencija od zahtjeva do isporuke, vrijeme od uključivanja do prve promjene koda) i isporuka proizvoda (DORA metrike: učestalost implementacija, vrijeme do promjene, vrijeme oporavka usluge, stopa neuspjelih promjena).

DORA-ina uravnotežena tablica rezultata dodaje ankete o razvojnom iskustvu (CSAT ili NPS), okvir H.E.A.R.T. za usvajanje i zadržavanje te uspjeh zadataka: učinkovitost i djelotvornost dovršavanja ključnih radnih tokova. Pritom je mogućnost platforme koja je najsnažnije povezana s pozitivnim razvojnim iskustvom davanje jasne povratne informacije o ishodu zadataka.

Okvir DX Core 4 (Speed, Effectiveness, Quality, Impact) spaja DORA, SPACE i razvojno iskustvo u jedan model vrijedan usvajanja kao okvir — objavljene postotke ishoda tretirajte kao marketinške podatke dobavljača, ne kao neovisne dokaze. Model zrelosti upozorava na Goodhartov zakon: kada mjera postane cilj, prestaje biti dobra mjera. Mjerite da biste učili, ne da biste sudili.

Postupan plan usvajanja

CNCF-ov model zrelosti procjenjuje pet aspekata — ulaganje, usvajanje, sučelja, operacije i mjerenje — neovisno. Svaka viša razina zrelosti košta više sredstava i vremena, pa najviša razina nije automatski cilj. Kako u modelu kaže Martin Fowler, vrijednost procjene nije razina na kojoj se nalazite, nego popis stvari na kojima treba raditi.

1. Odaberite jednu zlatnu stazu. Uzmite najčešći radni tok — često implementaciju usluge — i izgradite tek toliko da taj put bude vidljivo bolji.
2. Surađujte s malim brojem angažiranih timova. Bijela knjiga predlaže početak s čestim, nediferenciranim mogućnostima poput cjevovoda, baza podataka i promatranja.
3. Mjerite usvajanje i povratne informacije. Pratite aktivne korisnike, latenciju od zahtjeva do isporuke i uspjeh zadataka; iterirajte na putu.
4. Oblikujte platformu za proširenje. Izložite jasne API-je i model doprinosa kako bi drugi timovi dodavali alate i usluge.
5. Očekujte J-krivulju. DORA napominje da platformske inicijative često slijede J-krivulju: početni dobici u učinku, zatim pad učinka kako složenost raste, prije oporavka i stabilizacije na višoj razini; planirajte taj pad.

Kultura je često pravo ograničenje. CNCF-ovo istraživanje iz 2025. pokazalo je da 47% ispitanika kao najveću prepreku navodi kulturnu promjenu s razvojnim timovima — ispred bilo kojeg tehnološkog izbora.

Uobičajene zamke i kako ih izbjeći

DORA-ine smjernice za platformsko inženjerstvo identificiraju pet protuuzoraka:

1. “Izgradi pa će doći” — gradnja na pretpostavkama bez istraživanja korisnika. Ublažite istraživanjem i partnerskim timovima.
2. “Kula od bjelokosti” — središnji tim nameće krute standarde bez suradnje, gurajući programere prema shadow IT rješenjima. Ublažite zajedničkim oblikovanjem s timovima.
3. Zamka ticketinga (ticket-ops) — platformski tim postaje reaktivni prodavač naloga umjesto da omogućava samoposluživanje. Ublažite ulaganjem u samoposluživanje.
4. “Veliki prasak” (big bang) — izgradnja svega prije isporuke ičega; potrebe se mijenjaju dok gradite. Ublažite ranom isporukom minimalne zlatne staze (MVP).
5. “Zlatni kavez” — kruta pravila za sve koja zanemaruju različite potrebe, poput podatkovne znanosti ili mobilnog razvoja. Ublažite dopustivim ograničenjima i izlaznim putovima.

Dva strukturna rizika zaslužuju pozornost. Prvo, CNCF-ova bijela knjiga napominje da platforme propadaju kada se ne tretiraju kao proizvodi: nametnuti mandati stvaraju otpor, a timovi koje se doživljava kao troškovna mjesta teško dobivaju sredstva. Uključite voditelje proizvoda od početka i povežite platformu s tokovima vrijednosti. Drugo, DORA-ino istraživanje iz 2024. pokazalo je da IDP može smanjiti stabilnost promjena i propusnost; zaštitite se od toga fokusom na neovisnost programera i mjerenjem uravnotežene tablice rezultata.

Počnite s jednom zlatnom stazom

Ne trebate veliku platformsku organizaciju da biste započeli. Standardizirajte jedan put implementacije, tretirajte platformu kao proizvod i širite se na temelju onoga što programeri stvarno prihvaćaju. Podatak o 28% posvećenih timova i podatak o 90% usvajanja opisuju isti trend iz različitih kutova: platformsko inženjerstvo kreće se prema tome da postane standardni način rada sa softverom, a najviše će pomoći onima koji krenu malo, mjere pošteno i održavaju platformu tankom.

Izvori: CNCF Annual Cloud Native Survey 2025, CNCF Platforms White Paper, CNCF i SlashData Q1 2026 Technology Radar, DORA Platform Engineering Capability, Spotify o zlatnim stazama, CNCF Platform Engineering Maturity Model, Gartner: Top Strategic Technology Trends in Software Engineering for 2024, Backstage | CNCF, platformengineering.org: Referentna arhitektura IDP-a na AWS-u, AWS Prescriptive Guidance: Izgradnja interne platforme za razvojne inženjere na AWS-u, Microsoft Learn: Vodič za platformsko inženjerstvo, DX: Mjerenje produktivnosti razvojnih inženjera uz DX Core 4