# Бұлтты есептеу түсіндірілді: сіз білуіңіз керек 11 архитектуралық концепция (4K Masterclass).

Published: 2026-09-15

Көптеген бағдарламалық жасақтама инженерлері AWS, GCP және Azure бойынша жүздеген жеткізуші өнімдерінің аббревиатураларын жаттау арқылы бұлтты архитектураны үйренуге тырысады. Бірақ нақты әлемдегі бұлтты инженерия он бір іргелі архитектуралық примитивтерге негізделген. Бұл 4K ремастер мастер-классында Нико кәсіпорынның толық жоспарын талдайды: тік және көлденең масштабтаудан және Layer 7 жүктеме баланстаудан динамикалық автоматты масштабтауға, серверсіз microVM орындауына, асинхронды оқиғаға негізделген ажыратуға, контейнер оркестрациясына, төрт тіректі сақтау иерархиясына, жоғары қолжетімділік пен 11 тоғыз беріктіктің арасындағы маңызды айырмашылыққа, Infrastructure as Code декларациясына және Virtual Private Cloud желісіне дейін. Осы он бір концепцияны меңгерсеңіз, кез келген бэкендті өндірісте жобалай аласыз. Үкім: SHIP IT.

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

## Бұл бейне не туралы

- - Сәулет қабырғасы және мастер-жоспар
- - 01. Тік және көлденең масштабтау
- - 02. Жүктемені теңестіру архитектурасы (L4 vs. L7 & Денсаулық тексерулері)
- - 03. Автоматты масштабтау және серпімділік
- - 04. Серверсіз (FaaS & Firecracker MicroVMs)

## Тараулар

- 0:00 - Сәулет қабырғасы және мастер-жоспар
- 0:57 - 01. Тік және көлденең масштабтау
- 2:17 - 02. Жүктемені теңестіру архитектурасы (L4 vs. 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 vs. Консоль дрейфі)
- 13:20 - 11. Бұлтты желі (VPC, Subnets, NAT & Қауіпсіздік топтары)
- 14:26 - 12. Толық кәсіпорын жоспары және үкім

## Аударылған транскрипция

Бастапқы ағылшын тіліндегі баяндамадан аударылған. Қолжетімді аудио және субтитрлерді YouTube басқарады.

### - Сәулет қабырғасы және мастер-жоспар

0:00 Әрбір бағдарламалық жасақтама инженері ақырында бұлтты архитектура қабырғасына тап болады. Сіз қолданбаны ноутбугіңізде құрастырасыз, оны өндіріске шығарасыз, және нақты пайдаланушылар келген сәтте серверлер істен шығады, дерекқор қосылымдары ағып кетеді, ал AWS шотыңыз телефон нөмірі сияқты болады. Көптеген әзірлеушілер бұлтты инженерияны үш жүз түрлі AWS өнім аббревиатураларын жаттау арқылы шешуге тырысады. Бірақ нақты бұлтты есептеу жеткізуші каталогтарын жаттау туралы емес: ол он бір іргелі архитектуралық примитивтерге негізделген.

0:34 Бұл мастер-класста біз кәсіпорынның барлық жоспарын қарастырамыз: масштабтау және жүктемені теңестіруден серверсіз, оқиғаға негізделген ажыратуға, сақтау иерархияларына және бұлтты желіге дейін. Осы он бір концепцияны меңгерсеңіз, кез келген бэкендті AWS, GCP немесе Azure-да жобалай аласыз. Бұл The Daily Diff, ішінде.

### - 01. Тік және көлденең масштабтау

0:57 Бірінші концепция: Масштабтау. Қолданбаңыз трафик өсімін бастан кешкенде, жүктемені өңдеудің екі іргелі түрлі әдісі бар: тік масштабтау немесе көлденең масштабтау. Тік масштабтау немесе кеңейту, бұл сіздің бар машинаңызды алып, оған көбірек ресурстар қосуды білдіреді: төрт CPU ядросынан отыз екіге дейін жаңарту немесе отыз екі гигабайт жедел жадыны жүз жиырма сегізге ауыстыру. Тік масштабтау нөл архитектуралық өзгерістерді қажет етеді: сіздің кодыңыз

1:28 мен дерекқорыңыз дәл солай қалады. Бірақ ол қатал аппараттық шектеуге жетеді. Әлемде ешбір машинада он мың CPU ядросы жоқ, және жоғары деңгейлі даналар экспоненциалды баға премиумын тасымалдайды. Көлденең масштабтау немесе кеңейту, бұл серверлеріңізді кішкентай және тауарлық бағада ұстауды, бірақ маршрутизатордың артында бірнеше дананы параллельді түрде іске қосуды білдіреді. Егер бір дана істен шықса, қалған түйіндер трафикті нөлдік тоқтап қалу уақытымен қабылдайды. Көлденең масштабтаудың алтын ережесі

2:01 статуссыздық: қолданба серверлеріңіз пайдаланушы сессияларын, жүктелген файлдарды немесе статусты жергілікті дискілерінде сақтай алмайды. Статус сыртқы дерекқорда немесе кэште сақталуы керек, кез келген түйін кез келген пайдаланушы сұранысын өңдеуге мүмкіндік береді.

### - 02. Жүктемені теңестіру архитектурасы (L4 vs. L7 & Денсаулық тексерулері)

2:17 Екінші концепция: Жүктемені теңестіру. Көлденең масштабтау қағазда жақсы естіледі, бірақ ол бірден проблема туғызады: он мың пайдаланушы домен атауыңызға кіргенде, олардың трафигін нақты қай сервер қабылдайды? Жүктеме теңестірушісі қоғамдық интернет пен сіздің жеке бэкенд кластеріңіздің арасында орналасқан кері прокси ретінде әрекет етеді. және сіздің жеке бэкенд кластеріңіздің арасында орналасқан кері прокси ретінде әрекет етеді. Ол кіріс TCP немесе HTTP қосылымдарын қабылдайды және сұраныстарды дені сау даналарыңызға таратады.

2:47 Жүктеме теңестірушілері екі негізгі желілік деңгейде жұмыс істейді. 4-деңгейлі Желілік Жүктеме Теңестірушілері транспорттық деңгейде жұмыс істейді, IP мекенжайы мен портқа негізделген шикі TCP және UDP пакеттерін маршруттау микросекундтық кідіріспен және секундына миллиондаған сұраныстармен. 7-деңгейлі Қолданба Жүктеме Теңестірушілері HTTP протоколын тексереді өзі: URL жолдарын, сұраныс тақырыптарын, кукилерді және HTTP әдістерін оқиды. Бұл жолға негізделген маршруттауды іске қосады: slash-api сұраныстарын бэкенд кластеріңізге және slash-static сұраныстарын объект

3:25 қоймасына жіберу. Ең бастысы, жүктеме теңестірушілері белсенді денсаулық тексерулерін орындайды. Әрбір бірнеше секунд сайын, теңестіруші әрбір данадағы денсаулық нүктесіне пинг жібереді. Егер дана қатарынан үш бес жүз қате жіберсе немесе жауап беруге қабілетсіз болса, ол автоматты түрде пулдан нөлдік тасталған сұраныстармен шығарылады.

### - 03. Автоматты масштабтау және серпімділік

3:45 Үшінші концепция: Автоматты масштабтау. Егер сіздің веб-қосымшаңызға таңғы сағат үште екі сервер қажет болса, бірақ түскі іске қосу кезінде жиырма сервер қажет болса, бұлтты консольда түймелерді қолмен басу тоқтап қалуға және банкроттыққа кепілдендірілген жол болып табылады. Автоматты масштабтау көлденең серверлік пулдарға динамикалық серпімділік әкеледі. Автоматты масштабтау тобы орташа CPU пайдалануы, желілік I-O немесе кезектегі тереңдік сияқты өнімділік көрсеткіштерін бақылайды. Орташа CPU белгіленген шектен өткенде — мысалы,

4:19 қатарынан үш минут бойы жетпіс пайыз — автоматты масштабтаушы автоматты түрде жаңа виртуалды машиналарды іске қосады, оларды жүктеме теңестірушіңізбен тіркейді, және трафикті маршруттауды бастайды. Масштабтау да бірдей маңызды: трафик толқыны қайтқанда, автоматты масштабтаушы артық даналарды тоқтатады, сондықтан сіз бос есептеу үшін төлеуді тоқтатасыз. Флэппингті болдырмау үшін — мұнда серверлер тез жасалады және шексіз дүрбелең циклінде жойылады — бұлтты сәулетшілер салқындату кезеңдерін конфигурациялайды. Төртінші концепция: Серверсіз.

### - 04. Серверсіз (FaaS & Firecracker MicroVMs)

4:53 Жылдар бойы маркетинг командалары серверсізді аспанда жұмыс істейтін сиқырлы код ретінде насихаттады. Шын мәнінде, серверсіз әлі де серверлерді пайдаланады — бірақ сіз оларды иеленбейсіз, патч жасамайсыз немесе ешқандай код жұмыс істемеген кезде төлемейсіз. AWS Lambda немесе Google Cloud Functions сияқты Function-as-a-Service арқылы, сіз дербес өңдегіш функцияны жазасыз. HTTP сұранысы, S3 файл жүктеуі немесе дерекқор өзгерісі болғанда, бұлтты орындалу уақыты бес миллисекундтан аз уақытта Firecracker сияқты

5:23 уақытша микро-виртуалды машинаны іске қосады. Сіздің кодыңыз орындалады, жауап қайтарады және өшеді. Егер үш ай бойы ешкім сіздің веб-сайтыңызға кірмесе, сіздің есептеу шотыңыз дәл нөл доллар және нөл цент болады. Егер миллион пайдаланушы бір уақытта кірсе, провайдер миллион қатарлас microVM іске қосады. Инженерлік ымыралар нақты: жаңа орындалу уақыттарын іске қосқан кезде суық бастау кідірісі, Lambda-да он бес минуттық қатаң орындалу шектеуі және қатаң статуссыздық.

5:55 Серверсіз оқиға құбырлары мен спорадикалық API үшін теңдессіз, бірақ тұрақты WebSockets немесе бірнеше сағаттық оқыту үшін нашар.

### - 05. Оқиғаға негізделген архитектура (EDA & Ажырату)

6:05 Бесінші концепция: Оқиғаға негізделген архитектура немесе EDA. Дәстүрлі архитектураларда қызметтер синхронды түрде байланысады. Сіздің төлем қызметіңіз төлемге қоңырау шалады, төлем инвентаризацияға қоңырау шалады, инвентаризация алаяқтыққа қоңырау шалады, ал алаяқтық электрондық поштаға қоңырау шалады. Бұл синхронды апат каскадын тудырады. Егер үшінші тарап электрондық пошта провайдері желілік іркіліске тап болып, он секунд жауап берсе, сіздің тұтынушыңыздың бүкіл төлем сұранысы қатемен уақытынан асып кетеді. Оқиғаға негізделген архитектурада қызметтер толығымен ажыратылған.

6:37 Тұтынушы сатып алу түймесін басқанда, төлем қызметі төменгі деңгейдегі қызметтерге қоңырау шалмайды. Ол жай ғана OrderPlaced деп аталатын оқиғаны орталық Event Bus сияқты Amazon EventBridge немесе SNS тақырыбына жариялайды. Төлем елу миллисекундта аяқталады. Төлем, инвентаризацияны азайту және электрондық пошта түбіртектері үшін төменгі деңгейдегі жұмысшылар хабарламаларды өздерінің арнайы SQS кезектерінен тәуелсіз тартады. Егер электрондық пошта қызметі бір сағатқа тоқтап қалса, хабарламалар кезекте қауіпсіз буферленген күйде бірде-бір жоғалған тапсырыссыз күтеді.

### - 06. Контейнер оркестрациясы (Docker & Kubernetes)

7:13 Алтыншы концепция: Контейнер оркестрациясы. Docker пакеттеуді шешті: ол сіздің қолданба кодыңызды, жүйелік кітапханаларды, конфигурацияны және орындалу уақытын өзгермейтін кескінге орайды, ол сіздің MacBook-да және бұлтта бірдей жұмыс істейді. Бірақ контейнерді орау оңай. Елу физикалық виртуалды машинада бес жүз контейнерді іске қосу инженерия істен шығатын жер. Сондықтан Kubernetes және AWS ECS сияқты контейнер оркестраторлары

7:41 бар. Оркестратор басқару панелін қамтамасыз етеді: API сервері, etcd жағдай қоймасы және интеллектуалды жоспарлаушы. Сіз қалаған жағдайыңызды жариялайсыз: менің аутентификация қызметімнің он репликасын қалаймын, әрқайсысы екі гигабайт жедел жадымен. Жоспарлаушы кластерді тексереді, бос жады бар түйіндерге подтарды орналастырады, ішкі желіні конфигурациялайды және шындықты үздіксіз келістіреді. Егер түйін аппараттық ақаулыққа ұшыраса, 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 және DynamoDB сияқты NoSQL қозғалтқыштары бір таңбалы миллисекундтық кідірісті үлкен масштабта қамтамасыз етеді. Төртіншісі Redis сияқты Жедел жады кэштері. Жедел жадыдан деректерді оқу миллисекундтар емес, микросекундтарды алады. Кэштер дерекқорыңыздың алдында орналасып, оны қайталанатын оқу трафигінен қорғайды және құбылмалы пайдаланушы сессиясы токендерін басқарады.

### - 08. Жоғары қолжетімділік және тоғыздар (Multi-AZ Failover)

9:44 Сегізінші концепция: Жоғары қолжетімділік немесе HA. Қолжетімділік бір сұраққа жауап береді: сіздің қолданбаңыз қанша уақыт жұмыс істеп, пайдаланушыларға қолжетімді болады? Кәсіпорын келісімшарттарында қолжетімділік тоғыздармен өлшенеді. Екі тоғыз немесе тоқсан тоғыз пайыз қолжетімділік жылына үш жарым күннен астам тоқтап қалуға мүмкіндік береді. Төрт тоғыз рұқсат етілген тоқтап қалу уақытын елу екі минутқа дейін азайтады, ал бес тоғыз жылына бес минуттан аз толық тоқтап қалуға рұқсат береді.

10:15 Жоғары қолжетімділікке қол жеткізу үшін ақаулық домендері бойынша бір нүктелік істен шығуларды жоюыңыз керек. ақаулық домендері бойынша бір нүктелік істен шығуларды жоюыңыз керек. Бұлтта бұл бірнеше қолжетімділік аймақтарына орналастыруды білдіреді. Қолжетімділік аймағы бір жеке тірек емес: ол бір немесе одан да көп бір-бірінен миль қашықтықта орналасқан бөлек физикалық деректер орталықтары, олардың қуаты мен салқындату жүйелері тәуелсіз. Аймақ А және Аймақ В-да синхронды дерекқор репликациясымен белсенді даналарды іске қосу арқылы, найзағай соққысы немесе талшық үзілуі бүкіл физикалық нысанды істен шығарса, автоматтандырылған ауысуға әкеледі.

10:50 отыз секундта ешқандай адам араласуынсыз.

### - 09. Беріктік пен қолжетімділік (Неліктен 11 тоғыз жұмыс уақыты емес)

10:53 Тоғызыншы концепция: Төзімділік пен Қолжетімділік. Бұл бұлтты архитектура сұхбаттарындағы ең көп кездесетін тұзақ инженерлер сөздерді жиі өзара алмастырады, бірақ олар мүлдем басқа қасиеттерді өлшейді. Қолжетімділік жұмыс уақытын өлшейді: мен қазір деректерді оқу немесе жазу үшін API шақыруын жасай аламын ба? Деректерді дәл қазір оқи немесе жаза аламын ба? Төзімділік сақтауды өлшейді: менің деректерім он жыл ішінде тұрақты бит шіруінен, бұзылудан немесе жойылудан аман қала ма? он жыл ішінде бит бұзылуынан, зақымданудан немесе жойылудан аман қала ма?

11:24 Amazon S3 Standard-қа қараңыз. Оның Қызмет көрсету деңгейі туралы келісімі тоқсан тоғыз бүтін тоғыз пайызды ұсынады қолжетімділік, бұл айына шамамен қырық үш минуттық тоқтап қалуға мүмкіндік береді мұнда API сұрауы бес жүз қатесін қайтаруы мүмкін. Бірақ S3 он бір тоғыз төзімділікті уәде етеді: тоқсан тоғыз бүтін тоғыз тоғыз тоғыз тоғыз тоғыз тоғыз тоғыз тоғыз тоғыз тоғыз тоғыз пайыз. Егер сіз S3-те он миллион файлды сақтасаңыз, сіз статистикалық тұрғыдан әрбір он мың жылда бір файлды жоғалтуды күте аласыз.

11:56 әрбір он мың жылда бір файлды жоғалтуды күте аласыз. S3 бұған объектілерді өшіру кодтауы және кем дегенде үш географиялық бөлінген деректер орталығында блоктарды репликациялау арқылы қол жеткізеді. кем дегенде үш географиялық бөлінген деректер орталығы арқылы блоктарды репликациялау арқылы қол жеткізеді. Үлкен аймақтық желі істен шыққан кезде, S3 уақытша қолжетімсіз болуы мүмкін, бірақ сіздің деректеріңіз ешқашан жойылмайды.

### - 10. Код ретіндегі инфрақұрылым (Terraform vs. Консоль дрейфі)

12:14 Оныншы концепция: Код ретіндегі инфрақұрылым, немесе IaC. Бұлттық есептеулердің алғашқы күндерінде инженерлер AWS веб-басқару консоліне кіріп, веб-басқару консоліне кіріп, виртуалды машиналарды жасау үшін қолмен шертіп, жеке желілерді конфигурациялап, қауіпсіздік топтарын тіркеді. Индустрия мұны ClickOps деп атайды, және өндірісте бұл нағыз апат. Қолмен консоль өзгерістерінің бақылау жолы, кері қайтару механизмі жоқ, және сөзсіз сахналық және өндірістік орталар арасында конфигурацияның ығысуына әкеледі. Код ретіндегі инфрақұрылым құралдарымен

12:48 Terraform, OpenTofu, Pulumi немесе AWS CDK сияқты құралдармен, OpenTofu, Pulumi немесе AWS CDK сияқты құралдармен сіз бүкіл бұлттық архитектураңызды Git-те сақталған декларативті конфигурация файлдарында анықтайсыз. Ашық портқа немесе дерекқор репликасына жасалған әрбір өзгеріс тарту сұрауы мен тең құрбыларды тексеруден өтеді. тарту сұрауы және тең құрбыларды тексеру арқылы өтеді. terraform plan іске қосу кез келген нәрсеге қол тигізбес бұрын нақты API айырмашылығын алдын ала көрсетеді, және сіздің өндірістік стекіңіздің бірдей репликасын іске қосу төрт апта емес, төрт минутты алады. төрт минутты алады.

### - 11. Бұлтты желі (VPC, Subnets, NAT & Қауіпсіздік топтары)

13:20 Он бірінші концепция: Бұлтты желі және виртуалды жеке бұлттар. Серверлерді бұлтқа орналастырған кезде, олар бастапқы ашық интернетте ашық отырмайды. Олар VPC деп аталатын бағдарламалық қамтамасыз етумен анықталған оқшауланған шекараның ішінде өмір сүреді. VPC деп аталатын бағдарламалық қамтамасыз етумен анықталған оқшауланған шекараның ішінде өмір сүреді. Сіздің VPC ішінде сіз жеке IP мекенжай кеңістігін бөлесіз, он-нүкте-нөл-нүкте-нөл-нүкте-нөл қиғаш он алты сияқты, және оны ашық және жеке ішкі желілерге бөлесіз. ашық және жеке ішкі желілерге бөлесіз. Ашық ішкі желінің Интернет шлюзіне тікелей бағыты бар.

13:51 Ол сіздің қолданбалы жүктеме теңгерімдегіштеріңіз және NAT шлюздері сияқты ашық активтерді ұстайды. Ол сіздің желіңіздің тек ашық IP мекенжайлары бар бөлігі. Сіздің қолданбалы серверлеріңіз және өндірістік дерекқорларыңыз интернеттен кіріс бағыттары нөлдік және ашық IP-лері жоқ жеке ішкі желілерде қатаң түрде орналасқан. интернеттен кіріс бағыттары нөлдік және ашық IP-лері жоқ жеке ішкі желілерде қатаң түрде орналасқан. Сіздің бэкэнд серверлеріңіз қауіпсіздік жаңартуларын жүктеп алуы қажет болғанда, олардың шығыс трафигі ашық ішкі желідегі NAT шлюзі арқылы бағытталады. Әрбір инстанцияны қауіпсіздік топтары қоршайды: ең аз артықшылық принципін орындайтын күйлі виртуалды брандмауэрлер. ең аз артықшылық принципін орындайтын күйлі виртуалды брандмауэрлер.

### - 12. Толық кәсіпорын жоспары және үкім

14:28 Сіздің дерекқор қауіпсіздік тобы 5432 портында тек сіздің қолданбалы серверлеріңіздің қауіпсіздік тобынан қосылымдарды ғана қабылдайды, бұл сыртқы енуді математикалық тұрғыдан мүмкін емес етеді. қосылымдарды ғана қабылдайды, бұл сыртқы енуді математикалық тұрғыдан мүмкін емес етеді. Масштабты кішірейткенде, осы он бір қарабайыр құрылым бір тұтас жүйеге бірігеді. Сіздің DNS ашық ішкі желідегі жүктеме теңгерімдегішке бағытталады, автоматты масштабтау топтары бірнеше қолжетімділік аймақтары бойынша трафик толқындарын өңдейді, оқиғалық шиналар бэкэнд жұмысшыларын ажыратады, және сіздің бүкіл стекіңіз Git-тен Код ретіндегі инфрақұрылым арқылы орналастырылады. Git арқылы Код ретіндегі инфрақұрылым арқылы орналастырылады.

15:02 Бүгінгі мастер-класс үкімі: SHIP IT. Жүздеген бұлттық маркетингтік аббревиатураларды жаттауды тоқтатыңыз. Осы он бір архитектуралық үлгіні меңгеріңіз, күйіңізді ажыратыңыз, және істен шықпайтын жүйелер құрыңыз. Алғаш рет құрылыс бастаған кезде қай бұлттық концепция сізге ең көп бас ауруын тудырғанын түсініктемелерде айтыңыз. түсініктемелерде айтыңыз. Ал толық архитектуралық алдау парағын алу үшін, The Daily Diff.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