Ամպային հաշվարկների բացատրությունը՝ 11 ճարտարապետական հայեցակարգ, որոնք պետք է իմանաք (4K Masterclass):

Ինչ է ընդգրկում այս տեսանյութը

• - Ճարտարապետության պատը և գլխավոր նախագիծը
• - 01. Ուղղահայաց ընդդեմ հորիզոնական մասշտաբավորման
• - 02. Ծանրաբեռնվածության հավասարակշռման ճարտարապետություն (L4 ընդդեմ L7 և Առողջության ստուգումներ)
• - 03. Ավտոմասշտաբավորում և ճկունություն
• - 04. Անսերվեր (FaaS և Firecracker MicroVMs)

Թարգմանված արձանագրություն

Թարգմանվել է բնօրինակ անգլերեն պատմությունից։ Հասանելի աուդիո և ենթագրերը վերահսկվում են YouTube-ի կողմից։

- Ճարտարապետության պատը և գլխավոր նախագիծը

0:00 Յուրաքանչյուր ծրագրային ինժեներ ի վերջո բախվում է ամպային ճարտարապետության պատին։ Դուք հավելված եք ստեղծում ձեր նոութբուքի վրա, տեղադրում արտադրության մեջ, և այն պահին, երբ իրական օգտատերերը մուտք են գործում, սերվերները խափանվում են, տվյալների բազայի կապերը սպառվում են, իսկ ձեր AWS հաշիվը նմանվում է հեռախոսի համարի։ Ծրագրավորողների մեծ մասը փորձում է լուծել ամպային ինժեներության խնդիրը՝ անգիր անելով երեք հարյուր տարբեր AWS արտադրանքի հապավումներ։ Սակայն իրական ամպային հաշվարկները վաճառողի կատալոգները անգիր անելու մասին չեն: Դրանք կառուցված են տասնմեկ հիմնարար ճարտարապետական պրիմիտիվների վրա։

0:34 Այս վարպետության դասում մենք կուսումնասիրենք ամբողջ ձեռնարկության նախագիծը՝ մասշտաբավորումից և ծանրաբեռնվածության հավասարակշռումից մինչև անսերվերային, իրադարձությունների վրա հիմնված անջատում, պահեստավորման հիերարխիաներ և ամպային ցանցավորում։ Տիրապետեք այս տասնմեկ հասկացություններին, և դուք կարող եք նախագծել ցանկացած backend AWS-ի վրա, GCP-ի կամ Azure-ի։ Սա The Daily Diff-ն է, ներսից։

- 01. Ուղղահայաց ընդդեմ հորիզոնական մասշտաբավորման

0:57 Հասկացություն համար մեկ՝ Մասշտաբավորում։ Երբ ձեր հավելվածը տրաֆիկի աճ է զգում, դուք ունեք երկու սկզբունքորեն տարբեր եղանակներ ծանրաբեռնվածությունը կառավարելու համար՝ ուղղահայաց մասշտաբավորում կամ հորիզոնական մասշտաբավորում։ Ուղղահայաց մասշտաբավորումը, կամ մասշտաբավորումը վերև, նշանակում է վերցնել ձեր գոյություն ունեցող մեքենան և ավելացնել ավելի շատ ռեսուրսներ՝ թարմացնել չորս CPU միջուկներից մինչև երեսուներկու, կամ երեսուներկու գիգաբայթ RAM-ը փոխարինել հարյուր քսանութով։ Ուղղահայաց մասշտաբավորումը պահանջում է զրո ճարտարապետական փոփոխություններ՝ ձեր կոդը

1:28 և տվյալների բազան մնում են ճիշտ նույնը։ Սակայն այն բախվում է դաժան սարքավորումային սահմանին։ Աշխարհում ոչ մի մեքենա տասը հազար CPU միջուկ չունի, և բարձրակարգ ինստանսները կրում են էքսպոնենցիալ գնային պրեմիում։ Հորիզոնական մասշտաբավորումը, կամ մասշտաբավորումը դուրս, նշանակում է ձեր սերվերները պահել փոքր և ցածր գնով, բայց գործարկել բազմաթիվ ինստանսներ զուգահեռ ռոութերի հետևում։ Եթե մեկ ինստանս խափանվում է, մնացած հանգույցները կլանում են տրաֆիկը զրո անջատումով։ Հորիզոնական մասշտաբավորման ոսկե կանոնն է

2:01 անվիճակությունը՝ ձեր հավելվածի սերվերները չեն կարող պահել օգտատերերի սեսիաներ, վերբեռնված ֆայլեր կամ վիճակ իրենց տեղական սկավառակների վրա։ Վիճակը պետք է գտնվի արտաքին տվյալների բազայում կամ քեշում, թույլ տալով ցանկացած հանգույցի մշակել ցանկացած օգտատիրոջ հարցում։

- 02. Ծանրաբեռնվածության հավասարակշռման ճարտարապետություն (L4 ընդդեմ L7 և Առողջության ստուգումներ)

2:17 Հասկացություն համար երկու՝ Ծանրաբեռնվածության հավասարակշռում։ Հորիզոնական մասշտաբավորումը թղթի վրա հիանալի է թվում, բայց այն անմիջապես խնդիր է առաջացնում. երբ տասը հազար օգտատեր մուտք են գործում ձեր տիրույթի անունով, որ կոնկրետ սերվերն է ստանում նրանց տրաֆիկը։ Ծանրաբեռնվածության հավասարակշռիչը գործում է որպես հակադարձ պրոքսի՝ տեղակայված հանրային ինտերնետի և ձեր մասնավոր backend կլաստերի միջև։ Այն ընդունում է մուտքային TCP կամ HTTP կապեր և բաշխում է հարցումները ձեր առողջ ինստանսների միջև։

2:47 Ծանրաբեռնվածության հավասարակշռիչները գործում են երկու հիմնական ցանցային մակարդակներում։ Layer 4 Network Load Balancers-ը գործում է տրանսպորտային շերտում՝ ուղղորդելով հում TCP և UDP փաթեթները IP հասցեի և պորտի հիման վրա միկրովայրկյանական ուշացումով և վայրկյանում միլիոնավոր հարցումներով։ Layer 7 Application Load Balancers-ը ստուգում է HTTP արձանագրությունը ինքնին՝ կարդալով URL ուղիները, հարցման վերնագրերը, քուքիները և HTTP մեթոդները։ Սա հնարավորություն է տալիս ուղու վրա հիմնված երթուղայինացում՝ ուղարկելով slash-api հարցումները ձեր backend կլաստեր և slash-static հարցումները օբյեկտային

3:25 պահեստ։ Կարևոր է, որ ծանրաբեռնվածության հավասարակշռիչները կատարում են ակտիվ առողջության ստուգումներ։ Ամեն մի քանի վայրկյանը մեկ, հավասարակշռիչը պինգ է անում առողջության կետը յուրաքանչյուր ինստանսի վրա։ Եթե ինստանսը երեք անընդմեջ հինգ հարյուր սխալ է գրանցում կամ չի արձագանքում, այն ավտոմատ կերպով հեռացվում է պուլից զրո բաց թողնված հարցումներով։

- 03. Ավտոմասշտաբավորում և ճկունություն

3:45 Հասկացություն համար երեք՝ Ավտոմասշտաբավորում։ Եթե ձեր վեբ հավելվածին առավոտյան ժամը երեքին երկու սերվեր է անհրաժեշտ, բայց կեսօրվա գործարկման ժամանակ քսան սերվեր, ամպային կոնսոլում կոճակները ձեռքով սեղմելը խափանման և սնանկացման երաշխավորված ճանապարհ է։ Ավտոմասշտաբավորումը դինամիկ ճկունություն է հաղորդում հորիզոնական սերվերային պուլերին։ Ավտոմասշտաբավորման խումբը մոնիտորինգ է անում կատարողականի չափորոշիչները, ինչպիսիք են միջին CPU օգտագործումը, ցանցային I-O-ն կամ հերթի հետաձգման խորությունը։ Երբ միջին CPU-ն անցնում է սահմանված շեմը՝ օրինակ,

4:19 յոթանասուն տոկոս երեք անընդմեջ րոպեի համար՝ ավտոմասշտաբավորիչն ավտոմատ կերպով գործարկում է նոր վիրտուալ մեքենաներ, գրանցում դրանք ձեր ծանրաբեռնվածության հավասարակշռիչում, և սկսում է երթուղայինացնել տրաֆիկը։ Հավասարապես կարևոր է մասշտաբավորումը ներս՝ երբ տրաֆիկի ալիքը նահանջում է, ավտոմասշտաբավորիչը դադարեցնում է ավելորդ ինստանսները, որպեսզի դուք դադարեք վճարել պարապ հաշվարկների համար։ Թափահարումը կանխելու համար՝ որտեղ սերվերները արագորեն ստեղծվում և ոչնչացվում են անվերջ պտտվող ցիկլում՝ ամպային ճարտարապետները կարգավորում են սառեցման շրջաններ։ Հասկացություն համար չորս՝ Անսերվեր։

- 04. Անսերվեր (FaaS և Firecracker MicroVMs)

4:53 Տարիներ շարունակ մարքեթինգային թիմերը անսերվերայինը ներկայացնում էին որպես կախարդական կոդ, որն աշխատում է երկնքում։ Իրականում, անսերվերայինը դեռ օգտագործում է սերվերներ, բայց դուք չեք տիրապետում, չեք թարմացնում կամ վճարում դրանց համար, երբ կոդ չի աշխատում։ Function-as-a-Service-ի նման AWS Lambda-ի կամ Google Cloud Functions-ի դեպքում, դուք գրում եք ինքնուրույն հենդլեր ֆունկցիա։ Երբ տեղի է ունենում HTTP հարցում, S3 ֆայլի վերբեռնում կամ տվյալների բազայի փոփոխություն, ամպային միջավայրը գործարկում է անցողիկ

5:23 միկրո-վիրտուալ մեքենա, ինչպիսին է Firecracker-ը, հինգ միլիվայրկյանից պակաս ժամանակում։ Ձեր կոդը կատարվում է, վերադարձնում պատասխան և անջատվում։ Եթե երեք ամիս ոչ ոք չի այցելում ձեր կայք, ձեր հաշվարկման հաշիվը ճիշտ է զրո դոլար և զրո ցենտ։ Եթե միաժամանակ միլիոնավոր օգտատերեր մուտք են գործում, մատակարարը գործարկում է միլիոն միաժամանակյա միկրո-ՎՄ-ներ։ Ինժեներական փոխզիջումներն իրական են՝ սառը գործարկման ուշացում՝ թարմ աշխատանքային միջավայրեր գործարկելիս, Lambda-ի վրա տասնհինգ րոպեի կատարման խիստ սահմանափակում և խիստ անվիճակություն։

5:55 Անսերվերայինն անգերազանցելի է իրադարձությունների խողովակաշարերի և սպորադիկ API-ների համար, բայց վատ է մշտական WebSockets-ի կամ բազմաժամյա մարզումների համար։

- 05. Իրադարձությունների վրա հիմնված ճարտարապետություն (EDA և Անջատում)

6:05 Հասկացություն համար հինգ՝ Իրադարձությունների վրա հիմնված ճարտարապետություն, կամ EDA։ Ավանդական ճարտարապետություններում ծառայությունները հաղորդակցվում են սինխրոն կերպով։ Ձեր դրամարկղային ծառայությունը զանգում է վճարմանը, վճարումը զանգում է պահեստին, պահեստը զանգում է խարդախությանը, իսկ խարդախությունը զանգում է էլփոստին։ Սա ստեղծում է կործանման սինխրոն կասկադ։ Եթե երրորդ կողմի էլփոստի մատակարարը ցանցային խափանում է ունենում և տասը վայրկյան է պահանջվում պատասխանելու համար, ձեր հաճախորդի ամբողջ դրամարկղային հարցումը ժամանակից շուտ ավարտվում է սխալով։ Իրադարձությունների վրա հիմնված ճարտարապետությունում ծառայությունները ամբողջությամբ անջատված են։

6:37 Երբ հաճախորդը սեղմում է գնել, դրամարկղային ծառայությունը չի զանգահարում ներքևի ծառայություններին։ Այն պարզապես հրապարակում է OrderPlaced անունով իրադարձություն կենտրոնական Իրադարձությունների ավտոբուսում, ինչպիսին է 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 Storage-ը։ Դուք ֆայլերին մուտք եք գործում HTTP REST API-ների միջոցով՝ օգտագործելով պարզ PUT և GET կանչեր։ Այն առաջարկում է անսահման հորիզոնական հզորություն ամսական երկու ցենտով մեկ գիգաբայթի համար,

8:49 ինչը այն դարձնում է իդեալական տեսանյութերի, օգտատերերի վերբեռնումների, լոգերի և կրկնօրինակների համար։ Երկրորդը Բլոկային պահեստավորումն է, ինչպիսին է Amazon EBS-ը։ Սրանք վիրտուալ կոշտ սկավառակներ են, որոնք ուղղակիորեն կցված են կոնկրետ վիրտուալ մեքենային բարձր արագությամբ փոխկապակցումների միջոցով։ Դրանք ձևաչափվում են ստանդարտ ֆայլային համակարգերի մեջ, ինչպիսին է ext4-ը, աջակցելով արագ պատահական կարդալու և գրելու մուտքին, որը պահանջվում է տվյալների բազայի շարժիչների կողմից։ Երրորդը Կառավարվող տվյալների բազաներն են՝ հարաբերական շարժիչներ, ինչպիսիք են PostgreSQL-ը RDS-ի վրա, որոնք ապահովում են ACID գործարքներ և բարդ միացումներ,

9:21 և NoSQL շարժիչներ, ինչպիսիք են DynamoDB-ն, որոնք ապահովում են միանիշ միլիվայրկյանային ուշացում զանգվածային մասշտաբով։ Եվ չորրորդը Ներքին հիշողության քեշերն են, ինչպիսին է Redis-ը։ Հիշողությունից տվյալների կարդալը տևում է միկրովայրկյաններ՝ միլիվայրկյանների փոխարեն։ Քեշերը գտնվում են ձեր տվյալների բազայի դիմաց՝ պաշտպանելով այն կրկնվող կարդալու տրաֆիկից և կառավարելով անկայուն օգտատերերի սեսիայի թոքենները։

- 08. Բարձր հասանելիություն և ինը (Multi-AZ Failover)

9:44 Հասկացություն համար ութ՝ Բարձր հասանելիություն, կամ HA։ Հասանելիությունը պատասխանում է մեկ հարցի՝ ժամանակի որ տոկոսում է ձեր հավելվածը գործում և հասանելի օգտատերերին։ Ձեռնարկությունների պայմանագրերում հասանելիությունը չափվում է իններով։ Երկու ինը, կամ իննսունինը տոկոս հասանելիությունը, թույլ է տալիս ավելի քան երեք ու կես օր անջատում ամեն տարի։ Չորս ինը նվազեցնում է թույլատրված անջատումը մինչև հիսուներկու րոպե, իսկ հինգ ինը թույլ է տալիս ընդամենը հինգ րոպե ընդհանուր անջատում մեկ

10:15 տարվա ընթացքում։ Բարձր հասանելիություն ապահովելու համար դուք պետք է վերացնեք ձախողման մեկ կետերը ձախողման տիրույթներում։ Ամպում դա նշանակում է տեղակայել բազմաթիվ հասանելիության գոտիներում։ Հասանելիության գոտին մեկ ռեք չէ, այլ մեկ կամ ավելի տարբեր ֆիզիկական տվյալների կենտրոններ, որոնք գտնվում են մղոններ հեռու՝ անկախ էներգիայով և սառեցումով։ Գործարկելով ակտիվ ինստանսներ Գոտի A-ում և Գոտի B-ում՝ սինխրոն տվյալների բազայի կրկնօրինակումով, կայծակը կամ մալուխի կտրվածքը, որը խափանում է ամբողջ ֆիզիկական հաստատությունը, հանգեցնում է ավտոմատ ֆեյլովերի։

10:50 երեսուն վայրկյանում՝ առանց մարդու միջամտության։

- 09. Դիմացկունություն ընդդեմ հասանելիության (Ինչու 11 ինը չի նշանակում անդադար աշխատանք)

10:53 Իններորդ հայեցակարգը՝ ամրությունն ընդդեմ հասանելիության։ Սա ամենատարածված հայեցակարգային թակարդն է ամպային ճարտարապետության մեջ հարցազրույցների ժամանակ։ Ինժեներները հաճախ փոխարինաբար են օգտագործում բառերը, բայց դրանք չափում են լիովին տարբեր հատկություններ։ Հասանելիությունը չափում է անխափան աշխատանքի ժամանակը․ կարո՞ղ եմ API կանչ կատարել՝ իմ տվյալները կարդալու կամ գրելու համար հենց այս պահին։ Ամրությունը չափում է պահպանումը․ արդյո՞ք իմ տվյալները կգոյատևեն առանց մշտական բիթերի քայքայման, կոռուպցիայի կամ ոչնչացման տասը տարվա ընթացքում։

11:24 Դիտարկենք Amazon S3 Standard-ը։ Դրա Ծառայությունների Մակարդակի Համաձայնագիրը առաջարկում է իննսունինը ամբողջ ինը տասներորդական տոկոս հասանելիություն, որը թույլ է տալիս ամսական մոտ քառասուներեք րոպե անջատում, երբ API հարցումը կարող է վերադարձնել հարյուրավոր սխալներ։ Բայց S3-ը խոստանում է ամրության տասնմեկ իններ․ իննսունինը ամբողջ ինը ինը ինը ինը ինը ինը ինը ինը ինը տոկոս։ Եթե դուք տասը միլիոն ֆայլ եք պահում S3-ում, վիճակագրորեն կարող եք ակնկալել կորցնել միջինը

11:56 մեկ ֆայլ յուրաքանչյուր տասը հազար տարին մեկ։ S3-ն դրան հասնում է՝ օբյեկտները ջնջման կոդավորելով և կտորները բազմապատկելով առնվազն երեք աշխարհագրորեն առանձնացված տվյալների կենտրոններում։ Խոշոր տարածաշրջանային ցանցի անջատման ժամանակ S3-ը ժամանակավորապես կարող է անհասանելի լինել, բայց ձեր տվյալները երբեք չեն ոչնչացվում։

- 10. Ենթակառուցվածքը որպես կոդ (Terraform ընդդեմ Console Drift)

12:14 Տասներորդ հայեցակարգը՝ Ենթակառուցվածքը որպես Կոդ, կամ IaC։ Ամպային հաշվարկների վաղ շրջանում ինժեներները մուտք էին գործում AWS վեբ կառավարման կոնսոլ և ձեռքով սեղմելով ստեղծում էին վիրտուալ մեքենաներ, կարգավորում ենթացանցեր և կցում անվտանգության խմբեր։ Արդյունաբերությունը սա անվանում է ClickOps, և արտադրության մեջ դա բացարձակ աղետ է։ Ձեռքով կատարված կոնսոլային փոփոխությունները չունեն աուդիտի հետք, հետդարձի մեխանիզմ և անխուսափելիորեն առաջացնում են կոնֆիգուրացիայի շեղում փորձարկման և արտադրական միջավայրերի միջև։ Ենթակառուցվածքը

12:48 որպես Կոդ գործիքների հետ, ինչպիսիք են Terraform, OpenTofu-ն, Pulumi-ն կամ AWS CDK-ն, դուք սահմանում եք ձեր ամբողջ ամպային ճարտարապետությունը հայտարարագրային կոնֆիգուրացիոն ֆայլերում, որոնք պահվում են Git-ում։ Բաց պորտի կամ տվյալների բազայի կրկնօրինակի յուրաքանչյուր փոփոխություն անցնում է քաշման հարցում և գործընկերների վերանայում։ Terraform plan-ի գործարկումը նախադիտում է API-ի ճշգրիտ տարբերությունը, մինչև որևէ բանի դիպչելը, և ձեր արտադրական ստեկի ճշգրիտ կրկնօրինակը գործարկելը տևում է չորս րոպե՝ չորս շաբաթի փոխարեն։

- 11. Ամպային ցանցավորում (VPC, ենթացանցեր, NAT և անվտանգության խմբեր)

13:20 Տասնմեկերորդ հայեցակարգը՝ Ամպային ցանցեր և Վիրտուալ մասնավոր ամպեր։ Երբ սերվերներ եք տեղակայում ամպում, դրանք բաց չեն մնում բաց հանրային ինտերնետում։ Դրանք գտնվում են ծրագրային ապահովման կողմից սահմանված մեկուսացված սահմանի ներսում, որը կոչվում է VPC։ Ձեր VPC-ի ներսում դուք հատկացնում եք մասնավոր IP հասցեների տարածք, ինչպիսին է տասը-կետ-զրո-կետ-զրո-կետ-զրո-կետ տասնվեցը, և այն բաժանում եք հանրային և մասնավոր ենթացանցերի։ Հանրային ենթացանցն ունի ուղիղ երթուղի դեպի Ինտերնետ Շլյուզ։

13:51 Այն պարունակում է հանրային հասանելի ակտիվներ, ինչպիսիք են ձեր Հավելվածների Բեռնվածության հավասարեցնողները և NAT Շլյուզները։ Դա ձեր ցանցի միակ մասն է, որն ունի հանրային IP հասցեներ։ Ձեր հավելվածների սերվերները և արտադրական տվյալների բազաները խիստ գտնվում են մասնավոր ենթացանցերում՝ առանց հանրային IP-ների և զրո ներգնա երթուղիների ինտերնետից։ Երբ ձեր backend սերվերներին անհրաժեշտ է անվտանգության թարմացումներ ներբեռնել, դրանց արտագնա երթևեկությունը երթուղի է ստանում NAT Շլյուզի միջոցով՝ հանրային ենթացանցում։ Յուրաքանչյուր օրինակի շուրջ կան Անվտանգության Խմբեր․ վիճակային վիրտուալ հրդեհապատեր, որոնք պարտադրում են նվազագույն արտոնությունների սկզբունքը։

- 12. Ամբողջական ձեռնարկության նախագիծը և վճիռը

14:28 Ձեր տվյալների բազայի անվտանգության խումբը միայն ընդունում է կապեր պորտ 5432-ում՝ խիստ ձեր հավելվածների սերվերների անվտանգության խմբից, դարձնելով արտաքին ներթափանցումը մաթեմատիկորեն անհնար։ Երբ հետ եք քաշվում, այս տասնմեկ պարզագույն տարրերը կապվում են մեկ միասնական համակարգի մեջ։ Ձեր DNS-ը երթուղիներ է կատարում դեպի Բեռնվածության հավասարեցնող հանրային ենթացանցում, ավտոմատ մասշտաբային խմբերը մշակում են երթևեկության աճերը մի քանի հասանելիության գոտիներում, իրադարձությունների ավտոբուսները անջատում են backend աշխատողներին, և ձեր ամբողջ ստեկը տեղակայվում է Git-ից՝ օգտագործելով Ենթակառուցվածքը որպես Կոդ։

15:02 Այսօրվա վարպետության դասի վճիռը՝ SHIP IT։ Դադարեք անգիր անել հարյուրավոր ամպային մարքեթինգային հապավումներ։ Տիրապետեք այս տասնմեկ ճարտարապետական օրինաչափություններին, անջատեք ձեր վիճակը, և կառուցեք համակարգեր, որոնք չեն կարող ձախողվել։ Մեկնաբանություններում պատմեք, թե որ ամպային հայեցակարգն է ձեզ ամենամեծ գլխացավը պատճառել, երբ առաջին անգամ սկսել եք կառուցել։ Եվ ամբողջական ճարտարապետական խաբեության թերթիկը ստանալու համար, բաժանորդագրվեք տեղեկագրին the daily diff dot dev-ում,

15:28 հղումը ներքևում է։ Եվ սա է այսօրվա տարբերությունը։ Ես Նիկոն եմ Axrisi-ից։ Միավորել պատասխանատվությամբ։

Աղբյուրներ

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io