
AWS-ը Elastic Beanstalk-ը վերակառուցել է որպես հավելվածների կառավարման ծառայություն
The New Stack-ում հրապարակված AWS-ի հովանավորված հոդվածը պնդում է, որ ամպային պլատֆորմների գլխավոր խնդիրը բարդությունը չէ, այլ գործառնական պատասխանատվությունը։ Elastic Beanstalk-ն աշխատում է Standard և Cluster ռեժիմներով։
The New Stack-ում սեպտեմբերի 22-ին հրապարակված AWS-ի հովանավորված հոդվածի գլխավոր փաստարկն այն է, որ ամպային պլատֆորմների համար դժվարը բարդությունը չէ, այլ պատասխանատվությունը։ Հեղինակներն են AWS-ի մենեջեր Սաբարի Սավանտը և վերլուծաբան Ջանակիրամ MSV-ն. հոդվածը նկարագրում է, թե ինչպես AWS-ը Elastic Beanstalk-ը վերակառուցեց հավելվածների կառավարման ծառայության, որը պատասխանատվություն է ստանձնում հավելվածի տակ գտնվող շերտերի համար։
Գիշերվա ժամը երեքի թեստը
Հեղինակները խնդիրը բացատրում են այսպես կոչված գիշերվա ժամը երեքի թեստով. երբ ծանուցում է գալիս ու ծառայությունը վատանում է, պե՞տք է ինչ-որ մեկը արթուն լինի՝ դա շտկելու համար։ Թեստը հանձնում են այն ծառայությունները, որտեղ առողջ վիճակի սահմանումն ու դրա խախտման դեպքում գործողությունները որոշվում են տեղաբաշխման պահին, ոչ թե միջադեպի ժամանակ։
Նրանք համեմատում են երկու մոտեցում՝ ամբողջական վերահսկողություն (ենթակառուցվածքը որպես կոդ, service mesh, սեփական փայփլայններ) և մեկ հավելվածի պարզություն՝ ուղարկիր կոդը, ստացիր URL։ Նրանց պատկերազարդ միջին ընկերությունն ունի քառասուն ինժեներ, ութ արտադրական հավելված, մեկ SRE, որն իրականում ավագ մշակող է, և համապատասխանության աուդիտ, որին ոչ ոք չի սկսել պատրաստվել։
Չորս ձախողման օրինաչափություն
Հոդվածը հիմնվում է հարյուր հազարավոր արտադրական տեղաբաշխումների վրա և թվարկում կրկնվող խնդիրները՝ թողարկումներ, որոնք լուռ հաջողվում են, ապա աննկատ վատանում. դիտարկելիություն, որը գալիս է միջադեպից մի սպրինտ ուշ. պորտֆելի հարկ, երբ ծախսերը գծային աճում են հավելվածների քանակով. և անվտանգության կարգավորումներ, որոնք երբեք չեն կարգավորվում, քանի որ թիմում մասնագետ չկա։
Ջանակիրամ MSV-ն այդ բացը կառուցվածքային է համարում. cloud native-ը ստանդարտացրեց ենթակառուցվածքի շերտը կոնտեյներների ու Kubernetes-ի շուրջ, սակայն չստանդարտացրեց գործառնական սահմանը հավելվածի թիմի և նրա տակ գտնվող ենթակառուցվածքի միջև։ CNCF-ի ուսումնասիրությունը SlashData-ի հետ. կազմակերպությունների 28%-ն ունի առանձին platform engineering թիմ, 41%-ը բաշխում է այդ կարողությունները թիմերի միջև, 3%-ը ֆորմալ մոտեցում չունի. հոդվածի համաձայն՝ միջին շուկայի ինժեներական կազմակերպությունների մեծ մասը հենց այդտեղ է։
Standard և Cluster ռեժիմները
Elastic Beanstalk-ն այժմ աշխատում է երկու ռեժիմով, ինչը փոփոխություն է նախկին մեկ միջավայրով ճարտարապետության համեմատ։ Standard ռեժիմը տալիս է ամբողջական պատասխանատվություն մեկ հավելվածի համար՝ ներառյալ Windows-ի և .NET Framework-ի բեռերը։ Cluster ռեժիմը նույն մոդելը տարածում է ողջ պորտֆելի վրա՝ ընդհանուր ենթակառուցվածքով և կոդից արտադրություն տեղաբաշխմամբ, ութերորդ հավելվածը ծախսերը կիսում է առաջին յոթի հետ։
Հեղինակները չեն բաժանում շուկան բարդությունը նվազեցնող և գործառնությունները մշտապես ստանձնող պլատֆորմների, քանի որ յուրաքանչյուր մատակարար տեղաբաշխման պահին պատասխանատվություն է վերցնում։ Իրական հարցը, նրանց խոսքով, պատասխանատվության որքա՞նն է վերադառնում թիմին միջադեպի, կարկատանների ցիկլի կամ աուդիտի ժամանակ։
SiTech — AI-ով հզորացված վեբ մշակում
Ստեղծում ենք արագ ու ժամանակակից կայքեր և AI-ը ներդնում իրական բիզնես գործընթացներում։ Ունե՞ք նախագիծ կամ հարց։ Ուրախ կլինենք օգնել։