# Bulud hesablamaları izah edildi: bilməli olduğunuz 11 arxitektura konsepsiyası (4K Master-klass).

Published: 2026-09-15

Əksər proqram mühəndisləri AWS, GCP və Azure-da yüzlərlə satıcı məhsulunun akronimlərini əzbərləyərək bulud arxitekturasını öyrənməyə çalışırlar. Lakin real dünyada bulud mühəndisliyi on bir əsas arxitektura primitivinə əsaslanır. Bu 4K remaster master-klassında Niko tam müəssisə planını təhlil edir: şaquli və üfüqi miqyaslamadan və Layer 7 yükləmə balanslaşdırmasından dinamik avtomatik miqyaslamaya, serverless microVM icrasına, asinxron hadisə-idarəli ayrışmaya, konteyner orkestrasiyasına, dörd sütunlu saxlama iyerarxiyasına, yüksək əlçatanlıq və 11 doqquz davamlılıq arasındakı kritik fərqə, deklarativ Kod kimi İnfrastrukturaya və Virtual Şəxsi Bulud şəbəkəsinə qədər. Bu on bir konsepsiyanı mənimsəyin və siz istehsalda istənilən backendi qura bilərsiniz. Hökm: SHIP IT.

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

## Bu videoda nələr əhatə olunur

- - Arxitektura Divarı və Əsas Plan
- - 01. Şaquli vs. Üfüqi Miqyaslama
- - 02. Yükləmə Balanslaşdırma Arxitekturası (L4 vs. L7 və Sağlamlıq Yoxlamaları)
- - 03. Avtomatik Miqyaslama və Elastiklik
- - 04. Serverless (FaaS və Firecracker MicroVM-lər)

## Fəsillər

- 0:00 - Arxitektura Divarı və Əsas Plan
- 0:57 - 01. Şaquli vs. Üfüqi Miqyaslama
- 2:17 - 02. Yükləmə Balanslaşdırma Arxitekturası (L4 vs. L7 və Sağlamlıq Yoxlamaları)
- 3:45 - 03. Avtomatik Miqyaslama və Elastiklik
- 4:50 - 04. Serverless (FaaS və Firecracker MicroVM-lər)
- 6:05 - 05. Hadisə-idarəli Arxitektura (EDA və Ayrışma)
- 7:13 - 06. Konteyner Orkestrasiyası (Docker və Kubernetes)
- 8:16 - 07. 4 Bulud Saxlama Sütunu (S3, EBS, DB-lər və Redis)
- 9:44 - 08. Yüksək Əlçatanlıq və Doqquzlar (Çoxlu-AZ Failover)
- 10:53 - 09. Davamlılıq vs. Əlçatanlıq (Niyə 11 Doqquz Uptime Deyil)
- 12:14 - 10. Kod kimi İnfrastruktura (Terraform vs. Konsol Dəyişikliyi)
- 13:20 - 11. Bulud Şəbəkəsi (VPC, Subnet-lər, NAT və Təhlükəsizlik Qrupları)
- 14:26 - 12. Tam Müəssisə Planı və Hökm

## Tərcümə olunmuş transkript

Orijinal ingilis dilindəki nəqldən tərcümə edilmişdir. Mövcud audio və subtitrlər YouTube tərəfindən idarə olunur.

### - Arxitektura Divarı və Əsas Plan

0:00 Hər proqram mühəndisi sonda bulud arxitekturası divarı ilə üzləşir. Siz noutbukunuzda bir proqram qurursunuz, onu istehsala göndərirsiniz, və real istifadəçilər gələn an, serverlər çökür, verilənlər bazası bağlantıları tükənir və AWS hesabınız bir telefon nömrəsi kimi görünür. Əksər tərtibatçılar bulud mühəndisliyini üç yüz müxtəlif AWS məhsulu akronimini əzbərləməklə həll etməyə çalışırlar. Lakin real bulud hesablaması satıcı kataloqlarını əzbərləməkdən ibarət deyil: o, on bir fundamental arxitektura primitivinə əsaslanır.

0:34 Bu master-klassda biz bütün müəssisə planını nəzərdən keçirəcəyik: miqyaslaşmadan və yükləmə balanslaşdırmadan serverless, hadisə-idarəli ayrışmaya, saxlama iyerarxiyalarına və bulud şəbəkəsinə qədər. Bu on bir konsepsiyanı mənimsəyin və siz AWS, GCP və ya Azure-da istənilən backendi dizayn edə bilərsiniz. Bu, The Daily Diff, pərdə arxasında.

### - 01. Şaquli vs. Üfüqi Miqyaslama

0:57 Birinci Konsepsiya: Miqyaslaşma. Proqramınız trafik artımı yaşadığında, yükü idarə etmək üçün iki fundamental fərqli yolunuz var: şaquli miqyaslaşma və ya üfüqi miqyaslaşma. Şaquli miqyaslaşma, yəni miqyası artırmaq, mövcud maşınınızı götürüb daha çox resurs əlavə etmək deməkdir: dörd CPU nüvəsindən otuz iki-yə yüksəltmək və ya otuz iki gigabayt RAM-ı yüz iyirmi səkkizlə dəyişmək. Şaquli miqyaslaşma sıfır arxitektura dəyişikliyi tələb edir: kodunuz

1:28 və verilənlər bazanız tamamilə eyni qalır. Lakin bu, qəddar bir aparat tavanına çatır. Dünyada heç bir tək maşının on min CPU nüvəsi yoxdur, və yüksək səviyyəli instansiyalar eksponensial qiymət premiumu daşıyır. Üfüqi miqyaslaşma, yəni miqyası genişləndirmək, serverlərinizi kiçik və adi qiymətdə saxlamaq, lakin bir routerin arxasında paralel olaraq bir neçə instansiyanı işə salmaq deməkdir. Əgər bir instansiya çöksə, qalan düyünlər sıfır dayanma müddəti ilə trafiki mənimsəyir. Üfüqi miqyaslaşmanın qızıl qaydası

2:01 statelessness-dir: proqram serverləriniz istifadəçi seanslarını, yüklənmiş faylları və ya vəziyyəti yerli disklərində saxlaya bilməz. Vəziyyət xarici verilənlər bazasında və ya keşdə yaşamalıdır, hər hansı bir düyünə istənilən istifadəçi tələbini idarə etməyə imkan verir.

### - 02. Yükləmə Balanslaşdırma Arxitekturası (L4 vs. L7 və Sağlamlıq Yoxlamaları)

2:17 İkinci Konsepsiya: Yükləmə Balanslaşdırma. Üfüqi miqyaslaşma kağız üzərində əla səslənir, lakin dərhal bir problem yaradır: on min istifadəçi sizin domen adınıza daxil olduqda, onların trafikini hansı konkret server qəbul edir? Yükləmə balanslaşdırıcısı ictimai internet və sizin şəxsi backend klasteriniz arasında yerləşən əks proxy kimi çıxış edir. və sizin şəxsi backend klasteriniz arasında yerləşən əks proxy kimi çıxış edir. O, gələn TCP və ya HTTP bağlantılarını qəbul edir və tələbləri sağlam instansiyalarınız arasında paylayır.

2:47 Yükləmə balanslaşdırıcıları iki əsas şəbəkə qatında fəaliyyət göstərir. Layer 4 Şəbəkə Yükləmə Balanslaşdırıcıları nəqliyyat qatında fəaliyyət göstərir, IP ünvanı və port əsasında xam TCP və UDP paketlərini marşrutlaşdırır mikrosaniyə gecikməsi və saniyədə milyonlarla tələblə. Layer 7 Tətbiq Yükləmə Balanslaşdırıcıları HTTP protokolunun özünü yoxlayır: URL yollarını, tələb başlıqlarını, kukiləri və HTTP metodlarını oxuyur. Bu, yol əsaslı marşrutlaşdırmaya imkan verir: slash-api tələblərini sizin backend klasterinizə və slash-static tələblərini bir

3:25 obyekt yaddaşına göndərir. Əsas odur ki, yükləmə balanslaşdırıcıları aktiv sağlamlıq yoxlamaları aparır. Hər bir neçə saniyədən bir, balanslaşdırıcı hər bir instansiyada sağlamlıq son nöqtəsinə ping göndərir. Əgər bir instansiya ardıcıl üç beş yüz səhv verərsə və ya cavab verməzsə, o, avtomatik olaraq havuzdan sıfır itirilmiş tələblə çıxarılır.

### - 03. Avtomatik Miqyaslama və Elastiklik

3:45 Üçüncü Konsepsiya: Avtomatik Miqyaslaşma. Əgər veb proqramınıza səhər saat üçdə iki server lazımdırsa, lakin günorta başlatma zamanı iyirmi server lazımdırsa, bulud konsolunda düymələri əllə basmaq dayanma müddətinə və iflasa aparan zəmanətli yoldur. Avtomatik miqyaslaşma üfüqi server hovuzlarına dinamik elastiklik gətirir. Avtomatik Miqyaslama Qrupu orta CPU istifadəsi, şəbəkə I-O və ya növbə yığılması dərinliyi kimi performans metrikalarını izləyir. Orta CPU müəyyən edilmiş bir həddi — məsələn,

4:19 ardıcıl üç dəqiqə ərzində yetmiş faizi keçdikdə — avtomatik miqyaslandırıcı avtomatik olaraq yeni virtual maşınları işə salır, onları yükləmə balanslaşdırıcınızla qeydiyyatdan keçirir, və trafikin yönləndirilməsinə başlayır. Eyni dərəcədə vacibdir ki, miqyası kiçiltmək: trafik dalğası azaldıqda, avtomatik miqyaslandırıcı artıq instansiyaları dayandırır ki, boş hesablamaya pul ödəməyəsiniz. Çırpınmağı — serverlərin sürətlə yaradıldığı və sonsuz bir dövrdə məhv edildiyi halları — qarşısını almaq üçün bulud arxitektorları soyuq dövrlər konfiqurasiya edirlər. Dördüncü Konsepsiya: Serverless.

### - 04. Serverless (FaaS və Firecracker MicroVM-lər)

4:53 İllərdir marketinq komandaları serverless-i göydə işləyən sehrli kod kimi təqdim edirdilər. göydə işləyən sehrli kod kimi təqdim edirdilər. Əslində, serverless hələ də serverlərdən istifadə edir — lakin siz onlara sahib olmursunuz, yamalarını quraşdırmırsınız və ya heç bir kod işləməyəndə onlara pul ödəməyirsiniz. AWS Lambda və ya Google Cloud Functions kimi Funksiya-kimi-Xidmət ilə, siz müstəqil bir işləyici funksiya yazırsınız. Bir HTTP tələbi, S3 fayl yükləməsi və ya verilənlər bazası dəyişikliyi baş verdikdə, bulud runtime ephemeral

5:23 Firecracker kimi mikro-virtual-maşını beş millisaniyədən az müddətdə işə salır. Kodunuz icra olunur, cavab verir və bağlanır. Əgər üç ay ərzində heç kim veb saytınızı ziyarət etməzsə, hesablama faturanız tamamilə sıfır dollar və sıfır sentdir. Əgər bir milyon istifadəçi eyni vaxtda ona daxil olarsa, provayder bir milyon eyni vaxtda mikroVM işə salır. Mühəndislik kompromisləri realdır: təzə runtime-lar işə salınarkən soyuq başlanğıc gecikməsi, Lambdada sərt on beş dəqiqəlik icra limiti və ciddi statelessness.

5:55 Serverless hadisə boru kəmərləri və sporadik API-lər üçün rəqibsizdir, lakin davamlı WebSockets və ya çox saatlıq təlim işləri üçün zəifdir.

### - 05. Hadisə-idarəli Arxitektura (EDA və Ayrışma)

6:05 Beşinci Konsepsiya: Hadisə-idarəli Arxitektura, və ya EDA. Ənənəvi arxitekturalarda xidmətlər sinxron şəkildə əlaqə qurur. Sizin ödəniş xidmətiniz ödənişi çağırır, ödəniş inventarı çağırır, inventar fırıldaqçılığı çağırır və fırıldaqçılıq e-poçtu çağırır. Bu, qiyamətin sinxron kaskadını yaradır. Əgər üçüncü tərəf e-poçt provayderi şəbəkə kəsintisi yaşayarsa və cavab vermək üçün on saniyə çəkərsə, müştərinizin bütün ödəniş tələbi bir səhvlə vaxtaşırı başa çatır. Hadisə-idarəli arxitekturada xidmətlər tamamilə ayrılmışdır.

6:37 Müştəri almaq düyməsini basdıqda, ödəniş xidməti aşağı axın xidmətlərini çağırmır. O, sadəcə olaraq Mərkəzi Hadisə Avtobusuna (Amazon EventBridge və ya SNS mövzusu kimi) OrderPlaced adlı bir hadisə yayımlayır. Event Bus kimi Amazon EventBridge və ya bir SNS mövzusu kimi bir hadisə yayımlayır. Ödəniş əlli millisaniyədə tamamlanır. Ödəniş, inventar çıxarılması və e-poçt qəbzləri üçün aşağı axın işçiləri özlərinin xüsusi SQS növbələrindən müstəqil olaraq mesajları çəkirlər. Əgər e-poçt xidməti bir saat ərzində dayanarsa, mesajlar təhlükəsiz şəkildə növbədə heç bir itirilmiş sifariş olmadan saxlanılır.

### - 06. Konteyner Orkestrasiyası (Docker və Kubernetes)

7:13 Altıncı Konsepsiya: Konteyner Orkestrasiyası. Docker qablaşdırmanı həll etdi: o, sizin tətbiq kodunuzu, sistem kitabxanalarını, konfiqurasiyanı və runtime-ı dəyişməz bir şəkilə bükür ki, bu da MacBook-unuzda və buludda eyni şəkildə işləyir. Lakin bir konteyner qablaşdırmaq asandır. Əlli fiziki virtual maşın üzərində beş yüz konteyner işlətmək mühəndisliyin çökdüyü yerdir. Buna görə də Kubernetes və AWS ECS kimi konteyner orkestratorları

7:41 mövcuddur. Bir orkestrator bir nəzarət müstəvisi təmin edir: bir API server, bir etcd vəziyyət yaddaşı və ağıllı bir planlayıcı. Siz istədiyiniz vəziyyəti elan edirsiniz: mən auth xidmətimin on replikasını istəyirəm, hər biri iki gigabayt RAM ilə. Planlayıcı klasteri yoxlayır, podları boş yaddaşlı düyünlərə yerləşdirir, daxili şəbəkəni konfiqurasiya edir və reallığı davamlı olaraq uyğunlaşdırır. Əgər bir düyün aparat nasazlığı yaşayarsa, Kubernetes itkini aşkar edir və dərhal bütün yerindən tərpənmiş podları

### - 07. 4 Bulud Saxlama Sütunu (S3, EBS, DB-lər və Redis)

8:16 sağlam düyünlərə yenidən planlaşdırır. Yeddinci Konsepsiya: Bulud Saxlama İyerarxiyası. Başlayanlar çox vaxt bulud yaddaşını faylları atdığınız tək bir qutu kimi qəbul edirlər. İstehsal arxitekturasında yaddaş giriş modellərinə və gecikməyə əsasən dörd fərqli sütuna bölünür. Birincisi Obyekt Saxlama, Amazon S3 və ya Google Cloud Storage kimi. Fayllara HTTP REST API-ləri vasitəsilə sadə PUT və GET çağırışları ilə daxil olursunuz. O, hər ay hər gigabayt üçün iki sentə sonsuz üfüqi tutum təklif edir,

8:49 bu da onu video, istifadəçi yükləmələri, jurnallar və ehtiyat nüsxələri üçün ideal edir. İkincisi Blok Saxlama, Amazon EBS kimi. Bunlar yüksək sürətli bağlantılar vasitəsilə birbaşa müəyyən bir virtual maşına quraşdırılmış virtual sərt disklərdir. Onlar ext4 kimi standart fayl sistemlərinə formatlanır, verilənlər bazası mühərrikləri tərəfindən tələb olunan sürətli təsadüfi oxu və yazma girişini dəstəkləyir. Üçüncüsü İdarə olunan Verilənlər Bazalarıdır: RDS üzərində PostgreSQL kimi əlaqəli mühərriklər ACID əməliyyatları və kompleks birləşmələr təmin edir,

9:21 və DynamoDB kimi NoSQL mühərrikləri tək rəqəmli millisaniyə gecikməsi kütləvi miqyasda təmin edir. Və dördüncüsü Redis kimi Yaddaş Keşləridir. RAM-dan məlumat oxumaq millisaniyələr əvəzinə mikrosaniyələr çəkir. Keşlər verilənlər bazanızın qarşısında yerləşir, onu təkrarlanan oxu trafikindən qoruyur və dəyişkən istifadəçi seansı tokenlərini idarə edir.

### - 08. Yüksək Əlçatanlıq və Doqquzlar (Çoxlu-AZ Failover)

9:44 Səkkizinci Konsepsiya: Yüksək Əlçatanlıq, və ya HA. Əlçatanlıq bir suala cavab verir: proqramınızın nə qədər vaxtı işləkdir və istifadəçilər tərəfindən əlçatandır? Müəssisə müqavilələrində əlçatanlıq doqquzlarla ölçülür. İki doqquz, yəni doxsan doqquz faiz əlçatanlıq, hər il üç yarım gündən çox dayanma müddətinə imkan verir. Dörd doqquz icazə verilən dayanma müddətini əlli iki dəqiqəyə endirir, və beş doqquz hər il cəmi beş dəqiqə dayanma müddətinə icazə verir.

10:15 Yüksək əlçatanlığa nail olmaq üçün siz səhv domenləri üzrə tək uğursuzluq nöqtələrini aradan qaldırmalısınız. səhv domenləri üzrə tək uğursuzluq nöqtələrini aradan qaldırmalısınız. Buludda bu, çoxlu Əlçatanlıq Zonalarında yerləşdirmək deməkdir. Bir Əlçatanlıq Zonu tək bir rack deyil: bu, müstəqil enerji və soyutma ilə bir neçə kilometr məsafədə yerləşən bir və ya daha çox fərqli fiziki məlumat mərkəzidir. fiziki məlumat mərkəzidir. Zona A və Zona B-də sinxron verilənlər bazası replikasiyası ilə aktiv instansiyaları işə salmaqla, ildırım vurması və ya lif kəsilməsi bütün fiziki obyekti sıradan çıxararsa, avtomatik failoverlə nəticələnir.

10:50 otuz saniyə ərzində sıfır insan müdaxiləsi ilə.

### - 09. Davamlılıq vs. Əlçatanlıq (Niyə 11 Doqquz Uptime Deyil)

10:53 Doqquzuncu anlayış: Davamlılıq versus Əlçatanlıq. Bu, bulud arxitekturasında ən ümumi konseptual tələdir müsahibələr. Mühəndislər tez-tez bu sözləri bir-birinin yerinə istifadə edirlər, lakin onlar tamamilə fərqli xüsusiyyətləri ölçürlər. Əlçatanlıq işləmə müddətini ölçür: mənim API çağırışı edib məlumatımı oxuya və ya yaza bilərəmmi indi? Davamlılıq qorunmanı ölçür: mənim məlumatım on il ərzində qalıcı şəkildə bit çürüməsi, korrupsiya və ya məhv olmadan sağ qalacaqmı?

11:24 Amazon S3 Standardına baxın. Onun Xidmət Səviyyəsi Müqaviləsi doxsan doqquz tam doqquz faiz təklif edir əlçatanlıq, bu da hər ay təxminən qırx üç dəqiqə dayanma müddətinə icazə verir burada API sorğusu beş yüz səhvi qaytara bilər. Lakin S3 on bir doqquz davamlılıq vəd edir: doxsan doqquz tam doqquz doqquz doqquz doqquz doqquz doqquz doqquz doqquz doqquz faiz. Əgər S3-də on milyon fayl saxlasanız, statistik olaraq hər on min ildə bir fayl itirəcəyinizi gözləyə bilərsiniz.

11:56 orta hesabla hər on min ildə bir fayl itirməyinizi gözləyə bilərsiniz. S3 buna obyektləri silmə-kodlaşdıraraq və hissələri ən azı üç coğrafi olaraq ayrılmış məlumat obyektləri arasında replikasiya edərək nail olur. ən azı üç coğrafi olaraq ayrılmış məlumat mərkəzi arasında hissələri replikasiya edərək nail olur. Böyük bir regional şəbəkə kəsintisi zamanı S3 müvəqqəti olaraq əlçatmaz ola bilər, lakin məlumatlarınız heç vaxt məhv olmur.

### - 10. Kod kimi İnfrastruktura (Terraform vs. Konsol Dəyişikliyi)

12:14 Onuncu anlayış: Kod kimi İnfrastruktur, və ya IaC. Bulud hesablamasının ilk günlərində mühəndislər AWS-ə daxil olurdular veb idarəetmə konsolu və virtual maşınlar yaratmaq üçün əl ilə klikləyirdilər, alt şəbəkələri konfiqurasiya edir və təhlükəsizlik qruplarını əlavə edirdilər. Sənaye bunu ClickOps adlandırır və istehsaldə bu, tam bir fəlakətdir. Əl ilə konsol dəyişikliklərinin audit izi yoxdur, geri qaytarma mexanizmi yoxdur və qaçılmaz olaraq mərhələləndirmə və istehsal mühitləri arasında konfiqurasiya fərqinə səbəb olur. Kod kimi İnfrastruktur alətləri ilə, Terraform kimi,

12:48 Terraform kimi alətlər ilə, OpenTofu, Pulumi, və ya AWS CDK ilə bütün bulud arxitekturanızı Git-də saxlanan deklarativ konfiqurasiya fayllarında təyin edirsiniz. bütün bulud arxitekturanızı Git-də saxlanan deklarativ konfiqurasiya fayllarında təyin edirsiniz. Açıq porta və ya verilənlər bazası replikasına edilən hər dəyişiklik bir pull request və həmyaşıd baxışı vasitəsilə keçir. terraform planını işə salmaq hər hansı bir dəyişiklik edilməzdən əvvəl dəqiq API fərqini göstərir, heç nəyə toxunulmazdan əvvəl dəqiq API fərqini göstərir və istehsal stekinizin eyni replikasını dörd həftə əvəzinə dörd dəqiqəyə işə salır.

### - 11. Bulud Şəbəkəsi (VPC, Subnet-lər, NAT və Təhlükəsizlik Qrupları)

13:20 On birinci anlayış: Bulud Şəbəkəsi və Virtual Şəxsi Buludlar. Serverləri buluda yerləşdirdiyiniz zaman, onlar çılpaq açıq internetdə açıq şəkildə durmurlar. Onlar VPC adlanan proqramla təyin olunan təcrid olunmuş sərhəd daxilində yaşayırlar. VPC adlanan proqramla təyin olunan təcrid olunmuş sərhəd daxilində yaşayırlar. VPC daxilində siz on-nöqtə-sıfır-nöqtə-sıfır-nöqtə-sıfır slash on altı kimi bir şəxsi IP ünvan sahəsi ayırırsınız və onu on-nöqtə-sıfır-nöqtə-sıfır-nöqtə-sıfır slash on altı kimi bir şəxsi IP ünvan sahəsi ayırırsınız və onu ictimai və şəxsi alt şəbəkələrə bölürsünüz. İctimai alt şəbəkənin İnternet Şlyuzuna birbaşa marşrutu var.

13:51 O, Tətbiq Yük Balanslaşdırıcıları və NAT Şlyuzları kimi ictimaiyə açıq aktivləri saxlayır. Şlyuzları. Bu, şəbəkənizin ictimai IP ünvanlarına malik olan yeganə hissəsidir. ünvanları. Tətbiq serverləriniz və istehsal verilənlər bazaları ciddi şəkildə şəxsi alt şəbəkələrdə, ictimai IP-lərsiz və internetdən sıfır daxil olan marşrutlarla yaşayır. internetdən sıfır daxil olan marşrutlarla yaşayır. Arxa uç serverləriniz təhlükəsizlik yeniləmələrini yükləməli olduqda, internetdən sıfır daxil olan marşrutlarla yaşayır. Arxa uç serverləriniz təhlükəsizlik yeniləmələrini yükləməli olduqda, onların çıxan trafik marşrutları ictimai alt şəbəkədəki NAT Şlyuzu vasitəsilə keçir. alt şəbəkə. Hər instansiyanı Əməliyyat Qrupları əhatə edir: ən az imtiyaz prinsipini tətbiq edən vəziyyətli virtual divarlar. virtual divarlar ki, ən az imtiyaz prinsipini tətbiq edirlər.

### - 12. Tam Müəssisə Planı və Hökm

14:28 Verilənlər bazası təhlükəsizlik qrupunuz yalnız 5432 portu üzərindən əlaqələri qəbul edir yalnız tətbiq serverlərinizin təhlükəsizlik qrupundan, kənar müdaxiləni riyazi cəhətdən qeyri-mümkün edir. kənar müdaxiləni riyazi cəhətdən qeyri-mümkün edir. Geriyə çəkildikdə, bu on bir əsas hissə bir tam sistemə birləşir. DNS-niz ictimai alt şəbəkədəki Yük Balanslaşdırıcısına yönəlir, autoscaling qrupları çoxlu Əlçatanlıq Zonalarında trafik artımlarını idarə edir, tədbir avtobusları arxa uç işçilərini ayırır və bütün stekiniz Kod kimi İnfrastruktur istifadə edərək Git-dən yerləşdirilib.

15:02 Bugünkü master-klassın qərarı: SHIP IT. Yüzlərlə bulud marketinq akronimini əzbərləməyi dayandırın. Bu on bir arxitektura nümunəsini mənimsəyin, vəziyyətinizi ayırın, və uğursuz ola bilməyən sistemlər qurun. İlk dəfə qurduğunuzda sizə ən çox baş ağrısı verən bulud konsepsiyasını deyin rəylərdə. Və tam arxitektura fırıldaq vərəqini əldə etmək üçün, gündəlik diff dot dev-də bülletenə abunə olun,

15:28 aşağıdakı link. Və bu, bu gün üçün fərqdir. Mən Axrisidən Nikoyəm. Məsuliyyətlə birləşdirin.

## Mənbələr

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