# Računarstvo u oblaku objašnjeno: 11 arhitektonskih koncepata koje morate znati (4K Masterclass).

Published: 2026-09-15

Većina softverskih inženjera pokušava da nauči arhitekturu oblaka pamteći stotine akronima proizvoda dobavljača za AWS, GCP i Azure. Ali inženjering oblaka u stvarnom svetu izgrađen je na jedanaest fundamentalnih arhitektonskih primitiva. U ovom 4K remaster masterclass-u, Niko razlaže kompletan nacrt preduzeća: od vertikalnog nasuprot horizontalnog skaliranja i balansiranja opterećenja sloja 7 do dinamičkog automatskog skaliranja, izvršavanja mikroVM-a bez servera, asinhronog odvajanja vođenog događajima, orkestracije kontejnera, četvorostubne hijerarhije skladištenja, kritične razlike između visoke dostupnosti i 11 devetki trajnosti, deklarativne infrastrukture kao koda i umrežavanja virtuelne privatne mreže. Savladajte ovih jedanaest koncepata i moći ćete da dizajnirate bilo koji bek-end u proizvodnji. Presuda: SHIP IT.

Canonical: https://thedailydiff.dev/sr-Latn/video/2026-09-14-cloud-computing-explained-4k/

## Šta ovaj video pokriva

- - Arhitektonski zid i glavni nacrt
- - 01. Vertikalno naspram horizontalnog skaliranja
- - 02. Arhitektura balansiranja opterećenja (L4 naspram L7 i provere zdravlja)
- - 03. Automatsko skaliranje i elastičnost
- - 04. Bezserverno (FaaS i Firecracker MicroVMs)

## Poglavlja

- 0:00 - Arhitektonski zid i glavni nacrt
- 0:57 - 01. Vertikalno naspram horizontalnog skaliranja
- 2:17 - 02. Arhitektura balansiranja opterećenja (L4 naspram L7 i provere zdravlja)
- 3:45 - 03. Automatsko skaliranje i elastičnost
- 4:50 - 04. Bezserverno (FaaS i Firecracker MicroVMs)
- 6:05 - 05. Arhitektura vođena događajima (EDA i odvajanje)
- 7:13 - 06. Orkestracija kontejnera (Docker i Kubernetes)
- 8:16 - 07. 4 stuba skladištenja u oblaku (S3, EBS, DBs i Redis)
- 9:44 - 08. Visoka dostupnost i devetke (Multi-AZ Failover)
- 10:53 - 09. Trajnost naspram dostupnosti (Zašto 11 devetki nije uptime)
- 12:14 - 10. Infrastruktura kao kod (Terraform naspram Console Drift)
- 13:20 - 11. Umrežavanje u oblaku (VPC, Subnets, NAT i Security Groups)
- 14:26 - 12. Kompletan nacrt preduzeća i presuda

## Preveden transkript

Prevedeno sa originalne engleske naracije. Dostupan audio i titlovi kontrolisani su od strane YouTube-a.

### - Arhitektonski zid i glavni nacrt

0:00 Svaki softverski inženjer na kraju se suoči sa zidom arhitekture oblaka. Izgradite aplikaciju na svom laptopu, gurnete je u produkciju, i u trenutku kada stignu pravi korisnici, serveri se ruše, konekcije baze podataka se potroše, a vaš AWS račun izgleda kao telefonski broj. Većina developera pokušava da reši inženjering oblaka pamćenjem trista različitih AWS akronima proizvoda. Ali pravo računarstvo u oblaku nije pamćenje kataloga dobavljača: ono je izgrađeno na jedanaest fundamentalnih arhitektonskih primitiva.

0:34 U ovoj masterklasi, proći ćemo kroz ceo poslovni nacrt: od skaliranja i balansiranja opterećenja do bezservernog, odvajanja vođenog događajima, hijerarhija skladištenja i umrežavanja u oblaku. Savladajte ovih jedanaest koncepata i moći ćete da dizajnirate bilo koji bek-end na AWS-u, GCP-u ili Azure-u. Ovo je The Daily Diff, ispod haube.

### - 01. Vertikalno naspram horizontalnog skaliranja

0:57 Koncept broj jedan: Skaliranje. Kada vaša aplikacija doživi porast saobraćaja, imate dva fundamentalno različita načina za rukovanje opterećenjem: vertikalno skaliranje, ili horizontalno skaliranje. Vertikalno skaliranje, ili skaliranje nagore, znači uzimanje vaše postojeće mašine i dodavanje više resursa: nadogradnja sa četiri CPU jezgra na trideset i dva, ili zamena trideset i dva gigabajta RAM-a za sto dvadeset i osam. Vertikalno skaliranje zahteva nulte arhitektonske promene: vaš kod

1:28 i baza podataka ostaju potpuno isti. Ali nailazi na brutalni hardverski plafon. Nijedna mašina na svetu nema deset hiljada CPU jezgara, a vrhunske instance nose eksponencijalnu cenovnu premiju. Horizontalno skaliranje, ili skaliranje nagore, znači držanje vaših servera malim i po cenama robe, ali pokretanje više instanci paralelno iza rutera. Ako jedna instanca padne, preostali čvorovi apsorbuju saobraćaj sa nultim zastojem. Zlatno pravilo horizontalnog skaliranja je

2:01 bezstanost: vaši aplikacioni serveri ne mogu skladištiti korisničke sesije, otpremljene datoteke ili stanje na svojim lokalnim diskovima. Stanje mora živeti u eksternoj bazi podataka ili kešu, dozvoljavajući bilo kom čvoru da obrađuje bilo koji korisnički zahtev.

### - 02. Arhitektura balansiranja opterećenja (L4 naspram L7 i provere zdravlja)

2:17 Koncept broj dva: Balansiranje opterećenja. Horizontalno skaliranje zvuči sjajno na papiru, ali uvodi neposredan problem: kada deset hiljada korisnika pogodi vaše ime domena, koji specifični server prima njihov saobraćaj? Balanser opterećenja deluje kao reverzni proksi koji se nalazi između javnog interneta i vašeg privatnog bek-end klastera. Prihvata dolazne TCP ili HTTP veze i distribuira zahteve preko vaših zdravih instanci.

2:47 Balanseri opterećenja rade na dva primarna mrežna sloja. Layer 4 Network Load Balancers rade na transportnom sloju, rutirajući sirove TCP i UDP pakete na osnovu IP adrese i porta sa latencijom mikrosekundi i milionima zahteva u sekundi. Layer 7 Application Load Balancers pregledavaju sam HTTP protokol: čitanje URL putanja, zaglavlja zahteva, kolačića i HTTP metoda. Ovo omogućava rutiranje bazirano na putanji: slanje slash-api zahteva vašem bek-end klasteru i slash-static zahteva u

3:25 skladište objekata. Ključno je da balansi opterećenja vrše aktivne provere zdravlja. Svakih nekoliko sekundi, balanser pinguje zdravstvenu krajnju tačku na svakoj instanci. Ako instanca baci tri uzastopne greške petsto ili ne uspe da odgovori, automatski se izbacuje iz bazena sa nultim odbačenim zahtevima.

### - 03. Automatsko skaliranje i elastičnost

3:45 Koncept broj tri: Automatsko skaliranje. Ako vašoj veb aplikaciji trebaju dva servera u tri ujutro, ali dvadeset servera tokom podnevnog pokretanja, ručno kliktanje dugmadi u konzoli oblaka je garantovani put do zastoja i bankrota. Automatsko skaliranje donosi dinamičku elastičnost horizontalnim bazenima servera. Grupa za automatsko skaliranje prati metrike performansi kao što su prosečna iskorišćenost CPU-a, mrežni I/O ili dubina zastoja reda čekanja. Kada prosečni CPU pređe definisani prag — recimo,

4:19 sedamdeset posto tokom tri uzastopna minuta — autoskaler automatski pokreće nove virtuelne mašine, registruje ih kod vašeg balansera opterećenja, i počinje da rutira saobraćaj. Podjednako važno je i skaliranje unutra: kada se talas saobraćaja povuče, autoskaler ukida prekomerne instance tako da prestajete da plaćate za neaktivnu obradu. Da bi se sprečilo kolebanje — gde se serveri brzo kreiraju i uništavaju u beskrajnoj petlji gašenja — arhitekti oblaka konfigurišu periode mirovanja. Koncept broj četiri: Bezserverno.

### - 04. Bezserverno (FaaS i Firecracker MicroVMs)

4:53 Godinama su marketinški timovi predstavljali bezserverno kao magični kod koji radi na nebu. U stvarnosti, bezserverno i dalje koristi servere — ali ih vi ne posedujete, ne patchujete, niti plaćate kada kod ne radi. Sa Funkcijom kao Uslugom kao što su AWS Lambda ili Google Cloud Functions, pišete samostalnu funkciju rukovaoca. Kada se desi HTTP zahtev, S3 otpremanje datoteke ili promena baze podataka, cloud runtime pokreće efemernu

5:23 mikro-virtuelnu mašinu kao što je Firecracker za manje od pet milisekundi. Vaš kod se izvršava, vraća odgovor i gasi se. Ako niko ne poseti vašu veb stranicu tri meseca, vaš račun za obradu je tačno nula dolara i nula centi. Ako ga milion korisnika pogodi istovremeno, provajder pokreće milion istovremenih mikroVM-a. Inženjerski kompromisi su stvarni: latencija hladnog starta prilikom pokretanja novih runtimea, strogo ograničenje izvršavanja od petnaest minuta na Lambdi i stroga bezstanost.

5:55 Bezserverno je nepobedivo za event pajpove i sporadične API-je, ali loše za trajne WebSocket-ove ili višekčasovne treninge.

### - 05. Arhitektura vođena događajima (EDA i odvajanje)

6:05 Koncept broj pet: Arhitektura vođena događajima, ili EDA. U tradicionalnim arhitekturama, servisi komuniciraju sinhrono. Vaš servis za naplatu poziva plaćanje, plaćanje poziva inventar, inventar poziva prevaru, a prevara poziva e-mail. Ovo stvara sinhronu kaskadu propasti. Ako treći provajder e-pošte doživi mrežni problem i treba mu deset sekundi da odgovori, ceo zahtev vašeg korisnika za naplatu ističe sa greškom. U arhitekturi vođenoj događajima, servisi su potpuno razdvojeni.

6:37 Kada korisnik klikne kupi, servis za naplatu ne poziva donje servise. On jednostavno objavljuje događaj pod nazivom OrderPlaced na centralnu magistralu događaja kao što je Amazon EventBridge ili SNS tema. Naplata se završava za pedeset milisekundi. Donji radnici za plaćanje, odbitak inventara i račune e-pošte nezavisno povlače poruke iz svojih namenskih SQS redova. Ako servis e-pošte prestane sa radom na sat vremena, poruke čekaju sigurno buferisane u redu čekanja bez ijedne ispuštene narudžbine.

### - 06. Orkestracija kontejnera (Docker i Kubernetes)

7:13 Koncept broj šest: Orkestracija kontejnera. Docker je rešio pakovanje: on obuhvata vaš aplikacioni kod, sistemske biblioteke, konfiguraciju i runtime u nepromenljivu sliku koja radi identično na vašem MacBooku i u oblaku. Ali pakovanje kontejnera je lako. Pokretanje pet stotina kontejnera preko pedeset fizičkih virtuelnih mašina je mesto gde inženjering propada. Zato postoje orkestratori kontejnera kao što su Kubernetes i AWS ECS.

7:41 Orkestrator pruža kontrolni plan: API server, etcd skladište stanja i inteligentni raspoređivač. Deklarirate svoje željeno stanje: Želim deset replika mog auth servisa sa po dva gigabajta RAM-a. Raspoređivač pregleda klaster, postavlja podove na čvorove sa slobodnom memorijom, konfiguriše unutrašnje umrežavanje i kontinuirano usklađuje stvarnost. Ako čvor pretrpi hardverski kvar, Kubernetes otkriva gubitak i odmah preusmerava sve raseljene podove na

### - 07. 4 stuba skladištenja u oblaku (S3, EBS, DBs i Redis)

8:16 zdrave čvorove. Koncept broj sedam: Hijerarhija skladištenja u oblaku. Početnici često tretiraju skladištenje u oblaku kao jednu kantu gde bacate datoteke. U produkcijskoj arhitekturi, skladištenje je podeljeno na četiri različita stuba na osnovu obrazaca pristupa i latencije. Prvo je objektno skladištenje, kao Amazon S3 ili Google Cloud Storage. Datotekama pristupate preko HTTP REST API-ja koristeći jednostavne PUT i GET pozive. Nudi beskonačan horizontalni kapacitet po dva centa po gigabajtu mesečno,

8:49 što ga čini idealnim za video, korisničke otpreme, logove i rezervne kopije. Drugo je blokovsko skladištenje, kao Amazon EBS. To su virtuelni hard diskovi montirani direktno na određenu virtuelnu mašinu preko brzih interkonekcija. Formatiraju se u standardne fajl sisteme kao što je ext4, podržavajući brz nasumični pristup čitanju i pisanju koji zahtevaju mašine baza podataka. Treće su upravljane baze podataka: relacione mašine kao PostgreSQL na RDS-u koje pružaju ACID transakcije i složena spajanja,

9:21 i NoSQL mašine kao DynamoDB koje isporučuju jednocifrenu milisekundnu latenciju u ogromnim razmerama. I četvrto su keš memorije kao Redis. Čitanje podataka iz RAM-a traje mikrosekunde umesto milisekundi. Keš memorije se nalaze ispred vaše baze podataka, štiteći je od ponovljenog saobraćaja čitanja i upravljajući nestabilnim tokenima korisničke sesije.

### - 08. Visoka dostupnost i devetke (Multi-AZ Failover)

9:44 Koncept broj osam: Visoka dostupnost, ili HA. Dostupnost odgovara na jedno pitanje: koliki procenat vremena je vaša aplikacija operativna i dostupna korisnicima? U korporativnim ugovorima, dostupnost se meri u devetkama. Dve devetke, ili devedeset devet posto dostupnosti, dozvoljavaju preko tri i po dana zastoja svake godine. Četiri devetke smanjuju dozvoljeni zastoj na pedeset dve minute, a pet devetki dozvoljava jedva pet minuta ukupnog zastoja godišnje.

10:15 Da biste postigli visoku dostupnost, morate eliminisati pojedinačne tačke kvara preko domena kvara. U oblaku, to znači raspoređivanje preko više zona dostupnosti. Zona dostupnosti nije jedan rack: to je jedan ili više različitih fizičkih data centara udaljenih kilometrima sa nezavisnim napajanjem i hlađenjem. Pokretanjem aktivnih instanci u Zoni A i Zoni B sa sinhronom replikacijom baze podataka, udar groma ili prekid optičkog kabla koji obara čitavu fizičku ustanovu rezultira automatskim preusmeravanjem.

10:50 za trideset sekundi bez ikakve ljudske intervencije.

### - 09. Trajnost naspram dostupnosti (Zašto 11 devetki nije uptime)

10:53 Deveti koncept: Trajnost naspram Dostupnosti. Ovo je najčešća konceptualna zamka u intervjuima za arhitekturu u oblaku. Inženjeri često koriste ove reči naizmenično, ali one mere potpuno različite osobine. Dostupnost meri vreme rada: mogu li da uputim API poziv da bih pročitao ili upisao svoje podatke baš ovog trenutka? Trajnost meri očuvanje: da li će moji podaci preživeti bez trajnog oštećenja, korupcije ili uništenja tokom deset godina?

11:24 Pogledajte Amazon S3 Standard. Njegov Ugovor o nivou usluge nudi devedeset devet zarez devet procenata dostupnosti, što dozvoljava otprilike četrdeset tri minuta zastoja svakog meseca gde API zahtev može da vrati grešku petsto. Ali S3 obećava jedanaest devetki trajnosti: devedeset devet zarez devet devet devet devet devet devet devet devet devet procenata. Ako skladištite deset miliona datoteka u S3, statistički možete očekivati da izgubite

11:56 u proseku jednu datoteku svakih deset hiljada godina. S3 ovo postiže kodiranjem objekata za brisanje i repliciranjem delova preko najmanje tri geografski odvojene lokacije za skladištenje podataka. Tokom velikog regionalnog prekida mreže, S3 možda privremeno neće biti dostupan, ali vaši podaci nikada nisu uništeni.

### - 10. Infrastruktura kao kod (Terraform naspram Console Drift)

12:14 Koncept broj deset: Infrastruktura kao kod, ili IaC. U ranim danima računarstva u oblaku, inženjeri su se prijavljivali na AWS veb konzolu za upravljanje i ručno kliktali da bi kreirali virtuelne mašine, konfigurisali podmreže i prikačili sigurnosne grupe. Industrija ovo naziva ClickOps, a u produkciji, to je apsolutna katastrofa. Ručne promene konzole nemaju revizioni trag, nema mehanizma za povratak, i neizbežno uzrokuju odstupanje konfiguracije između razvojnih i produkcionih okruženja. Sa alatima za infrastrukturu

12:48 kao kod, poput Terraform, OpenTofu, Pulumi ili AWS CDK, celu svoju arhitekturu oblaka definišete u deklarativnim konfiguracionim datotekama pohranjenim u Gitu. Svaka promena otvorenog porta ili replike baze podataka prolazi kroz zahtev za povlačenje i recenziju kolega. Pokretanje terraform plan pregleda tačnu API razliku pre nego što se bilo šta dotakne, a podizanje identične replike vašeg produkcionog steka traje četiri minuta umesto četiri nedelje.

### - 11. Umrežavanje u oblaku (VPC, Subnets, NAT i Security Groups)

13:20 Koncept broj jedanaest: Mreža u oblaku i virtuelne privatne mreže. Kada rasporedite servere u oblak, oni ne stoje izloženi na sirovom javnom internetu. Oni žive unutar softverski definisane izolovane granice nazvane VPC. Unutar vašeg VPC-a, dodeljujete privatni IP adresni prostor kao što je deset-tačka-nula-tačka-nula-tačka-nula kosa crta šesnaest, i delite ga na javne i privatne podmreže. Javna podmreža ima direktnu rutu do Internet Gateway-a.

13:51 Ona sadrži javno dostupne resurse poput vaših Application Load Balancera i NAT Gateway-a. To je jedini deo vaše mreže koji poseduje javne IP adrese. Vaši aplikacioni serveri i produkcione baze podataka žive isključivo u privatnim podmrežama bez javnih IP adresa i nula dolaznih ruta sa interneta. Kada vaši backend serveri trebaju da preuzmu sigurnosne ispravke, njihov odlazni saobraćaj se rutira kroz NAT Gateway u javnoj podmreži. Oko svake instance su Sigurnosne Grupe: virtuelni zaštitni zidovi sa stanjem koji primenjuju princip najmanje privilegije.

### - 12. Kompletan nacrt preduzeća i presuda

14:28 Sigurnosna grupa vaše baze podataka prihvata veze samo na portu 5432 isključivo od sigurnosne grupe vaših aplikacionih servera, što čini spoljnu penetraciju matematički nemogućom. Kada se udaljite, ovih jedanaest primitiva se povezuje u jedan kohezivni sistem. Vaš DNS rutira do Load Balancera u javnoj podmreži, grupe za automatsko skaliranje rukuju naletima saobraćaja preko više zona dostupnosti, sabirnice događaja razdvajaju backend radnike, i ceo vaš stek je raspoređen iz Git-a koristeći Infrastrukturu kao kod.

15:02 Presuda današnjeg masterklasa: SHIP IT. Prestanite da pamtite stotine marketinških skraćenica u oblaku. Savladajte ovih jedanaest arhitektonskih obrazaca, odvojite svoje stanje, i gradite sisteme koji ne mogu da zakažu. Recite mi koji vam je koncept oblaka zadavao najveću glavobolju kada ste tek počeli da gradite u komentarima. A da biste preuzeli kompletan "cheat sheet" za arhitekturu, pretplatite se na bilten na thedaily diff dot dev,

15:28 link ispod. I to je razlika za danas. Ja sam Niko iz Axrisija. Spajajte odgovorno.

## Izvori

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io