Неліктен серверсіз революция тұйыққа тірелді

Негізгі нүктелер

  • Бірнеше жыл бойы бізге серверсіз есептеулер (серверсіз) қолданбаларды іске қосу үшін арнайы ОЖсыз жаңа дәуірді ашады деп уәде берді. Бізге мұндай құрылым ауқымдылыққа қатысты көптеген мәселелерді шешеді деп айтты. Шындығында, бәрі басқаша.
  • Көптеген адамдар серверсіз технологияны жаңа идея ретінде қарастырғанымен, оның тамырын 2006 жылы Zimki PaaS және Google App Engine арқылы іздеуге болады, олардың екеуі де серверсіз архитектураны пайдаланады.
  • Бағдарламалау тілін шектеулі қолдаудан өнімділік мәселелеріне дейін серверсіз революцияның тоқтап қалуының төрт себебі бар.
  • Серверсіз есептеулер соншалықты пайдасыз емес. Одан алыс. Дегенмен, оларды серверлерді тікелей ауыстыру ретінде қарастыруға болмайды. Кейбір қолданбалар үшін олар ыңғайлы құрал болуы мүмкін.

Сервер өлді, сервер аман болсын!

Бұл серверсіз революцияны жақтаушылардың шайқас айқайы. Соңғы бірнеше жылдағы салалық баспасөзге жылдам шолу дәстүрлі сервер үлгісі өлді және бірнеше жылдан кейін бәріміз серверсіз архитектураларды қолданатын боламыз деген қорытындыға келуге жеткілікті.

Бұл саладағы кез келген адам біледі және біз өз мақаламызда атап өткендей серверсіз есептеулер күйі, Бұл олай емес. Мағынасы туралы көптеген мақалаларға қарамастан серверсіз революция, ол ешқашан болған емес. Ақиқатында, соңғы зерттеулер көрсетедібұл революция тұйыққа тірелген болуы мүмкін.

Серверсіз модельдерге арналған кейбір уәделер орындалды, бірақ бәрі емес. Барлығы емес.

Бұл мақалада мен бұл жағдайдың себептерін қарастырғым келеді. Неліктен серверсіз үлгілердің икемділігінің жоқтығы әлі де оларды кеңірек қабылдауға кедергі болып табылады, бірақ олар нақты, жақсы анықталған жағдайларда пайдалы болып қала береді.

Серверсіз есептеу шеберлері нені уәде етті

Серверсіз есептеулердің мәселелеріне көшпес бұрын, олардың не қамтамасыз ету керек екенін көрейік. Серверсіз революцияның уәделері көп болды және кейде - өте өршіл болды.

Терминді білмейтіндер үшін қысқаша анықтама берілген. Серверсіз есептеуіш қолданбалар (немесе қолданбалардың бөліктері) әдетте қашықтан орналастырылатын орындалу орталарында сұраныс бойынша іске қосылатын архитектураны анықтайды. Сонымен қатар, серверсіз жүйелерді орналастыруға болады. Серверсіз сенімді жүйелерді құру соңғы бірнеше жылда жүйелік әкімшілер мен SaaS компанияларының басты мәселесі болды, өйткені бұл архитектура «дәстүрлі» клиент/сервер үлгісіне қарағанда бірнеше негізгі артықшылықтарды ұсынады:

  1. Серверсіз үлгілер пайдаланушылардан өздерінің операциялық жүйелеріне қолдау көрсетуді немесе тіпті арнайы операциялық жүйелермен үйлесімді қолданбаларды құруды талап етпейді. Оның орнына әзірлеушілер ортақ код жасайды, оны серверсіз платформаға жүктеп салып, оның іске қосылуын бақылайды.
  2. Серверсіз фреймворктардағы ресурстар әдетте минутпен (немесе тіпті секундтармен) есептелінеді. Бұл клиенттер кодты нақты орындаған уақыт үшін ғана төлейтінін білдіреді. Бұл дәстүрлі бұлтты VM-мен жақсы салыстырылады, мұнда машина көп уақыт жұмыс істемейді, бірақ ол үшін төлеуге тура келеді.
  3. Масштабтау мәселесі де шешілді. Жүйе сұраныстың кенеттен көтерілуіне оңай төтеп бере алатындай серверсіз құрылымдардағы ресурстар динамикалық түрде тағайындалады.

Қысқаша айтқанда, серверсіз модельдер икемді, арзан, масштабталатын шешімдерді ұсынады. Мен бұл идеяны бұрын ойламағанымызға таң қалдым.

Бұл шынымен жаңа идея ма?

Негізі бұл идея жаңа емес. Пайдаланушыларға код нақты жұмыс істейтін уақыт үшін ғана төлеуге рұқсат беру тұжырымдамасы ол енгізілгеннен бері бар Zimki PaaS 2006 жылы және шамамен сол уақытта Google App Engine өте ұқсас шешімді ұсынды.

Шындығында, біз қазір «серверсіз» модель деп атайтын модель қазір «бұлтты жергілікті» деп аталатын және бірдей дерлік қамтамасыз ететін көптеген технологиялардан ескірек. Жоғарыда айтылғандай, серверсіз модельдер негізінен ондаған жылдар бойы болған SaaS бизнес үлгісінің кеңейтімі ғана.

Серверсіз модель FaaS архитектурасы емес екенін мойындаған жөн, бірақ екеуінің арасында байланыс бар. FaaS негізінен серверсіз архитектураның есептеуге бағытталған бөлігі болып табылады, бірақ ол бүкіл жүйені білдірмейді.

Ендеше, осының бәрі неліктен? Дамушы елдерде Интернетке ену қарқыны күрт артуда, есептеу ресурстарына деген сұраныс та өсуде. Мысалы, электрондық коммерция секторлары қарқынды дамып келе жатқан көптеген елдерде бұл платформалардағы қолданбалар үшін есептеу инфрақұрылымы жоқ. Бұл жерде ақылы серверсіз платформалар келеді.

Серверсіз үлгілермен проблемалар

Бұл серверсіз үлгілерде ... проблемалары бар. Мені қате түсінбеңіз: мен олар өздерін нашар деп айтпаймын немесе кейбір жағдайларда кейбір компанияларға айтарлықтай құндылық бермейді. Бірақ «төңкерістің» негізгі талабы - серверсіз архитектура дәстүрлі архитектураны тез ауыстырады - ешқашан нәтиже бермейді.

Сондықтан.

Бағдарламалау тілдеріне шектеулі қолдау

Көптеген серверсіз платформалар тек белгілі бір тілдерде жазылған қолданбаларды іске қосуға мүмкіндік береді. Бұл осы жүйелердің икемділігі мен бейімделгіштігін қатты шектейді.

Серверсіз платформалар көптеген негізгі тілдерді қолдайды деп саналады. AWS Lambda және Azure функциялары қолдау көрсетілмейтін тілдерде іске қосылған қолданбалар мен функцияларға арналған қаптаманы қамтамасыз етеді, дегенмен бұл жиі өнімділік құнына ие болады. Сондықтан көптеген ұйымдар үшін бұл шектеу әдетте маңызды емес. Бірақ бұл жерде. Серверсіз модельдердің артықшылықтарының бірі - бұл түсініксіз, сирек қолданылатын бағдарламаларды арзанырақ пайдалануға болады, өйткені сіз тек олардың жұмыс істейтін уақыты үшін төлейсіз. Ал түсініксіз, сирек қолданылатын бағдарламалар көбіне... түсініксіз, сирек қолданылатын программалау тілдерінде жазылады.

Бұл серверсіз модельдің негізгі артықшылықтарының бірін бұзады.

Сатушыға байланыстыру

Серверсіз платформалардың екінші проблемасы немесе, кем дегенде, олардың қазіргі уақытта жүзеге асырылу тәсілі, олар әдетте операциялық деңгейде бір-біріне ұқсамайды. Жазу функциялары, орналастыру және басқару тұрғысынан стандарттау іс жүзінде жоқ. Бұл мүмкіндіктерді бір платформадан екіншісіне тасымалдау өте көп уақытты қажет ететінін білдіреді.

Серверсіз үлгіге көшудің ең қиын бөлігі әдетте жай ғана код үзінділері болып табылатын есептеу мүмкіндіктері емес, қолданбалардың нысанды сақтау, сәйкестендіруді басқару және кезек сияқты қосылған жүйелермен қалай байланысуы болып табылады. Функцияларды жылжытуға болады, бірақ қолданбаның қалған бөлігін жылжыту мүмкін емес. Бұл уәде етілген арзан және икемді платформаларға мүлдем қарама-қайшы.

Кейбіреулер серверсіз модельдер жаңа және олардың қалай жұмыс істейтінін стандарттауға уақыт болмады деп санайды. Бірақ олар жаңа емес, мен жоғарыда атап өткенімдей, контейнерлер сияқты басқа да көптеген бұлттық технологиялар жақсы стандарттарды әзірлеу мен кеңінен қабылдаудың арқасында әлдеқайда ыңғайлы болды.

өнімділік

Серверсіз платформалардың есептеу өнімділігін өлшеу қиын, өйткені ішінара жеткізушілер ақпаратты құпия сақтайды. Көбісі қашықтағы, серверсіз платформалардағы мүмкіндіктер ішкі серверлердегідей жылдам жұмыс істейді, бірнеше сөзсіз кідіріс мәселелерін сақтайды деп санайды.

Дегенмен, кейбір дәлелдер басқаша көрсетеді. Бұрын белгілі бір платформада іске қосылмаған немесе біраз уақыт іске қосылмаған функцияларды инициализациялау үшін біраз уақыт қажет. Бұл олардың кодының кейбір қол жетімді сақтау ортасына тасымалдануымен байланысты болуы мүмкін, дегенмен - эталондар сияқты - көптеген жеткізушілер сізге деректерді тасымалдау туралы айтпайды.

Әрине, мұны айналып өтудің бірнеше жолы бар. Олардың бірі серверсіз платформа жұмыс істейтін кез келген бұлттық тіл үшін мүмкіндіктерді оңтайландыру болып табылады, бірақ бұл бұл платформалар «икемді» деген мәлімдемені біршама жоққа шығарады.

Тағы бір тәсіл - өнімділігі маңызды бағдарламаларды «жаңа» сақтау үшін жүйелі түрде іске қосылуын қамтамасыз ету. Бұл екінші тәсіл, әрине, серверсіз платформалар үнемдірек деген мәлімдемеге сәл қарсы келеді, өйткені сіз тек бағдарламаларыңыздың жұмыс істеген уақыты үшін төлейсіз. Бұлттық провайдерлер салқын ұшыруды азайтудың жаңа әдістерін енгізді, бірақ олардың көпшілігі FaaS бастапқы мәнін бұзатын «бірге дейін масштабты» талап етеді.

Суық іске қосу мәселесін ішінара серверсіз жүйелерді үй ішінде іске қосу арқылы шешуге болады, бірақ бұл өз есебінен келеді және жақсы ресурстары бар командалар үшін тауаша нұсқасы болып қала береді.

Толық қолданбаларды іске қоса алмайсыз

Ақырында, серверсіз архитектуралардың дәстүрлі үлгілерді жақын арада алмастырмайтынының ең маңызды себебі, олар (әдетте) қолданбаларды толығымен іске қоса алмайды.

Дәлірек айтсақ, бұл шығын тұрғысынан іс жүзінде мүмкін емес. Сәтті монолитті сегіз шлюз, қырық кезек және ондаған дерекқор даналары арқылы біріктірілген төрт ондаған функциялар жинағына айналдыруға болмайды. Осы себепті серверсіз жаңа әзірлемелер үшін жақсырақ. Іс жүзінде ешбір қолданыстағы қолданбаны (архитектураны) тасымалдау мүмкін емес. Көшіруге болады, бірақ нөлден бастау керек.

Бұл көп жағдайда серверсіз платформалар есептеуді қажет ететін тапсырмаларды орындау үшін бэк-серверлерге қосымша ретінде пайдаланылады дегенді білдіреді. Бұл қашықтан есептеуді орындаудың біртұтас әдісін ұсынатын бұлтты есептеудің басқа екі түрінен, контейнерлерден және виртуалды машиналардан өте ерекшеленеді. Бұл микросервистерден серверсіз жүйелерге көшу қиындықтарының бірін көрсетеді.

Әрине, бұл әрқашан қиындық тудырмайды. Жеке жабдықты сатып алмай-ақ үлкен есептеу ресурстарын мерзімді түрде пайдалану мүмкіндігі көптеген ұйымдарға нақты және тұрақты пайда әкелуі мүмкін. Бірақ кейбір қолданбалар ішкі серверлерде, ал басқалары серверсіз бұлт архитектурасында болса, басқару күрделіліктің жаңа деңгейіне шығады.

Революция болсын?

Барлық осы шағымдарға қарамастан, мен серверсіз шешімдерге қарсы емеспін. Шын сөзім. Әзірлеушілер, әсіресе серверсіз үлгілерді алғаш рет зерттеп жатқан болса, бұл технология серверлерді тікелей алмастыра алмайтынын түсінуі керек. Оның орнына біздің кеңестер мен ресурстарды қараңыз серверсіз қолданбаларды құру және осы үлгіні қалай қолдану керектігін шешіңіз.

Ақпарат көзі: www.habr.com

пікір қалдыру