# Vysvetlenie cloud computingu: 11 architektonických konceptov, ktoré musíte poznať (4K Masterclass).

Published: 2026-09-15

Väčšina softvérových inžinierov sa snaží naučiť cloudovú architektúru zapamätaním si stoviek akronymov dodávateľských produktov naprieč AWS, GCP a Azure. Ale reálne cloudové inžinierstvo je postavené na jedenástich fundamentálnych architektonických primitívoch. V tejto 4K remasterovanej masterclass Niko rozoberá kompletný podnikový plán: od vertikálneho verzus horizontálneho škálovania a vyrovnávania záťaže vrstvy 7 po dynamické automatické škálovanie, bezserverové vykonávanie mikro-VM, asynchrónne udalostne riadené oddelenie, orchestráciu kontajnerov, štvorpilierovú hierarchiu úložiska, kritický rozdiel medzi vysokou dostupnosťou a 11 deviatkami trvácnosti, deklaratívnu Infraštruktúru ako kód a sieťovanie Virtual Private Cloud. Ovládnite týchto jedenásť konceptov a môžete navrhnúť akýkoľvek backend v produkcii. Verdikt: SHIP IT.

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

## Čo toto video pokrýva

- - Architektonický múr a hlavný plán
- - 01. Vertikálne vs. horizontálne škálovanie
- - 02. Architektúra vyrovnávania záťaže (L4 vs. L7 a kontroly stavu)
- - 03. Automatické škálovanie a elasticita
- - 04. Bezserverové (FaaS a Firecracker MicroVMs)

## Kapitoly

- 0:00 - Architektonický múr a hlavný plán
- 0:57 - 01. Vertikálne vs. horizontálne škálovanie
- 2:17 - 02. Architektúra vyrovnávania záťaže (L4 vs. L7 a kontroly stavu)
- 3:45 - 03. Automatické škálovanie a elasticita
- 4:50 - 04. Bezserverové (FaaS a Firecracker MicroVMs)
- 6:05 - 05. Udalostne riadená architektúra (EDA a oddelenie)
- 7:13 - 06. Orchestrácia kontajnerov (Docker a Kubernetes)
- 8:16 - 07. 4 piliere cloudového úložiska (S3, EBS, DBs a Redis)
- 9:44 - 08. Vysoká dostupnosť a deviatky (Multi-AZ Failover)
- 10:53 - 09. Trvácnosť vs. dostupnosť (Prečo 11 deviatok nie je dostupnosť)
- 12:14 - 10. Infraštruktúra ako kód (Terraform vs. Console Drift)
- 13:20 - 11. Cloudové siete (VPC, podsiete, NAT a bezpečnostné skupiny)
- 14:26 - 12. Kompletný podnikový plán a verdikt

## Preložený prepis

Preložené z pôvodného anglického rozprávania. Dostupný zvuk a titulky sú kontrolované službou YouTube.

### - Architektonický múr a hlavný plán

0:00 Každý softvérový inžinier sa nakoniec stretne s múrom cloudovej architektúry. Vytvoríte aplikáciu na svojom notebooku, odošlete ju do produkcie, a v momente, keď prídu skutoční používatelia, servery padajú, pripojenia k databáze sa vyčerpajú a váš účet AWS vyzerá ako telefónne číslo. Väčšina vývojárov sa snaží riešiť cloudové inžinierstvo zapamätaním si tristo rôznych akronymov produktov AWS. Ale skutočný cloud computing nie je o zapamätaní si katalógov dodávateľov: je postavený na jedenástich fundamentálnych architektonických primitívoch.

0:34 V tejto masterclass prejdeme celým podnikovým plánom: od škálovania a vyrovnávania záťaže po bezserverové, udalostne riadené oddelenie, hierarchie úložiska a cloudové siete. Ovládnite týchto jedenásť konceptov a môžete navrhnúť akýkoľvek backend na AWS, GCP alebo Azure. Toto je The Daily Diff, pod kapotou.

### - 01. Vertikálne vs. horizontálne škálovanie

0:57 Koncept číslo jedna: Škálovanie. Keď vaša aplikácia zažíva rast prevádzky, máte dva zásadne odlišné spôsoby, ako zvládnuť záťaž: vertikálne škálovanie, alebo horizontálne škálovanie. Vertikálne škálovanie, alebo škálovanie nahor, znamená vziať svoj existujúci stroj a pridať viac zdrojov: upgrade zo štyroch CPU jadier na tridsaťdva, alebo výmenu tridsaťdva gigabajtov RAM za sto dvadsaťosem. Vertikálne škálovanie nevyžaduje žiadne architektonické zmeny: váš kód

1:28 a databáza zostanú presne rovnaké. Ale narazí na brutálny hardvérový strop. Žiadny samostatný stroj na svete nemá desaťtisíc CPU jadier, a špičkové inštancie nesú exponenciálnu cenovú prémiu. Horizontálne škálovanie, alebo škálovanie von, znamená udržiavať svoje servery malé a za komoditné ceny, ale spúšťať viacero inštancií paralelne za routerom. Ak jedna inštancia spadne, zostávajúce uzly absorbujú prevádzku s nulovými výpadkami. Zlaté pravidlo horizontálneho škálovania je

2:01 bezstavovosť: vaše aplikačné servery nemôžu ukladať užívateľské relácie, nahrané súbory alebo stav na svojich lokálnych diskoch. Stav musí žiť v externej databáze alebo cache, čo umožňuje ľubovoľnému uzlu spracovať akúkoľvek užívateľskú požiadavku.

### - 02. Architektúra vyrovnávania záťaže (L4 vs. L7 a kontroly stavu)

2:17 Koncept číslo dva: Vyrovnávanie záťaže. Horizontálne škálovanie znie na papieri skvele, ale prináša okamžitý problém: keď desaťtisíc používateľov navštívi vaše doménové meno, ktorý konkrétny server prijíma ich prevádzku? Load balancer funguje ako reverzný proxy server sediaci medzi verejným internetom a vaším súkromným backendovým klastrom. Prijíma prichádzajúce TCP alebo HTTP pripojenia a distribuuje požiadavky medzi vaše zdravé inštancie.

2:47 Load balancery fungujú na dvoch hlavných sieťových vrstvách. Load balancery siete vrstvy 4 fungujú na transportnej vrstve, smerujúce surové TCP a UDP pakety na základe IP adresy a portu s mikrosekundovou latenciou a miliónmi požiadaviek za sekundu. Load balancery aplikácií vrstvy 7 kontrolujú samotný protokol HTTP: čítajú URL cesty, hlavičky požiadaviek, cookies a HTTP metódy. To umožňuje smerovanie založené na ceste: odosielanie požiadaviek s lomkou-api na váš backendový klaster a požiadaviek s lomkou-static do

3:25 objektového úložiska. Kľúčové je, že load balancery vykonávajú aktívne kontroly stavu. Každých niekoľko sekúnd balancer pingne koncový bod stavu na každej inštancii. Ak inštancia vyhodí tri po sebe idúce päťstovkové chyby alebo nereaguje, je automaticky vylúčená z fondu s nulovými odmietnutými požiadavkami.

### - 03. Automatické škálovanie a elasticita

3:45 Koncept číslo tri: Automatické škálovanie. Ak vaša webová aplikácia potrebuje dva servery o tretej ráno, ale dvadsať serverov počas poludňajšieho spustenia, ručné klikanie na tlačidlá v cloudovej konzole je zaručená cesta k výpadkom a bankrotu. Automatické škálovanie prináša dynamickú elasticitu horizontálnym serverovým poolom. Skupina automatického škálovania monitoruje metriky výkonu, ako je priemerné využitie CPU, sieťové I-O alebo hĺbka frontu čakajúcich úloh. Keď priemerné využitie CPU prekročí definovaný prah – napríklad,

4:19 sedemdesiat percent po dobu troch po sebe idúcich minút – autoscaler automaticky spustí nové virtuálne stroje, zaregistruje ich s vaším load balancerom, a začne smerovať prevádzku. Rovnako dôležité je škálovanie dovnútra: keď vlna prevádzky ustúpi, autoscaler ukončí nadbytočné inštancie, takže prestanete platiť za nečinný výpočet. Aby sa predišlo preklápaniu – kedy sa servery rýchlo vytvárajú a ničia v nekonečnej cyklickej slučke – cloudoví architekti konfigurujú obdobia ochladenia. Koncept číslo štyri: Bezserverové.

### - 04. Bezserverové (FaaS a Firecracker MicroVMs)

4:53 Po roky marketingové tímy propagovali bezserverové ako magický kód bežiaci na oblohe. V skutočnosti bezserverové stále používa servery – ale vy ich nevlastníte, nepatchujete ani za ne neplatíte, keď nebeží žiadny kód. S Function-as-a-Service, ako sú AWS Lambda alebo Google Cloud Functions, napíšete samostatnú obslužnú funkciu. Keď dôjde k požiadavke HTTP, nahrávaniu súboru S3 alebo zmene databázy, cloudový runtime spustí efemérnu

5:23 mikro-virtuálny stroj ako Firecracker za menej ako päť milisekúnd. Váš kód sa vykoná, vráti odpoveď a vypne sa. Ak nikto nenavštívi vašu webovú stránku tri mesiace, váš účet za výpočty je presne nula dolárov a nula centov. Ak ju milión používateľov navštívi súčasne, poskytovateľ spustí milión súbežných microVM. Inžinierske kompromisy sú skutočné: latencia studeného štartu pri spúšťaní čerstvých runtime, pevný pätnásťminútový limit vykonávania na Lambda a prísna bezstavovosť.

5:55 Bezserverové je neprekonateľné pre udalostné pipeline a sporadické API, ale slabé pre perzistentné WebSockets alebo viachodinové tréningové behy.

### - 05. Udalostne riadená architektúra (EDA a oddelenie)

6:05 Koncept číslo päť: Udalostne riadená architektúra, alebo EDA. V tradičných architektúrach komunikujú služby synchrónne. Vaša služba pokladne volá platbu, platba volá inventár, inventár volá podvod a podvod volá e-mail. To vytvára synchrónnu kaskádu skazy. Ak poskytovateľ e-mailu tretej strany zažije sieťový výpadok a trvá mu desať sekúnd, kým odpovie, celá žiadosť zákazníka o pokladňu vyprší s chybou. V udalostne riadenej architektúre sú služby úplne oddelené.

6:37 Keď zákazník klikne na kúpiť, služba pokladne nevolá nadväzné služby. Jednoducho publikuje udalosť s názvom OrderPlaced do centrálnej Udalostnej zbernice ako Amazon EventBridge alebo témy SNS. Pokladňa sa dokončí za päťdesiat milisekúnd. Nadväzujúce pracovné procesy pre platbu, odpočet inventára a potvrdenia e-mailom sťahujú správy nezávisle z vlastných vyhradených front SQS. Ak e-mailová služba vypadne na hodinu, správy bezpečne čakajú vo fronte bez jedinej stratenej objednávky.

### - 06. Orchestrácia kontajnerov (Docker a Kubernetes)

7:13 Koncept číslo šesť: Orchestrácia kontajnerov. Docker vyriešil balenie: zabalí váš aplikačný kód, systémové knižnice, konfiguráciu a runtime do nemenného obrazu, ktorý beží identicky na vašom MacBooku aj v cloude. Ale zabalenie kontajnera je jednoduché. Spustenie päťsto kontajnerov naprieč päťdesiatimi fyzickými virtuálnymi strojmi je miesto, kde inžinierstvo zlyháva. Preto existujú orchestrátory kontajnerov ako Kubernetes a AWS ECS.

7:41 Orchestrátor poskytuje riadiacu rovinu: API server, úložisko stavu etcd a inteligentný plánovač. Deklarujete požadovaný stav: Chcem desať replík mojej autentifikačnej služby s dvoma gigabajtmi RAM pre každú. Plánovač kontroluje klaster, umiestňuje pody na uzly s voľnou pamäťou, konfiguruje interné siete a nepretržite zosúlaďuje realitu. Ak uzol utrpí hardvérovú poruchu, Kubernetes zistí stratu a okamžite preplánuje všetky presunuté pody na

### - 07. 4 piliere cloudového úložiska (S3, EBS, DBs a Redis)

8:16 zdravé uzly. Koncept číslo sedem: Hierarchia cloudového úložiska. Začiatočníci často považujú cloudové úložisko za jeden kôš, kam hádžete súbory. V produkčnej architektúre je úložisko rozdelené do štyroch odlišných pilierov na základe vzorov prístupu a latencie. Prvé je Objektové úložisko, ako Amazon S3 alebo Google Cloud Storage. Prístup k súborom cez HTTP REST API pomocou jednoduchých PUT a GET volaní. Ponúka nekonečnú horizontálnu kapacitu za dva centy za gigabajt mesačne,

8:49 čo ho robí ideálnym pre video, nahrávky používateľov, logy a zálohy. Druhé je Blokové úložisko, ako Amazon EBS. Toto sú virtuálne pevné disky pripojené priamo k špecifickému virtuálnemu stroju cez vysokorýchlostné prepojenia. Formátujú sa do štandardných súborových systémov ako ext4, podporujúc rýchly náhodný prístup na čítanie a zápis, ktorý vyžadujú databázové systémy. Tretie sú Spravované databázy: relačné systémy ako PostgreSQL na RDS poskytujúce ACID transakcie a komplexné joiny,

9:21 a NoSQL systémy ako DynamoDB poskytujúce jednocifernú milisekundovú latenciu pri masívnom rozsahu. A štvrté sú In-Memory Caches ako Redis. Čítanie dát z RAM trvá mikrosekundy namiesto milisekúnd. Caches sedia pred vašou databázou, chránia ju pred opakovanou čítacou prevádzkou a spravujú prchavé tokeny užívateľských relácií.

### - 08. Vysoká dostupnosť a deviatky (Multi-AZ Failover)

9:44 Koncept číslo osem: Vysoká dostupnosť, alebo HA. Dostupnosť odpovedá na jednu otázku: aké percento času je vaša aplikácia funkčná a dosiahnuteľná pre používateľov? V podnikových zmluvách sa dostupnosť meria v deviatkach. Dve deviatky, alebo deväťdesiatdeväť percent dostupnosti, umožňuje viac ako tri a pol dňa výpadkov každý rok. Štyri deviatky znižujú povolený výpadok na päťdesiatdva minút, a päť deviatok povoľuje sotva päť minút celkových výpadkov za

10:15 rok. Na dosiahnutie vysokej dostupnosti musíte eliminovať jednotlivé body zlyhania naprieč doménami chýb. V cloude to znamená nasadenie naprieč viacerými zónami dostupnosti. Zóna dostupnosti nie je jeden rack: je to jedno alebo viac odlišných fyzických dátových centier vzdialených míle od seba s nezávislým napájaním a chladením. Spustením aktívnych inštancií v zóne A a zóne B so synchrónnou replikáciou databázy, úder blesku alebo pretrhnutie optického kábla, ktoré vyradí celé fyzické zariadenie, má za následok automatické prepnutie na zálohu.

10:50 za tridsať sekúnd bez akéhokoľvek ľudského zásahu.

### - 09. Trvácnosť vs. dostupnosť (Prečo 11 deviatok nie je dostupnosť)

10:53 Koncept číslo deväť: Trvanlivosť verzus Dostupnosť. Toto je najčastejšia konceptuálna pasca v cloudovej architektúre rozhovoroch. Inžinieri často používajú tieto slová zameniteľne, ale merajú úplne iné vlastnosti. Dostupnosť meria dobu prevádzky: môžem uskutočniť volanie API na čítanie alebo zápis mojich údajov práve v tejto sekunde? Trvanlivosť meria uchovanie: prežijú moje dáta bez trvalého bitového rozkladu, poškodenia alebo zničenia po dobu desiatich rokov?

11:24 Pozrite sa na Amazon S3 Standard. Jeho dohoda o úrovni služieb ponúka deväťdesiatdeväť celých deväť desatín percenta dostupnosti, čo umožňuje zhruba štyridsaťtri minút výpadku mesačne, počas ktorých môže požiadavka API vrátiť chybu päťsto. Ale S3 sľubuje jedenásť deviatok trvanlivosti: deväťdesiatdeväť celých deväťdeväťdeväťdeväťdeväťdeväťdeväť deväťdeväť percent. Ak uložíte desať miliónov súborov do S3, štatisticky môžete očakávať stratu

11:56 priemerne jedného súboru každých desaťtisíc rokov. S3 to dosahuje kódovaním objektov s chybovou korekciou a replikáciou blokov naprieč najmenej tromi geograficky oddelenými dátovými centrami. Počas veľkého regionálneho výpadku siete môže byť S3 dočasne nedostupné, ale vaše dáta nikdy nie sú zničené.

### - 10. Infraštruktúra ako kód (Terraform vs. Console Drift)

12:14 Koncept číslo desať: Infraštruktúra ako kód, alebo IaC. V raných dňoch cloud computingu sa inžinieri prihlasovali do webovej správcovskej konzoly AWS a ručne preklikávali, aby vytvorili virtuálne stroje, konfigurovali podsiete a pripojili bezpečnostné skupiny. Odvetvie to nazýva ClickOps a v produkcii je to absolútna katastrofa. Manuálne zmeny v konzole nemajú auditnú stopu, žiadny mechanizmus pre vrátenie zmien a nevyhnutne spôsobujú rozdiel v konfigurácii medzi stagingovými a produkčnými prostrediami. S nástrojmi Infraštruktúry

12:48 ako kód, ako sú Terraform, OpenTofu, Pulumi alebo AWS CDK, definujete svoju celú cloudovú architektúru v deklaratívnych konfiguračných súboroch uložených v Gite. Každá zmena otvoreného portu alebo repliky databázy prechádza cez pull request a vzájomné preskúmanie. Spustenie \`terraform plan\` zobrazí presný rozdiel API predtým, ako sa čokoľvek dotkne, a spustenie identickej repliky vášho produkčného zásobníka trvá štyri minúty namiesto štyroch týždňov.

### - 11. Cloudové siete (VPC, podsiete, NAT a bezpečnostné skupiny)

13:20 Koncept číslo jedenásť: Cloudové siete a virtuálne privátne cloudy. Keď nasadíte servery do cloudu, nesedia vystavené na surovom verejnom internete. Žijú vo vnútri softvérovo definovanej izolovanej hranice nazývanej VPC. Vo vnútri vašej VPC pridelíte súkromný rozsah IP adries, ako napríklad desať bodka nula bodka nula bodka nula lomka šestnásť, a rozdelíte ho na verejné a súkromné podsiete. Verejná podsieť má priamu cestu k internetovej bráne.

13:51 Obsahuje verejne prístupné aktíva, ako sú vaše aplikačné load balancery a NAT brány. Je to jediná časť vašej siete, ktorá má verejné IP adresy. Vaše aplikačné servery a produkčné databázy žijú výhradne v súkromných podsieťach bez verejných IP adries a nulových prichádzajúcich trás z internetu. Keď vaše backend servery potrebujú stiahnuť bezpečnostné aktualizácie, ich odchádzajúca prevádzka smeruje cez NAT bránu vo verejnej podsieti. Každú inštanciu obklopujú Bezpečnostné skupiny: stavové virtuálne firewally, ktoré presadzujú princíp najmenších privilégií.

### - 12. Kompletný podnikový plán a verdikt

14:28 Bezpečnostná skupina vašej databázy akceptuje pripojenia na porte 5432 výhradne z bezpečnostnej skupiny vašich aplikačných serverov, čo robí externú penetráciu matematicky nemožnou. Keď sa odkloníte, týchto jedenásť primitív sa spája do jedného súdržného systému. Váš DNS smeruje na Load Balancer vo verejnej podsieti, skupiny automatického škálovania spracúvajú návaly prevádzky naprieč viacerými zónami dostupnosti, zbernice udalostí oddeľujú backendových pracovníkov a celý váš zásobník je nasadený z Gitu pomocou Infraštruktúry ako kódu.

15:02 Verdikt dnešnej majstrovskej triedy: SHIP IT. Prestaňte si pamätať stovky marketingových skratiek cloudu. Osvojte si týchto jedenásť architektonických vzorov, oddelte svoj stav a budujte systémy, ktoré nemôžu zlyhať. Povedzte mi, ktorý cloudový koncept vám spôsobil najväčšie bolesti hlavy, keď ste prvýkrát začali budovať, v komentároch. A aby ste získali kompletný architektonický cheat sheet, prihláste sa na odber noviniek na the daily diff dot dev,

15:28 odkaz nižšie. A to je rozdiel na dnes. Som Niko z Axrisi. Zlúčte zodpovedne.

## Zdroje

- [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