Հիմնական կետերը

• Արդեն մի քանի տարի է, ինչ մեզ խոստանում են, որ առանց սերվերի հաշվարկը (առանց սերվեր) նոր դարաշրջան կբացի առանց հավելվածներ գործարկելու հատուկ ՕՀ-ի: Մեզ ասացին, որ նման կառույցը լայնածավալության շատ խնդիրներ կլուծի։ Իրականում ամեն ինչ այլ է։
• Թեև շատերը համարում են առանց սերվերի տեխնոլոգիան որպես նոր գաղափար, դրա արմատները կարելի է գտնել մինչև 2006 թվականը Zimki PaaS-ի և Google App Engine-ի միջոցով, որոնք երկուսն էլ օգտագործում են առանց սերվերի ճարտարապետություն:
• Չորս պատճառ կա, թե ինչու է առանց սերվերի հեղափոխությունը կանգ առել՝ սկսած ծրագրավորման լեզվի սահմանափակ աջակցությունից մինչև կատարողականի խնդիրներ:
• Առանց սերվերի հաշվարկն այնքան էլ անօգուտ չէ: Հեռու դրանից. Այնուամենայնիվ, դրանք չպետք է դիտվեն որպես սերվերների անմիջական փոխարինում: Որոշ ծրագրերի համար դրանք կարող են հարմար գործիք լինել:

Սերվերը մահացել է, կեցցե սերվերը:

Սա առանց սերվերի հեղափոխության կողմնակիցների մարտական ​​ճիչն է: Անցած մի քանի տարիների ընթացքում արդյունաբերության մամուլին արագ հայացք գցելու համար բավական է եզրակացնել, որ սերվերի ավանդական մոդելը մեռած է, և որ մի քանի տարի հետո մենք բոլորս կօգտագործենք առանց սերվերի ճարտարապետություն:

Ինչպես գիտի ոլորտի որևէ մեկը, և ինչպես մենք նաև նշել ենք մեր հոդվածում առանց սերվերի հաշվարկման վիճակը, սա սխալ է. Չնայած արժանիքների մասին բազմաթիվ հոդվածներին առանց սերվերի հեղափոխություն, այն երբեք տեղի չի ունեցել։ Իրականում, վերջին ուսումնասիրությունները ցույց են տալիսոր այս հեղափոխությունը կարող է փակուղի մտել։

Սերվերազուրկ մոդելների որոշ խոստումներ, անշուշտ, իրականացել են, բայց ոչ բոլորը: Ոչ բոլորը.

Այս հոդվածում ես ուզում եմ հաշվի առնել այս պայմանի պատճառները: Ինչու է առանց սերվերի մոդելների ճկունության բացակայությունը դեռևս խոչընդոտ է դրանց ավելի լայն ընդունման համար, թեև դրանք մնում են օգտակար հատուկ, լավ սահմանված հանգամանքներում:

Այն, ինչ խոստացան առանց սերվերի հաշվարկման վարպետները

Մինչև առանց սերվերի հաշվարկման խնդիրներին անցնելը, տեսնենք, թե ինչ պետք է տրամադրեին: Անսերվերի հեղափոխության խոստումներ շատ էին և երբեմն շատ հավակնոտ:

Նրանց համար, ովքեր ծանոթ չեն տերմինին, այստեղ կա համառոտ սահմանում. Առանց սերվերի հաշվարկը սահմանում է ճարտարապետություն, որտեղ հավելվածները (կամ հավելվածների մասերը) աշխատում են ըստ պահանջի գործարկման միջավայրերում, որոնք սովորաբար գտնվում են հեռակա կարգով: Բացի այդ, առանց սերվերի համակարգերը կարող են տեղակայվել: Առանց սերվերի ամուր համակարգերի կառուցումը վերջին մի քանի տարիների ընթացքում եղել է համակարգի ադմինիստրատորների և SaaS ընկերությունների հիմնական մտահոգությունը, քանի որ (պնդվում է) այս ճարտարապետությունն առաջարկում է մի քանի հիմնական առավելություններ «ավանդական» հաճախորդի/սերվերի մոդելի նկատմամբ.

1. Առանց սերվերի մոդելները օգտվողներից չեն պահանջում պահպանել իրենց սեփական օպերացիոն համակարգերը կամ նույնիսկ ստեղծել հավելվածներ, որոնք համատեղելի են կոնկրետ օպերացիոն համակարգերի հետ: Փոխարենը, մշակողները ստեղծում են ընդհանուր կոդ, վերբեռնում այն ​​առանց սերվերի հարթակ և դիտում դրա գործարկումը:
2. Առանց սերվերի շրջանակների ռեսուրսները սովորաբար վճարվում են րոպեներով (կամ նույնիսկ վայրկյաններով): Սա նշանակում է, որ հաճախորդները վճարում են միայն այն ժամանակի համար, երբ նրանք իրականում կատարում են կոդը: Սա բարենպաստորեն համեմատվում է ավանդական ամպային VM-ի հետ, որտեղ մեքենան ժամանակի մեծ մասում անգործուն է, բայց դուք պետք է վճարեք դրա համար:
3. Լուծվեց նաև մասշտաբայնության խնդիրը։ Առանց սերվերի շրջանակների ռեսուրսները նշանակվում են դինամիկ կերպով, որպեսզի համակարգը հեշտությամբ կարողանա հաղթահարել պահանջարկի հանկարծակի աճերը:

Մի խոսքով, առանց սերվերի մոդելներն ապահովում են ճկուն, էժան, մասշտաբային լուծումներ: Ես զարմացած եմ, որ ավելի վաղ չէինք մտածել այս գաղափարի մասին:

Իսկապե՞ս սա նոր գաղափար է:

Իրականում գաղափարը նոր չէ. Հայեցակարգը, որը թույլ է տալիս օգտատերերին վճարել միայն այն ժամանակի համար, որն իրականում գործարկվում է կոդը, գոյություն ունի դրա ներդրման պահից Զիմկի ՊաաՍ 2006 թվականին, և մոտավորապես նույն ժամանակ, Google App Engine-ը հանդես եկավ շատ նմանատիպ լուծումով:

Իրականում, այն, ինչ մենք հիմա անվանում ենք «առանց սերվերի» մոդելը, ավելի հին է, քան այն տեխնոլոգիաներից շատերը, որոնք այժմ կոչվում են «ամպի բնիկ», որոնք ապահովում են գրեթե նույնը: Ինչպես նշվեց, առանց սերվերի մոդելները, ըստ էության, ընդամենը SaaS բիզնես մոդելի ընդլայնումն են, որը գոյություն ունի տասնամյակների ընթացքում:

Հարկ է նաև գիտակցել, որ առանց սերվերի մոդելը FaaS ճարտարապետություն չէ, չնայած երկուսի միջև կապ կա: FaaS-ը, ըստ էության, առանց սերվերի ճարտարապետության հաշվարկակենտրոն մասն է, բայց այն չի ներկայացնում ամբողջ համակարգը:

Ուրեմն ինչու՞ այս ամբողջ աղմուկը: Դե, քանի որ զարգացող երկրներում ինտերնետի ներթափանցման տեմպերը շարունակում են աճել, նույնքան էլ աճում է հաշվողական ռեսուրսների պահանջարկը: Օրինակ, էլեկտրոնային առևտրի արագ զարգացող շատ երկրներ պարզապես չունեն հաշվողական ենթակառուցվածք այս հարթակներում հավելվածների համար: Այստեղ են մտնում վճարովի առանց սերվերի հարթակները:

Խնդիրներ առանց սերվերի մոդելների հետ

Բռնելն այն է, որ առանց սերվերի մոդելներն ունեն… խնդիրներ: Ինձ սխալ մի հասկացեք. ես չեմ ասում, որ դրանք ինքնին վատն են կամ որոշ հանգամանքներում նշանակալի արժեք չեն տալիս որոշ ընկերությունների: Բայց «հեղափոխության» հիմնական պնդումը, որ առանց սերվերի ճարտարապետությունը արագորեն կփոխարինի ավանդականին, երբեք չի իրականանում:

Ահա թե ինչու.

Սահմանափակ աջակցություն ծրագրավորման լեզուներին

Առանց սերվերի պլատֆորմների մեծ մասը թույլ է տալիս գործարկել միայն որոշակի լեզուներով գրված հավելվածները: Սա խիստ սահմանափակում է այս համակարգերի ճկունությունն ու հարմարվողականությունը:

Համարվում է, որ առանց սերվերի հարթակները աջակցում են հիմնական լեզուներին: AWS Lambda և Azure գործառույթները նաև ապահովում են հավելվածներ և գործառույթներ չաջակցվող լեզուներով գործարկելու համար, չնայած դա հաճախ ունենում է կատարողական ծախս: Այսպիսով, շատ կազմակերպությունների համար այս սահմանափակումը սովորաբար մեծ խնդիր չէ: Բայց ահա բանը. Ենթադրվում է, որ առանց սերվերի մոդելների առավելություններից մեկն այն է, որ անհասկանալի, հազվադեպ օգտագործվող ծրագրերը կարող են օգտագործվել ավելի էժան, քանի որ վճարում եք միայն դրանց գործարկման ժամանակի համար: Իսկ անհասկանալի, հազվադեպ օգտագործվող ծրագրերը հաճախ գրվում են... անհասկանալի, հազվադեպ օգտագործվող ծրագրավորման լեզուներով:

Սա խաթարում է առանց սերվերի մոդելի հիմնական առավելություններից մեկը:

Պարտադիր վաճառողի հետ

Սերվեր չունեցող պլատֆորմների հետ կապված երկրորդ խնդիրն է, կամ, համենայն դեպս, ներկայումս դրանց ներդրման եղանակը, այն է, որ դրանք սովորաբար նման չեն գործառնական մակարդակում: Գործնականում չկա ստանդարտացում գրելու գործառույթների, տեղակայման և կառավարման առումով: Սա նշանակում է, որ գործառույթների տեղափոխումը մի հարթակից մյուսը չափազանց ժամանակատար է:

Առանց սերվերի մոդելի անցնելու ամենադժվարը հաշվողական առանձնահատկությունները չեն, որոնք սովորաբար կոդի հատվածներ են, այլ այն, թե ինչպես են հավելվածները շփվում միացված համակարգերի հետ, ինչպիսիք են օբյեկտների պահեստավորումը, ինքնության կառավարումը և հերթերը: Գործառույթները կարող են տեղափոխվել, բայց մնացած հավելվածը չի կարող: Սա խոստացված էժան ու ճկուն հարթակների ճիշտ հակառակն է։

Ոմանք պնդում են, որ առանց սերվերի մոդելները նոր են, և ժամանակ չի եղել դրանց աշխատանքի ստանդարտացման համար: Բայց դրանք այնքան էլ նոր չեն, ինչպես ես նշեցի վերևում, և շատ այլ ամպային տեխնոլոգիաներ, ինչպիսիք են բեռնարկղերը, արդեն շատ ավելի հարմար են դարձել լավ չափանիշների մշակման և համատարած ընդունման շնորհիվ:

Արտադրողականություն

Սերվեր չունեցող հարթակների հաշվողական կատարումը դժվար է չափել, մասամբ այն պատճառով, որ վաճառողները հակված են գաղտնի պահել տեղեկատվությունը: Շատերը պնդում են, որ հեռավոր, առանց սերվերի հարթակներում գործառույթներն աշխատում են նույնքան արագ, որքան ներքին սերվերների վրա՝ խնայելով մի քանի անխուսափելի ուշացման խնդիրներ:

Այնուամենայնիվ, որոշ ապացույցներ այլ բան են հուշում: Գործառույթները, որոնք նախկինում չեն գործարկվել որոշակի հարթակում, կամ չեն գործարկվել որոշ ժամանակով, որոշ ժամանակ է պահանջում սկզբնավորման համար: Սա, հավանաբար, պայմանավորված է նրանով, որ նրանց կոդը տեղափոխվել է ավելի քիչ հասանելի պահեստային միջոց, չնայած, ինչպես հենանիշերի դեպքում, վաճառողներից շատերը ձեզ չեն պատմի տվյալների տեղափոխման մասին:

Իհարկե, սա շրջանցելու մի քանի եղանակ կա: Մեկն այն է, որ օպտիմիզացնենք հնարավորությունները ցանկացած ամպային լեզվի համար, որով աշխատում է ձեր առանց սերվերի պլատֆորմը, բայց դա որոշակիորեն խաթարում է այն պնդումը, որ այդ հարթակները «ճկուն են»:

Մեկ այլ մոտեցում է ապահովել, որ կատարման համար կարևոր ծրագրերը կանոնավոր գործարկվեն՝ դրանք «թարմ» պահելու համար: Այս երկրորդ մոտեցումը, իհարկե, մի փոքր հակասում է այն պնդմանը, որ առանց սերվերի հարթակներն ավելի ծախսարդյունավետ են, քանի որ դուք վճարում եք միայն ձեր ծրագրերի գործարկման ժամանակի համար: Ամպային պրովայդերները ներկայացրել են սառը գործարկումները նվազեցնելու նոր ուղիներ, սակայն դրանցից շատերը պահանջում են «մեկ մասշտաբներ» (մասշտաբներ մեկին), ինչը խաթարում է FaaS-ի սկզբնական արժեքը:

Սառը մեկնարկի խնդիրը կարող է մասամբ լուծվել առանց սերվերի համակարգերի ներսում գործարկելու միջոցով, բայց դա գալիս է իր հաշվին և մնում է լավ ռեսուրսներ ունեցող թիմերի խորշ տարբերակ:

Դուք չեք կարող գործարկել ամբողջական ծրագրեր

Վերջապես, թերևս ամենակարևոր պատճառն այն է, որ առանց սերվերի ճարտարապետությունները շուտով չեն փոխարինի ավանդական մոդելներին, այն է, որ նրանք (ընդհանուր առմամբ) չեն կարող գործարկել ամբողջական ծրագրեր:

Ավելի ճիշտ՝ ծախսերի տեսանկյունից դա անիրագործելի է։ Ձեր հաջողված մոնոլիտը, հավանաբար, չպետք է վերածվի չորս տասնյակ գործառույթների մի շարքի՝ կապված ութ դարպասներով, քառասուն հերթերով և տվյալների բազայի տասնյակ օրինակներով: Այս պատճառով առանց սերվերի ավելի հարմար է նոր զարգացումների համար: Գործնականում ոչ մի գոյություն ունեցող հավելված (ճարտարապետություն) հնարավոր չէ տեղափոխել: Դուք կարող եք գաղթել, բայց պետք է սկսել զրոյից:

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

Իհարկե, դա միշտ չէ, որ խնդիր է: Պարբերաբար հսկայական հաշվողական ռեսուրսներ օգտագործելու ունակությունը՝ առանց ձեր սեփական սարքաշար գնելու, կարող է իրական և կայուն օգուտներ բերել բազմաթիվ կազմակերպությունների: Բայց եթե որոշ հավելվածներ գտնվում են ներքին սերվերների վրա, իսկ մյուսները՝ առանց սերվերի ամպային ճարտարապետության, ապա կառավարումը մտնում է բարդության նոր մակարդակ:

Կեցցե հեղափոխությունը.

Չնայած այս բոլոր բողոքներին, ես դեմ չեմ առանց սերվերի լուծումներին: Անկեղծ ասած. Պարզապես մշակողները պետք է հասկանան, հատկապես, եթե նրանք առաջին անգամ են ուսումնասիրում առանց սերվերի մոդելներ, որ այս տեխնոլոգիան ուղղակիորեն չի փոխարինում սերվերներին: Փոխարենը, ստուգեք մեր խորհուրդներն ու ռեսուրսները առանց սերվերի հավելվածների կառուցում և որոշեք, թե ինչպես լավագույնս կիրառել այս մոդելը:

Source: www.habr.com