Postoji nešto pomalo apsurdno u tome da je postavljanje obične web stranice postalo tema za arhitektonski sastanak.
Stranica ima nekoliko podstranica, kontakt-formu, možda blog i nekoliko hiljada posjeta mjesečno. Ipak, vrlo brzo se počne govoriti o kontejnerima, orkestraciji, distribuiranim servisima, funkcijama koje se izvršavaju na zahtjev, upravljanim bazama podataka, centralizovanim zapisima, globalnoj isporuci sadržaja i infrastrukturi opisanoj kroz stotine redova konfiguracije.
Na kraju dobijemo sistem koji može podnijeti hipotetičkih deset miliona korisnika, ali koji niko u timu ne razumije bez otvaranja šest kontrolnih ploča i tri interna dokumenta.
Moj problem nije u AWS-u, Microsoft Azureu, Google Cloudu, Kubernetesu ili serverless tehnologijama. Sve su to ozbiljni alati koji rješavaju ozbiljne probleme. Moj problem počinje onda kada se njihovo korištenje pretvori u refleks, prije nego što je iko jasno objasnio koji problem zapravo rješavamo.
Ponekad nam, sasvim jednostavno, treba server.
Tri članka, ali zapravo jedan argument
Prije same rasprave o hostingu vrijedi primijetiti važan detalj: tri dostavljena članka nisu tri nezavisna izvora koja su slučajno došla do sličnog zaključka. Sva tri potpisuje David Timothy i sva tri predstavljaju varijacije iste osnovne teze.
To ne znači da ih treba odbaciti. Naprotiv, zajedno nude prilično široku argumentaciju protiv automatskog oslanjanja na velike cloud platforme. Ali bilo bi pogrešno njihovo međusobno slaganje predstaviti kao trostruku potvrdu autorovih tvrdnji. To je jedan autorski stav, objavljen i prilagođen za tri različite platforme.
Medium verzija je direktnija i više se oslanja na velike prekide rada kako bi pokazala opasnost koncentracije infrastrukture. Tekst na DEV Communityju detaljnije razlaže Kubernetes, serverless, troškove, vezivanje za jednog dobavljača i prividnu sigurnost takozvanog multi-cloud pristupa. Hashnode verzija snažnije naglašava praktičnu stranu tradicionalnog hostinga, razumljivost sistema i ideju da nezavisnost ne znači tehnološku čistotu.
Zajednička poruka je jasna: veliki cloud je mogućnost, a ne prirodni zakon.
S tom porukom se uglavnom slažem. Ipak, argument je uvjerljiviji kada ga odvojimo od pomalo romantične predstave da je jedan obični VPS samim tim jednostavan, nezavisan i siguran. Nije. Može biti sve to, ali samo ako neko zna šta radi.
Cloud nije problem, problem je odluka donesena unaprijed
Postoje dva potpuno različita načina da se započne razgovor o infrastrukturi.
Prvi je da se pitamo šta projektu treba.
Drugi je da se pitamo koje ćemo cloud servise koristiti.
Drugo pitanje već sadrži odgovor na mnogo važnije pitanje. Ono unaprijed pretpostavlja da projekat treba biti izgrađen unutar velikog cloud ekosistema. Nakon toga više ne odlučujemo da li nam takav sistem treba, nego samo biramo njegove dijelove.
Tu nastaje dobar dio nepotrebne složenosti.
Recimo da pravimo poslovnu web stranicu. Ona treba biti dostupna, brza, sigurna i redovno kopirana. Možda joj treba baza podataka. Možda treba slati elektronsku poštu. Ništa od toga samo po sebi ne zahtijeva distribuiranu arhitekturu.
Takav projekat može sasvim dobro raditi na kvalitetnom dijeljenom hostingu ili VPS-u. Ako ima veće potrebe, može dobiti snažniji server ili više od jednog servera. Tek kada se pojave stvarni zahtjevi za izrazito promjenjivim opterećenjem, globalnom dostupnošću, velikom količinom podataka, specifičnim regulatornim uslovima ili složenom organizacijom razvojnih timova, veliki cloud počinje nuditi prednosti koje je teško ili skupo reprodukovati na klasičnoj infrastrukturi.
Međutim, u tehnološkoj kulturi često se ponašamo kao da svaki novi projekat čeka globalna eksplozija korisnika.
Velika većina ih ne čeka.
Mnogo projekata nikada neće imati problem skaliranja. Neki neće imati ni problem publike. Uprkos tome, infrastruktura se planira za zamišljene milione korisnika, dok se stvarnih prvih stotinu još nije pojavilo.
To nije priprema za uspjeh. Često je samo skupo odgađanje rada na onome što korisniku zaista treba.
Složenost je postala statusni simbol
Jedna od boljih tvrdnji koja se provlači kroz sva tri teksta jeste da tehnološka industrija nagrađuje vidljivu složenost.
Rečenica „postavio sam aplikaciju na VPS“ ne zvuči naročito uzbudljivo. Nema komplikovanog dijagrama. Nema deset strelica između servisa. Nema nove skraćenice koju treba objasniti upravi.
Ako se ista aplikacija podijeli na funkcije, kontejnere, redove poruka, upravljanu bazu podataka, sistem za čuvanje tajni i nekoliko slojeva nadzora, odjednom djeluje ozbiljnije. Možemo održati prezentaciju o njoj. Možemo zaposliti ljude koji će upravljati platformom na kojoj radi platforma.
Problem je što količina tehnologije nije isto što i kvalitet inženjerske odluke.
Dobar inženjer ne pokazuje vrijednost tako što koristi najveći broj alata. Pokazuje je tako što bira najmanje složen sistem koji pouzdano ispunjava zahtjeve.
To „najmanje složen“ ne znači primitivan. Jedan VPS sa aplikacijom, bazom podataka i rezervnim kopijama može biti loše osmišljen. Može imati jednu tačku kvara, slabu zaštitu, neažuriran softver i kopije podataka koje niko nikada nije pokušao vratiti.
Ali ni dvadeset upravljanih servisa nije automatski sigurno. Samo ima više mjesta na kojima konfiguracija može biti pogrešna, više računa koji se mogu zloupotrijebiti i više zavisnosti koje korisnik ne vidi.
Jednostavnost nije odsustvo stručnosti. Prava jednostavnost je često rezultat stručnosti.
Kubernetes nije potvrda da je projekat ozbiljan
Kubernetes je izvrstan primjer tehnologije koja je od rješenja za određenu vrstu problema postala simbol profesionalnosti.
Ako organizacija ima mnogo servisa, više razvojnih timova, složene načine isporuke aplikacija, potrebu za automatskim raspoređivanjem radnih opterećenja i zahtjevnu infrastrukturu, Kubernetes može imati smisla. Njegova vrijednost tada nije izmišljena.
Ali blog nije takav problem. Nije ni većina prezentacijskih stranica. Često nije ni mala poslovna aplikacija.
Čak i kada je Kubernetes upravljan kao cloud servis, njegov konceptualni trošak ne nestaje. Neko i dalje mora razumjeti podove, servise, mrežu, pohranu, tajne, dozvole, ograničenja resursa, nadogradnje i cijeli ekosistem koji se s vremenom izgradi oko klastera.
Ako projekat koristi sve te mogućnosti, taj trošak može biti opravdan.
Ako ih ne koristi, dobili smo dodatni posao bez dodatne vrijednosti.
Slično važi i za serverless. Funkcije koje se izvršavaju samo kada su potrebne mogu biti odlične za obradu događaja, kratke zadatke i veoma promjenjivo opterećenje. Ali serverless aplikacija rijetko ostane jedna usamljena funkcija. Brzo joj trebaju pristupna pravila, okidači, API prolazi, skladište, nadzor, zapisivanje događaja i drugi servisi.
Serveri nisu nestali. Samo ih više ne kontrolišemo direktno, a račun se sada izračunava prema složenijoj formuli.
Nekada je to odlična razmjena. Nekada je način da običan dugotrajni proces pretvorimo u distribuirani sistem koji je teže razumjeti i preseliti.
Cijena nije samo iznos na računu
Veliki cloud se često prodaje kroz jednostavnu poruku: plati ono što koristiš.
To zvuči pošteno, a u određenim situacijama zaista jeste. Ako se opterećenje drastično mijenja, nema mnogo smisla stalno plaćati kapacitet potreban samo nekoliko sati mjesečno. Ako kompaniji treba skup specijalizovani sistem na kratko, iznajmljivanje može biti mnogo racionalnije od kupovine i održavanja vlastite infrastrukture.
Ali „plati ono što koristiš“ ima i drugu stranu: moraš razumjeti sve što koristiš.
Procesorsko vrijeme je jedna stavka. Memorija druga. Skladištenje treća. Broj zahtjeva četvrta. Izlazni promet može biti peta. Zapisivanje događaja, nadzor, javne adrese, pristupni prolazi i dodatne operacije mogu dobiti svoje mjerače.
Tako tehnička arhitektura postaje i arhitektura računa.
Kod tradicionalnog VPS-a cijena je obično dosadnija. Plaća se određena količina resursa, a projekat radi unutar tog okvira. Ako ga preraste, mora se optimizovati ili preseliti na snažniji sistem.
Ta predvidivost nije bezvrijedna. Za malo preduzeće iz Bosne i Hercegovine, samostalnog autora ili lokalnu organizaciju, neočekivan cloud račun nije zanimljiva lekcija iz skaliranja. To je konkretan finansijski problem.
Još važnije, cijena infrastrukture nije samo mjesečni račun. U nju ulazi vrijeme ljudi koji je postavljaju, održavaju, nadziru i pokušavaju razumjeti. Jeftin servis može biti skup ako zahtijeva rijetku stručnost. S druge strane, nešto skuplji upravljani servis može biti odlična kupovina ako timu ukloni posao za koji nema ni vremena ni znanja.
Zato se cloud i klasični hosting ne mogu pošteno porediti samo preko cijene procesora i memorije.
Kada „upravljano“ počne upravljati korisnikom
Upravljani servisi nude stvarnu pogodnost. Upravljana baza podataka može ukloniti veliki dio osjetljivog administrativnog posla. Sistem za identitet može spriječiti razvojni tim da napravi vlastito, loše rješenje za prijavu korisnika. Gotovi sistemi za redove poruka, skladištenje i analitiku mogu skratiti razvoj za mjesece.
Ali ono čega se odričemo obično se manje reklamira.
Prihvatamo ograničenja dobavljača, njegov način naplate, njegove programske interfejse, pravila naloga, raspored ukidanja proizvoda i promjene poslovnih prioriteta. Što dublje aplikacija koristi vlasničke servise jedne kompanije, preseljenje postaje teže.
Premjestiti konvencionalnu aplikaciju između dva servera nije uvijek lako, ali su njeni osnovni dijelovi obično prepoznatljivi. Datoteke su datoteke. PostgreSQL ili MariaDB postoje kod različitih pružalaca usluga. Linux server se može dobiti na mnogo mjesta.
Ako aplikacija zavisi od vlasničke baze, identiteta, funkcija, sistema poruka, nadzora i načina isporuke jednog clouda, preseljenje više nije migracija. To je djelimična rekonstrukcija proizvoda.
Vezivanje za dobavljača nije uvijek greška. Ako kompanija uz pomoć određenog servisa izađe na tržište godinu ranije, to može biti sasvim razumna poslovna odluka. Neozbiljno je samo praviti se da cijena te brzine ne postoji.
Pogodan servis nije isto što i nezavisan servis.
Veliki prekidi rada i pogrešna lekcija
Sva tri članka koriste prekide rada velikih infrastrukturnih kompanija kao argument protiv pretjerane centralizacije. Spominju se incidenti AWS-a, Microsoft Azurea, Google Clouda, Fastlyja i Cloudflarea, kao i njihov uticaj na veliki broj poznatih internetskih usluga.
Ovdje je važno izvući pravu lekciju.
Činjenica da je AWS imao veliki prekid ne dokazuje da je mali VPS pouzdaniji od AWS-a. Takav zaključak bio bi besmislen. Veliki pružaoci cloud usluga imaju ogromne timove, višestruke sisteme zaštite, automatizovan oporavak i nivo infrastrukture koji većina manjih kompanija ne može ni približno izgraditi.
I mali hosting može pasti. Može mu otkazati disk, mreža ili napajanje. Može napraviti lošu nadogradnju. Može imati katastrofalnu korisničku podršku. Može jednostavno prestati poslovati.
Razlika je u obimu posljedica.
Kada padne mali pružalac hostinga, padaju stranice njegovih korisnika. Za njih je to ozbiljno, ali ostatak interneta uglavnom nastavlja raditi. Kada problem pogodi osnovni servis dominantne cloud regije, posljedice se mogu preliti na hiljade naizgled nepovezanih aplikacija.
Posebno je zanimljivo što različiti brendovi ne znače nužno različitu infrastrukturu. Jedna platforma može zavisiti od druge, koja zatim zavisi od treće, a čiji se kritični podaci nalaze kod jednog od nekoliko velikih cloud dobavljača. Korisnik vidi različite logotipe i plaća odvojene račune, ali se lanac zavisnosti na kraju vraća na isto mjesto.
Tako možemo kupiti privid raznovrsnosti, a da stvarna tehnička zavisnost ostane centralizovana.
U tekstovima se incident Google Clouda iz juna 2025. opisuje ponešto različito. Jedna verzija ga pojednostavljuje kao problem vezan za sloj identiteta i pristupa, dok detaljnija verzija govori o promjeni politike u sistemu Service Control i neadekvatnoj obradi pogrešnih podataka. Ta razlika ne ruši glavni argument, ali pokazuje zašto tehničke prekide ne treba svoditi na zgodnu etiketu. Uzrok, mehanizam širenja i posljedice nisu ista stvar.
Najzanimljiviji detalj nije samo da aplikacija može prestati raditi. Problem može pogoditi i sistem nadzora koji bi trebalo da objasni zašto aplikacija ne radi. Ako su proizvod, zapisnici, statusni alati i komunikacija vezani za istu osnovnu infrastrukturu, rezervni plan postoji uglavnom na papiru.
Manji pružalac nije isto što i decentralizacija
Autor sva tri teksta s pravom brani manje hosting kompanije, regionalne centre podataka, VPS pružaoce i tradicionalni dijeljeni hosting. Raznovrsnost dobavljača smanjuje vjerovatnoću da jedan incident istovremeno pogodi ogroman dio interneta.
Ipak, ovdje treba biti oprezan.
Mali hosting može iznajmljivati servere od većeg pružaoca. Njegova mreža može zavisiti od nekoliko velikih operatera. DNS može biti kod Cloudflarea, elektronska pošta kod Microsofta, zaštita od napada kod treće kompanije, a rezervne kopije u velikom cloudu.
Drugim riječima, stranica smještena izvan AWS-a nije automatski nezavisna od velikih infrastrukturnih sistema.
Potpuna tehnološka nezavisnost danas je skoro nemoguća, a često ni nema ekonomskog smisla. Cilj ne treba biti nekakva ideološka čistota u kojoj odbijamo svaki veliki servis. Cilj treba biti da razumijemo gdje se nalaze kritične zavisnosti i šta se događa kada jedna od njih nestane.
To je mnogo korisniji pristup od lijepljenja oznake „decentralizovano“ na sistem samo zato što račun ne stiže od Amazona.
Razumljivost je ozbiljna tehnička prednost
Najjači argument u korist dosadne infrastrukture za mene nije ni cijena ni nostalgija. To je razumljivost.
Sistem koji odgovorna osoba može obuhvatiti vlastitim mentalnim modelom lakše je održavati, popravljati i preseliti. Ako znam gdje aplikacija radi, gdje su joj podaci, kako se pokreće, gdje zapisuje greške i kako se vraća rezervna kopija, već imam važan dio operativne sigurnosti.
To ne znači da sve moram raditi ručno. Automatizacija je korisna. Kontejneri mogu biti korisni. Kontrolna ploča može biti korisna. Upravljana baza može biti korisna.
Besmislen je taj tehnički mačizam prema kojem ozbiljan administrator mora sve raditi u terminalu, dok je svako grafičko sučelje znak slabosti. Ako alat čini legitiman posao jasnijim i bržim, onda radi ono zbog čega alat postoji.
Ali razumljivost ne smije ostati izgovor za nemar. Jedan server i jedna rezervna kopija nisu plan oporavka ako je kopija stalno priključena na isti sistem ili ako nikada nije testirana. Jednostavan sistem mora se ažurirati, zaštititi i nadzirati. Kapacitet se mora pratiti. Treba znati ko reaguje kada nešto pođe pogrešno.
„Dosadno“ je pohvala samo kada znači provjereno i predvidivo. Ako znači napušteno, neažurirano i bez kopija, onda je to samo loša infrastruktura.
Multi-cloud često liječi složenost dodatnom složenošću
Kada se spomene zavisnost od jednog velikog pružaoca, brz odgovor često glasi: multi-cloud.
Na papiru zvuči odlično. Aplikacija radi kod više dobavljača, pa kvar jednog ne ruši cijeli sistem. U praksi to može zahtijevati dvostruke ili trostruke konfiguracije, različite mrežne modele, različite sigurnosne politike, složeniju isporuku i ljude koji poznaju nekoliko velikih platformi.
Za banku, globalnu komunikacijsku platformu ili ključni državni sistem takav trošak može biti opravdan.
Za malu aplikaciju, pokušaj da se izbjegne jedan složen cloud tako što ćemo istovremeno koristiti tri složena clouda djeluje kao liječenje glavobolje udarcem čekića.
Portabilnost ne mora značiti da sve stalno radi svuda. Može značiti da aplikacija koristi uobičajene tehnologije, da su podaci dostupni u prenosivom formatu, da postoji dokumentovan postupak preseljenja i da ključne funkcije nisu neraskidivo vezane za deset vlasničkih servisa.
Mogućnost odlaska ponekad vrijedi više od aktivnog prisustva kod više dobavljača.
Šta bih ja pitao prije izbora infrastrukture
Ne bih započeo pitanjem da li je bolji AWS ili VPS. To je prerano.
Prvo bih pitao koliki promet projekat stvarno ima, a ne koliki sanja da će imati. Zatim bih pogledao koliko prekida može podnijeti, kakve podatke čuva, postoje li pravni ili regulatorni zahtjevi, koliko brzo mora rasti i ko će sistem održavati.
Jednako je važno znati kako se vraća nakon kvara. Rezervna kopija koja nije testirana samo je optimistična pretpostavka. Redundantnost koja zavisi od istog DNS-a, istog naloga i iste cloud regije može biti samo skuplja verzija jedne tačke kvara.
Pitao bih i koliko bi preseljenje trajalo ako dobavljač podigne cijene, ugasi servis, blokira nalog ili promijeni uslove korištenja. Ne zato što će se to nužno dogoditi, nego zato što prava vrijednost izlaznog plana postaje vidljiva tek kada je kasno da ga pravimo.
Tek nakon tih odgovora ima smisla birati tehnologiju.
Ako zahtjevi vode prema velikom cloudu, treba ga koristiti bez osjećaja krivice. Ako vode prema Kubernetesu, isto važi. Ali ti alati treba da zasluže mjesto u arhitekturi. Ne treba ga dobiti automatski zato što dobro izgledaju u oglasu za posao.
Internetu ne treba jedan savršeni stanodavac
Koncentracija internetske infrastrukture nije rezultat tajnog plana. Velike platforme su postale velike zato što nude dobre proizvode, široku dostupnost i pogodnosti koje je teško ignorisati.
Upravo zato je problem složeniji.
Svaka pojedinačna kompanija može donijeti racionalnu odluku da koristi AWS, Azure, Google Cloud ili Cloudflare. Kada hiljade kompanija donesu istu racionalnu odluku, cijeli sistem može postati kolektivno krhkiji.
To je razlika između pouzdanosti pojedinačnog dobavljača i otpornosti interneta kao cjeline.
Internetu ne trebaju manje sposobni servisi samo da bi bili mali. Trebaju mu stvarne alternative, različite mreže, regionalni centri podataka, prenosive aplikacije i korisnici koji znaju da je pogodnost oblik zavisnosti.
Ne mislim da se trebamo vratiti u vrijeme kada je svaki vlasnik stranice morao sam održavati fizički server. Niti mislim da je ručno administriranje sistema nekakav moralno superioran izbor. Veliki cloud je omogućio projekte koje bi ranije bilo preskupo ili previše sporo izgraditi.
Ali odbijam ideju da je tehnički napredak isto što i dodavanje novih slojeva.
Nekada je napredak upravo suprotan: prepoznati da projekat nema problem globalnog skaliranja, izabrati običan server, napraviti dobre rezervne kopije, dokumentovati sistem i završiti posao.
Cloud treba koristiti kada rješava problem koji stvarno imamo. Kubernetes treba koristiti kada zaista imamo nešto što treba orkestrirati. Serverless treba koristiti kada način izvršavanja odgovara opterećenju. Upravljani servis treba prihvatiti kada njegova korist opravdava cijenu i zavisnost.
Sve ostalo je kupovina složenosti na kredit.
Meni ozbiljna infrastruktura nije ona koja ima najviše servisa, najljepši dijagram ili najmoderniji rječnik. Ozbiljna je ona koju ljudi mogu razumjeti, održavati, platiti i oporaviti kada nešto neminovno pođe pogrešno.
Ako je za to dovoljan jedan dobro podešen server, nema se čega stidjeti.
Ponekad je dosadna tehnologija dosadna upravo zato što već dugo radi.
IZVORI