# Булуттагы эсептөө түшүндүрүлдү: сиз билишиңиз керек болгон 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/ky/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. Console Drift)
- 13:20 - 11. Булут тармагы (VPC, Subnets, NAT & Коопсуздук топтору)
- 14:26 - 12. Толук ишкананын планы жана өкүм

## Котормо стенограмма

Англис тилиндеги баштапкы баяндамадан которулган. Жеткиликтүү аудио жана коштомо жазуулар YouTube тарабынан көзөмөлдөнөт.

### - Архитектура дубалы жана башкы план

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

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

### - 01. Вертикалдык жана Горизонталдык масштабдоо

0:57 Биринчи концепция: Масштабдоо. Сиздин тиркемеңиз трафиктин өсүшүнө дуушар болгондо, сизде эки негизи бар жүктү башкаруунун ар кандай жолдору: вертикалдык масштабдоо же горизонталдык масштабдоо. Вертикалдык масштабдоо же өйдө масштабдоо сиздин учурдагы машинаңызды алып, көбүрөөк ресурстарды кошууну билдирет: төрттөн CPU өзөгүн отуз экиге чейин жаңыртуу же отуз эки гигабайт RAMды жүз жыйырма сегизге алмаштыруу. Вертикалдык масштабдоо нөлдүк архитектуралык өзгөрүүлөрдү талап кылат: сиздин кодуңуз

1:28 жана маалымат базасы дал ошондой бойдон калат. Бирок ал катаал аппараттык шыпка жетет. Дүйнөдө бир да машинада он миң CPU өзөгү жок, жана жогорку деңгээлдеги инстанциялар экспоненциалдык баа премиумуна ээ. Горизонталдык масштабдоо же сыртка масштабдоо сиздин серверлериңизди кичинекей жана арзан баада кармоону, бирок роутердин артында бир нече инстанцияны параллель иштетүүнү билдирет. Эгер бир инстанция иштен чыкса, калган түйүндөр трафикти нөлдүк токтоп калуу менен өзүнө сиңирип алат. Горизонталдык масштабдоонун алтын эрежеси - бул

2:01 абалы жоктук: сиздин тиркеме серверлериңиз колдонуучу сеанстарын, жүктөлгөн файлдарды же абалды жергиликтүү дисктеринде сактай албайт. Абал тышкы маалымат базасында же кэште жашашы керек, каалаган түйүнгө каалаган колдонуучу суроосун иштетүүгө мүмкүндүк берет.

### - 02. Жүктү баланстоо архитектурасы (L4 vs. L7 & Ден соолукту текшерүү)

2:17 Экинчи концепция: Жүктү баланстоо. Горизонталдык масштабдоо кагаз жүзүндө сонун угулат, бирок ал дароо бир көйгөйдү жаратат: он миң колдонуучу сиздин домен атыңызга киргенде, алардын трафигин кайсы сервер кабыл алат? Жүктү баланстоочу жалпы интернеттин ортосунда жайгашкан тескери прокси катары иштейт жана сиздин жеке бэкенд кластериңиз. Ал кирүүчү TCP же HTTP туташууларын кабыл алат жана суроо-талаптарды дени сак инстанцияларыңызга бөлүштүрөт.

2:47 Жүктү баланстоочулар эки негизги тармак деңгээлинде иштейт. Layer 4 Network Load Balancers транспорт деңгээлинде иштейт, IP дарек жана порт боюнча чийки TCP жана UDP пакеттерин маршрутизациялайт микросекунддук кечигүү жана секундасына миллиондогон суроо-талаптар менен. Layer 7 Application Load Balancers HTTP протоколун текшерет өзүн: URL жолдорун, суроо баштарын, кукилерди жана HTTP ыкмаларын окуу. Бул жолго негизделген маршрутизацияны иштетет: /api суроолорду бэкенд кластериңизге жана /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 файл жүктөө же маалымат базасынын өзгөрүшү пайда болгондо, булут иштөө убактысы ephemeral

5:23 Firecracker сыяктуу микро-виртуалдык машинаны беш миллисекунддун ичинде ишке киргизет. Сиздин кодуңуз аткарылат, жооп кайтарат жана өчүрүлөт. Эгер үч ай бою эч ким сиздин веб-сайтыңызга кирбесе, сиздин эсептөө эсебиңиз нөл доллар жана нөл цент болот. Эгер миллион колдонуучу бир эле учурда кирсе, провайдер миллион бир убактагы microVMди ишке киргизет. Инженердик компромисстер реалдуу: жаңы иштөө убакыттарын ишке киргизүүдөгү "муздак баштоо" кечигүүсү, Lambda'да он беш мүнөттүк катуу аткаруу чеги жана катуу абалы жоктук.

5:55 Серверсиз окуя конвейерлери жана спорадикалык APIлер үчүн теңдешсиз, бирок туруктуу WebSockets же көп сааттык окутуу үчүн начар.

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

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

6:37 Кардар сатып алуу баскычын басканда, текшерүү кызматы төмөнкү кызматтарды чакырбайт. Ал жөн гана Заказ жайгаштырылды деп аталган окуяны борбордук Amazon EventBridge же SNS темасы сыяктуу окуя автобусуна жарыялайт. Текшерүү элүү миллисекундда аяктайт. Төлөм, инвентаризацияны азайтуу жана электрондук почта квитанциялары үчүн төмөнкү жумушчулар кабарларды өзүнүн атайын SQS кезектеринен өз алдынча тартып алышат. Эгер электрондук почта кызматы бир саатка иштебей калса, кабарлар коопсуз бир дагы түшкөн заказсыз кезекте буферде күтөт.

### - 06. Контейнерди башкаруу (Docker & Kubernetes)

7:13 Алтынчы концепция: Контейнерди башкаруу. Docker таңгактоо маселесин чечти: ал сиздин тиркеме кодуңузду, системалык китепканаларды, конфигурацияны жана иштөө убактысын өзгөрүлгүс MacBookуңузда жана булутта бирдей иштеген сүрөткө ороп салат. Бирок контейнерди таңгактоо оңой. Элүү физикалык виртуалдык машина боюнча беш жүз контейнерди иштетүү инженерия иштен чыгат. Ошондуктан Kubernetes жана AWS ECS сыяктуу контейнер оркестраторлору

7:41 бар. Оркестратор башкаруу тегиздигин камсыз кылат: API серверин, etcd абал сактагычын жана интеллектуалдык пландоочуну. Сиз каалаган абалыңызды жарыялайсыз: мен өзүмдүн аутентификация кызматымдын он репликасын ар бири эки гигабайт RAM менен каалайм. Пландоочу кластерди текшерет, подкасттарды бош эс тутуму бар түйүндөргө жайгаштырат, ички тармакты конфигурациялайт жана реалдуулукту тынымсыз жөнгө салат. Эгер түйүн аппараттык камсыздоонун бузулушуна дуушар болсо, Kubernetes жоготууну аныктайт жана дароо бардык ордунан жылган подкасттарды дени сак

### - 07. 4 булут сактагыч түркүгү (S3, EBS, DBs & Redis)

8:16 түйүндөргө кайра пландоого мажбурлайт. Жетинчи концепция: Булут сактагыч иерархиясы. Жаңы баштагандар көбүнчө булут сактагычты файлдарды таштай турган бир челек катары карашат. Өндүрүш архитектурасында сактагыч жеткиликтүүлүк схемаларына жана кечигүүгө негизделген төрт өзүнчө түркүккө бөлүнөт. Биринчиси - Объект сактагыч, Amazon S3 же Google Cloud Сактагыч сыяктуу. Файлдарды HTTP REST API аркылуу жөнөкөй PUT жана GET чалууларын колдонуп жетишесиз. Ал айына гигабайтына эки центтен чексиз горизонталдык сыйымдуулукту сунуштайт,

8:49 аны видео, колдонуучу жүктөөлөрү, журналдар жана камдык көчүрмөлөр үчүн идеалдуу кылат. Экинчиси - Блок сактагыч, Amazon EBS сыяктуу. Бул жогорку ылдамдыктагы туташуулар аркылуу белгилүү бир виртуалдык машинага түздөн-түз орнотулган виртуалдык катуу дисктер. Алар ext4 сыяктуу стандарттуу файл системаларына форматташат, маалымат базасынын кыймылдаткычтары талап кылган тез туш келди окуу жана жазуу мүмкүнчүлүгүн колдойт. Үчүнчүсү - Башкарылуучу маалымат базалары: RDS'теги PostgreSQL сыяктуу реляциялык кыймылдаткычтар ACID транзакцияларын жана татаал бирикмелерди камсыз кылат,

9:21 жана DynamoDB сыяктуу NoSQL кыймылдаткычтары массалык масштабда бир орундуу миллисекунддук кечигүүнү камсыз кылат. Төртүнчүсү - Redis сыяктуу эс тутумдагы кэштер. RAMдан маалыматтарды окуу миллисекунд эмес, микросекунддарды талап кылат. Кэштер сиздин маалымат базаңыздын алдында жайгашып, аны кайталанган окуу трафигинен коргойт жана туруксуз колдонуучу сеанс токендерин башкарат.

### - 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. Console Drift)

12:14 Ончу түшүнүк: Инфраструктура код катары, же IaC. Булут эсептөөнүн алгачкы күндөрүндө, инженерлер AWS'ке кирип, веб башкаруу консолуна кирип, виртуалдык машиналарды түзүү, подтармактарды конфигурациялоо жана коопсуздук топторун тиркөө үчүн кол менен басышкан. виртуалдык машиналарды түзүү, подтармактарды конфигурациялоо жана коопсуздук топторун тиркөө үчүн кол менен басышкан. Өнөр жай муну ClickOps деп атайт, жана өндүрүштө бул абсолюттук кырсык. Кол менен жасалган консол өзгөрүүлөрүнүн аудит изи жок, артка кайтаруу механизми жок жана сөзсүз түрдө аралык жана өндүрүш чөйрөлөрүнүн ортосунда конфигурациянын айырмасын пайда кылат. Инфраструктура код катары Terraform сыяктуу куралдар менен,

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

### - 11. Булут тармагы (VPC, Subnets, NAT & Коопсуздук топтору)

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

13:51 Ал Сиздин Колдонмо Жүк Баланстоочуларыңыз жана NAT Шлюздарыңыз сыяктуу коомдук багытталган активдерди камтыйт. Шлюздар. Бул сиздин тармагыңыздын коомдук IP даректерине ээ болгон жалгыз бөлүгү. даректер. Сиздин колдонмо серверлериңиз жана өндүрүш маалымат базалары катуу жеке подтармактарда коомдук IP жок жана интернеттен келген нөлдүк кириш маршруттар менен жашайт. интернет. Сиздин бэкенд серверлериңиз коопсуздук жаңыртууларын жүктөп алуу үчүн, алардын чыгыш трафиги коомдук подтармактагы NAT шлюзу аркылуу багытталат. подтармак. Ар бир инстанцияны курчап турган Коопсуздук Топтору: мамлекеттик виртуалдык брандмауэрлер, алар эң аз артыкчылык принцибин ишке ашырат.

### - 12. Толук ишкананын планы жана өкүм

14:28 Сиздин маалымат базасынын коопсуздук тобу 5432 портундагы туташууларды 5432 портунда гана сиздин колдонмо серверлериңиздин коопсуздук тобунан гана кабыл алат, тышкы киришин математикалык жактан мүмкүн эмес кылат. Чоңойтуп караганда, бул он бир жөнөкөй элемент бирдиктүү системага биригет. Сиздин DNS коомдук подтармактагы Жүк Баланстоочуга багытталат, автомасштабдоо топтору бир нече Жеткиликтүүлүк зоналары боюнча трафик агымын жөнгө салат, окуя автобустары бэкенд жумушчуларын ажыратат, жана сиздин бүт стек Infrastructure as Code колдонуп, Git'тен жайгаштырылган.

15:02 Бүгүнкү мастер-класстын чечими: ЖИБЕРҮҮ. Жүздөгөн булут маркетингинин кыскартууларын жаттап алууну токтотуңуз. Бул он бир архитектуралык үлгүнү өздөштүрүңүз, абалыңызды ажыратыңыз, жана иштебей турган системаларды куруңуз. Биринчи баштаганда кайсы булут концепциясы сизге эң чоң баш ооруну бергенин комментарийлерде айтыңыз. курулуш комментарийлерде. Ал эми толук архитектуралык шпаргалканы алуу үчүн, 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