# Објаснето облачно пресметување: 11 архитектонски концепти што мора да ги знаете (4K мастерклас).

Published: 2026-09-15

Повеќето софтверски инженери се обидуваат да научат облачна архитектура со меморирање стотици акроними на производи од продавачи низ AWS, GCP и Azure. Но, инженерството за облак во реалниот свет е изградено на единаесет фундаментални архитектонски примитиви. Во овој 4K ремастер мастерклас, Нико го разложува комплетниот претпријатие-план: од вертикално наспроти хоризонтално скалирање и балансирање на оптоварување на Слој 7 до динамично автоматско скалирање, извршување на серверски microVM, асинхроно одвојување водено од настани, оркестрација на контејнери, четири-столбна хиерархија за складирање, критичната разлика помеѓу висока достапност и 11 деветки издржливост, декларативна инфраструктура како код и вмрежување на виртуелен приватен облак. Совладајте ги овие единаесет концепти, и ќе можете да архитектирате било каков бекенд во производство. Пресуда: SHIP IT.

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

## Што покрива ова видео

- - Архитектонскиот ѕид и главен план
- - 01. Вертикално наспроти хоризонтално скалирање
- - 02. Архитектура за балансирање на оптоварување (L4 наспроти L7 и здравствени проверки)
- - 03. Автоматско скалирање и еластичност
- - 04. Безсерверно (FaaS и Firecracker MicroVMs)

## Поглавја

- 0:00 - Архитектонскиот ѕид и главен план
- 0:57 - 01. Вертикално наспроти хоризонтално скалирање
- 2:17 - 02. Архитектура за балансирање на оптоварување (L4 наспроти L7 и здравствени проверки)
- 3:45 - 03. Автоматско скалирање и еластичност
- 4:50 - 04. Безсерверно (FaaS и Firecracker MicroVMs)
- 6:05 - 05. Архитектура водена од настани (EDA и одвојување)
- 7:13 - 06. Оркестрација на контејнери (Docker и Kubernetes)
- 8:16 - 07. 4-те столбови на облачно складирање (S3, EBS, DBs и Redis)
- 9:44 - 08. Висока достапност и деветки (Multi-AZ Failover)
- 10:53 - 09. Издржливост наспроти достапност (Зошто 11 деветки не е време на работа)
- 12:14 - 10. Инфраструктура како код (Terraform наспроти Console Drift)
- 13:20 - 11. Облачно вмрежување (VPC, подмрежи, NAT и безбедносни групи)
- 14:26 - 12. Комплетниот претпријатие-план и пресуда

## Преведен транскрипт

Преведено од оригиналната англиска нарација. Достапното аудио и наслови се контролирани од YouTube.

### - Архитектонскиот ѕид и главен план

0:00 Секој софтверски инженер на крајот се соочува со ѕидот на облачната архитектура. Вие градите апликација на вашиот лаптоп, ја ставате во производство, и во моментот кога ќе пристигнат вистински корисници, серверите паѓаат, врските со базата на податоци се исцрпуваат, а вашата AWS сметка изгледа како телефонски број. Повеќето програмери се обидуваат да го решат облачното инженерство со меморирање триста различни акроними на AWS производи. Но, вистинското облачно пресметување не е за меморирање на каталози на продавачи: тоа е изградено на единаесет фундаментални архитектонски примитиви.

0:34 Во овој мастерклас, ќе го пројдеме целиот претпријатие-план: од скалирање и балансирање на оптоварување до безсерверни, одвојување водено од настани, хиерархии за складирање и облачно вмрежување. Совладајте ги овие единаесет концепти, и ќе можете да дизајнирате било каков бекенд на AWS, GCP или Azure. Ова е The Daily Diff, под хаубата.

### - 01. Вертикално наспроти хоризонтално скалирање

0:57 Концепт број еден: Скалирање. Кога вашата апликација доживува раст на сообраќајот, имате два фундаментално различни начини да се справите со оптоварувањето: вертикално скалирање или хоризонтално скалирање. Вертикалното скалирање, или скалирање нагоре, значи земање на вашата постоечка машина и додавање повеќе ресурси: надградба од четири процесорски јадра на триесет и две, или замена на триесет и два гигабајти RAM меморија за сто дваесет и осум. Вертикалното скалирање не бара никакви архитектонски промени: вашиот код

1:28 и базата на податоци остануваат потполно исти. Но, тоа наидува на брутален хардверски плафон. Ниту една машина во светот нема десет илјади процесорски јадра, а врвните инстанци носат експоненцијална ценовна премија. Хоризонталното скалирање, или скалирање нанадвор, значи задржување на вашите сервери мали и со комерцијална цена, но извршување на повеќе инстанци паралелно зад рутер. Ако една инстанца падне, преостанатите јазли го апсорбираат сообраќајот со нула застој. Златното правило на хоризонталното скалирање е

2:01 безсостојбеност: вашите сервери за апликации не можат да складираат кориснички сесии, поставени датотеки или состојба на нивните локални дискови. Состојбата мора да живее во надворешна база на податоци или кеш, овозможувајќи му на кој било јазол да се справи со кое било корисничко барање.

### - 02. Архитектура за балансирање на оптоварување (L4 наспроти L7 и здравствени проверки)

2:17 Концепт број два: Балансирање на оптоварување. Хоризонталното скалирање звучи одлично на хартија, но воведува итен проблем: кога десет илјади корисници ќе пристапат до вашето име на домен, кој специфичен сервер го добива нивниот сообраќај? Балансерот на оптоварување делува како обратен прокси кој се наоѓа помеѓу јавниот интернет и вашиот приватен бекенд кластер. Прифаќа дојдовни TCP или HTTP конекции и ги дистрибуира барањата низ вашите здрави инстанци.

2:47 Балансерите на оптоварување работат на два примарни мрежни слоја. Мрежните балансери на оптоварување на слој 4 работат на транспортниот слој, рутирајќи сурови TCP и UDP пакети врз основа на IP адреса и порта со латентност во микросекунди и милиони барања во секунда. Балансерите на оптоварување на апликации на слој 7 го проверуваат HTTP протоколот самиот: читање URL патеки, заглавија на барања, колачиња и HTTP методи. Ова овозможува рутирање засновано на патеки: испраќање барања за /api до вашиот бекенд кластер и барања за /static до

3:25 складиште на објекти. Клучно, балансерите на оптоварување вршат активни здравствени проверки. На секои неколку секунди, балансерот пингува крајна точка за здравје на секоја инстанца. Ако инстанца фрли три последователни грешки од петстотини или не успее да одговори, таа автоматски се отстранува од базенот со нула отфрлени барања.

### - 03. Автоматско скалирање и еластичност

3:45 Концепт број три: Автоматско скалирање. Ако вашата веб апликација има потреба од два сервери во три часот наутро, но дваесет сервери за време на лансирање напладне, рачното кликање на копчиња во облачната конзола е загарантиран пат до застој и банкрот. Автоматското скалирање носи динамична еластичност на хоризонталните базени на сервери. Групата за автоматско скалирање ги следи метриките за перформанси како просечна искористеност на процесорот, мрежен I/O или длабочина на заостаната редица. Кога просечниот процесор ќе надмине одреден праг – да речеме,

4:19 седумдесет проценти за три последователни минути – автоматскиот скалер автоматски лансира нови виртуелни машини, ги регистрира со вашиот балансер на оптоварување, и почнува да рутира сообраќај. Подеднакво важно е скалирањето навнатре: кога бранот на сообраќај се повлекува, автоматскиот скалер ги прекинува вишокот инстанци за да престанете да плаќате за неактивна пресметка. За да се спречи треперење – каде што серверите брзо се создаваат и уништуваат во бескрајна јамка на тресење – облачните архитекти конфигурираат периоди на ладење. Концепт број четири: Безсерверно.

### - 04. Безсерверно (FaaS и Firecracker MicroVMs)

4:53 Со години, маркетинг тимовите го промовираа безсерверното како магичен код кој работи на небото. Во реалноста, безсерверното сè уште користи сервери – но вие не ги поседувате, не ги крпите, ниту пак плаќате за нив кога не работи никаков код. Со функција-како-услуга како AWS Lambda или Google Cloud Functions, пишувате самостојна функција за ракување. Кога ќе се случи HTTP барање, S3 поставување на датотека или промена во базата на податоци, облачното runtime подигнува ефемерна

5:23 микро-виртуелна машина како Firecracker за помалку од пет милисекунди. Вашиот код се извршува, враќа одговор и се исклучува. Ако никој не ја посети вашата веб-страница три месеци, вашата сметка за пресметување е точно нула долари и нула центи. Ако милион корисници ја посетат истовремено, провајдерот креира милион истовремени microVM-и. Инженерските компромиси се реални: латентност при ладен старт при подигнување нови runtime-и, тешко ограничување од петнаесет минути за извршување на Lambda и строга безсостојбеност.

5:55 Безсерверното е непобедливо за настани и спорадични API-и, но лошо за постојани WebSockets или повеќечасовни обуки.

### - 05. Архитектура водена од настани (EDA и одвојување)

6:05 Концепт број пет: Архитектура водена од настани, или EDA. Во традиционалните архитектури, услугите комуницираат синхроно. Вашата услуга за наплата повикува плаќање, плаќањето повикува инвентар, инвентарот повикува измама, а измамата повикува е-пошта. Ова ја создава синхроната каскада на пропаст. Ако провајдерот на е-пошта од трета страна доживее мрежен прекин и му требаат десет секунди да одговори, целото барање за наплата на вашиот клиент истекува со грешка. Во архитектурата водена од настани, услугите се целосно одвоени.

6:37 Кога клиент ќе кликне купи, услугата за наплата не повикува низводни услуги. Таа едноставно објавува настан наречен OrderPlaced на централен Автобус за настани како Amazon EventBridge или SNS тема. Наплатата завршува за педесет милисекунди. Низводните работници за плаќање, одземање на инвентар и сметки по е-пошта независно извлекуваат пораки од нивните посветени SQS редици. Ако услугата за е-пошта престане да работи еден час, пораките безбедно чекаат баферирани во редицата без ниту една отфрлена нарачка.

### - 06. Оркестрација на контејнери (Docker и Kubernetes)

7:13 Концепт број шест: Оркестрација на контејнери. Docker го реши пакувањето: го обвиткува вашиот апликативен код, системски библиотеки, конфигурација и runtime во непроменлива слика која работи идентично на вашиот MacBook и во облакот. Но, пакувањето на контејнер е лесно. Извршувањето на петстотини контејнери низ педесет физички виртуелни машини е местото каде што инженерството се распаѓа. Затоа постојат оркестратори на контејнери како Kubernetes и AWS ECS.

7:41 Оркестраторот обезбедува контролен авион: API сервер, etcd складиште на состојби и интелигентен распоредувач. Вие ја декларирате вашата посакувана состојба: Сакам десет реплики на мојата услуга за автентикација со по два гигабајти RAM меморија. Распоредувачот го проверува кластерот, поставува поди на јазли со слободна меморија, конфигурира внатрешно вмрежување и континуирано ја усогласува реалноста. Ако јазол претрпи хардверски дефект, Kubernetes го детектира загубата и веднаш ги прераспоредува сите поместени поди на

### - 07. 4-те столбови на облачно складирање (S3, EBS, DBs и Redis)

8:16 здрави јазли. Концепт број седум: Хиерархија на складирање во облак. Почетниците често го третираат облачното складирање како единствена корпа каде што фрлате датотеки. Во производната архитектура, складирањето е поделено на четири различни столбови врз основа на шемите на пристап и латентноста. Прво е Складирање на објекти, како Amazon S3 или Google Cloud Storage. Пристапувате до датотеки преку HTTP REST API со користење на едноставни PUT и GET повици. Нуди бесконечен хоризонтален капацитет по два центи по гигабајт месечно,

8:49 што го прави идеален за видео, кориснички поставувања, логови и резервни копии. Второ е Блок складирање, како Amazon EBS. Ова се виртуелни тврди дискови монтирани директно на специфична виртуелна машина преку брзи интерконекции. Тие се форматираат во стандардни датотечни системи како ext4, поддржувајќи брз случаен пристап за читање и пишување што е потребен од бази на податоци мотори. Трето се управувачки бази на податоци: релациони мотори како PostgreSQL на RDS кои обезбедуваат ACID трансакции и сложени спојувања,

9:21 и NoSQL мотори како DynamoDB кои испорачуваат едноцифрена милисекундна латентност на масивна скала. И четврто се кешови во меморија како Redis. Читањето податоци од RAM трае микросекунди наместо милисекунди. Кешовите се наоѓаат пред вашата база на податоци, штитејќи ја од повторен сообраќај за читање и управувајќи со нестабилни кориснички сесиски токени.

### - 08. Висока достапност и деветки (Multi-AZ Failover)

9:44 Концепт број осум: Висока достапност, или HA. Достапноста одговара на едно прашање: колкав процент од времето вашата апликација е оперативна и достапна за корисниците? Во договорите на претпријатијата, достапноста се мери во деветки. Две деветки, или деведесет и девет проценти достапност, дозволуваат повеќе од три и половина дена застој секоја година. Четири деветки го намалуваат дозволениот застој на педесет и две минути, а пет деветки дозволуваат едвај пет минути вкупен застој годишно.

10:15 За да постигнете висока достапност, мора да ги елиминирате единствените точки на дефект низ домените на дефект. Во облакот, тоа значи распоредување низ повеќе зони на достапност. Зона на достапност не е еден регал: тоа се еден или повеќе различни физички центри за податоци оддалечени километри со независно напојување и ладење. Со извршување на активни инстанци во Зона А и Зона Б со синхрона репликација на базата на податоци, удар на гром или прекин на влакно што ќе го исклучи целиот физички објект резултира со автоматски премин на други сервери.

10:50 за триесет секунди со нула човечка интервенција.

### - 09. Издржливост наспроти достапност (Зошто 11 деветки не е време на работа)

10:53 Концепт број девет: Издржливост наспроти Достапност. Ова е најчестата концептуална замка во интервјуата за cloud архитектура . Инженерите често ги користат зборовите наизменично, но тие мерат сосема различни својства. Достапноста мери работно време: дали можам да направам API повик за читање или запишување на моите податоци токму овој момент? Издржливоста мери зачувување: дали моите податоци ќе преживеат без трајно оштетување, корупција или уништување во текот на десет години?

11:24 Погледнете го Amazon S3 Standard. Неговиот Договор за ниво на услуга нуди деведесет и девет точка девет проценти достапност, што дозволува приближно четириесет и три минути прекин на работа секој месец каде API барањето може да врати грешка од петстотини. Но, S3 ветува единаесет деветки издржливост: деведесет и девет точка девет девет девет девет девет девет девет девет девет проценти. Ако складирате десет милиони датотеки во S3, статистички можете да очекувате да изгубите

11:56 просечно една датотека на секои десет илјади години. S3 го постигнува ова со објекти за кодирање на бришење и реплицирање на делови низ најмалку три географски одвоени центри за податоци. За време на голем регионален мрежен прекин, S3 може привремено да биде недостапен, но вашите податоци никогаш не се уништуваат.

### - 10. Инфраструктура како код (Terraform наспроти Console Drift)

12:14 Концепт број десет: Инфраструктура како Код, или IaC. Во раните денови на cloud компјутерите, инженерите се најавуваа на AWS веб-конзолата за управување и рачно кликнуваа наоколу за да создадат виртуелни машини, да конфигурираат подмрежи и да прикачат безбедносни групи. Индустријата ова го нарекува ClickOps, а во продукција, тоа е апсолутна катастрофа. Рачните промени на конзолата немаат запис за ревизија, нема механизам за враќање назад и неизбежно предизвикуваат промена на конфигурацијата помеѓу развојната и продукциската околина. Со алатките Инфраструктура

12:48 како Код како Terraform, OpenTofu, Pulumi или AWS CDK, вие ја дефинирате вашата целосна cloud архитектура во декларативни конфигурациски датотеки складирани во Git. Секоја промена на отворена порта или реплика на база на податоци поминува низ барање за повлекување и преглед од колеги. Стартувањето terraform plan го прегледува точниот API diff пред да се допре нешто, а подигнувањето на идентична реплика на вашиот продукциски стак трае четири минути наместо четири недели.

### - 11. Облачно вмрежување (VPC, подмрежи, NAT и безбедносни групи)

13:20 Концепт број единаесет: Cloud Networking и Виртуелни Приватни Облаци. Кога распоредувате сервери во cloud, тие не се изложени на суровиот јавен интернет. Тие живеат во граница дефинирана со софтвер наречена VPC. Внатре во вашиот VPC, вие доделувате приватен простор за IP адреси како десет точка нула точка нула точка нула коса црта шеснаесет, и го делите на јавни и приватни подмрежи. Јавната подмрежа има директна рута до Internet Gateway.

13:51 Таа содржи јавно достапни средства како што се вашите Application Load Balancers и NAT Gateways. Тоа е единствениот дел од вашата мрежа што поседува јавни IP адреси. Вашите апликациски сервери и продукциски бази на податоци живеат исклучиво во приватни подмрежи без јавни IP-адреси и нула влезни рути од интернетот. Кога вашите бекенд сервери треба да преземат безбедносни ажурирања, нивниот излезен сообраќај се насочува преку NAT Gateway во јавната подмрежа. Околу секоја инстанца се безбедносни групи: stateful виртуелни заштитни ѕидови кои го спроведуваат принципот на најмала привилегија.

### - 12. Комплетниот претпријатие-план и пресуда

14:28 Вашата безбедносна група на базата на податоци прифаќа врски само на портата 5432 строго од безбедносната група на вашите апликациски сервери, со што надворешното продирање е математички невозможно. Кога ќе се оддалечите, овие единаесет примитиви се поврзуваат во еден кохезивен систем. Вашиот DNS се насочува кон Load Balancer во јавна подмрежа, групите за автоматско скалирање се справуваат со напливи на сообраќај низ повеќе зони на достапност, автобусите за настани ги одвојуваат бекенд работниците, а целиот ваш стак е распореден од Git користејќи Infrastructure as Code.

15:02 Пресуда за денешната мастеркласа: SHIP IT. Престанете да меморирате стотици кратенки за cloud маркетинг. Овладете ги овие единаесет архитектонски шаблони, одвојте ја вашата состојба, и изградете системи што не можат да откажат. Кажете ми кој cloud концепт ви зададе најголема главоболка кога првпат почнавте да градите во коментарите. И за да го преземете комплетниот лист со измами за архитектура, претплатете се на билтенот на the daily diff dot dev,

15:28 линкот подолу. И тоа е разликата за денес. Јас сум Нико од Axrisi. Спојувајте одговорно.

## Извори

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