ключавыя моманты
- Вось ужо некалькі гадоў нам абяцаюць, што бессерверныя вылічэнні (serverless) адкрыюць новую эпоху без канкрэтнай АС для выканання прыкладанняў. Нам казалі, што такая структура вырашыць шмат праблем маштабаванасці. Насамрэч усё інакш.
- Хаця многія разглядаюць бессерверную тэхналогію як новую ідэю, яе карані можна прасачыць аж да 2006 года, калі з'явіліся Zimki PaaS і Google App Engine – у абодвух выпадках выкарыстоўваецца бессерверная архітэктура.
- Ёсць чатыры прычыны, па якіх бессерверная рэвалюцыя зайшла ў тупік: ад абмежаванай падтрымкі моў праграмавання да праблем з прадукцыйнасцю.
- Бессерверныя вылічэнні не так ужо бескарысныя. Зусім не. Аднак іх не трэба разглядаць як прамую замену сервераў. Для некаторых прыкладанняў яны могуць быць зручнай прыладай.
Сервер мёртвы, хай жыве сервер!
Так гучыць баявы кліч адэптаў бессервернай рэвалюцыі. Досыць бегла прагледзець галіновую прэсу апошніх некалькіх гадоў, і можна лёгка прыйсці да высновы, што традыцыйная серверная мадэль мёртвая і што праз некалькі гадоў мы ўсё будзем выкарыстоўваць бессерверныя архітэктуры.
Як вядома любому ў галіны, і як мы таксама паказвалі ў нашым артыкуле аб , гэта не так. Нягледзячы на мноства артыкулаў аб добрых якасцях , яна так і не адбылася. На самой справе, , што гэтая рэвалюцыя, магчыма, зайшла ў тупік.
Некаторыя з абяцанняў для бессерверных мадэляў, несумненна, былі рэалізаваны, але не ўсё. Далёка не ўсё.
У гэтым артыкуле я хачу разгледзець прычыны такога стану. Чаму адсутнасць гнуткасці бессерверных мадэляў усё яшчэ з'яўляецца перашкодай для іх шырэйшага ўкаранення, хоць яны і застаюцца карыснымі ў пэўных, выразна вызначаных абставінах.
Што абяцалі прадстаўнікі бессерверных вылічэнняў
Перш чым перайсці да праблем бессерверных вылічэнняў, давайце паглядзім, што яны мусілі забяспечыць. былі шматлікімі і - часам - вельмі амбіцыйнымі.
Для тых, хто не знаёмы з тэрмінам, вось кароткае азначэнне. Бессерверныя вылічэнні вызначаюць архітэктуру, у якой прыкладанні (ці часткі прыкладанняў) выконваюцца па патрабаванні ў асяроддзях выканання, якія звычайна размяшчаюцца выдалена. Акрамя таго, бессерверныя сістэмы можна захапіць у сябе. На працягу некалькіх апошніх гадоў стварэнне ўстойлівых бессерверных сістэм было галоўным клопатам сістэмных адміністратараў і SaaS-кампаній, паколькі (як сцвярджаецца) гэтая архітэктура прапануе некалькі ключавых пераваг у параўнанні з "традыцыйнай" кліент-сервернай мадэллю:
- Бессерверныя мадэлі не патрабуюць, каб карыстачы падтрымлівалі ўласныя аперацыйныя сістэмы ці нават стваралі прыкладанні, сумяшчальныя з вызначанымі АС. Замест гэтага распрацоўшчыкі ствараюць агульны код, загружаюць яго ў бессерверную платформу і назіраюць за яго выкананнем.
- Рэсурсы ў бессерверных фрэймворках звычайна аплачваюцца па хвілінах (ці нават секундам). Гэта азначае, што кліенты плацяць толькі за той час, калі яны фактычна выконваюць код. Гэта выгадна адрозніваецца ад традыцыйнай хмарнай VM, дзе машына большую частку часу прастойвае, але за яе даводзіцца плаціць.
- Праблема маштабаванасці таксама вырашалася. Рэсурсы ў бессерверных фрэймворках прызначаюцца дынамічна, так што сістэма лёгка спраўляецца з раптоўнымі воплескамі попыту.
Карацей кажучы, бессерверныя мадэлі забяспечваюць гнуткія, танныя, якія маштабуюцца рашэнні. Дзіўна, што мы не дадумаліся да гэтай ідэі раней.
Гэта сапраўды новая ідэя?
Насамрэч ідэя не новая. Канцэпцыя, якая дазваляе карыстальнікам плаціць толькі за той час, калі код фактычна запускаецца, існуе з таго часу, як яна была ўведзена ў рамках у 2006 годзе, і прыкладна ў той жа час Google App Engine прапанаваў вельмі падобнае рашэнне.
Насамрэч тое, што мы цяпер завём «бессервернай» мадэллю, старэйшай за шматлікія тэхналогіі, якія цяпер завуць «натыўнымі хмарнымі», і якія забяспечваюць амаль тое ж самае. Як ужо адзначалася, бессерверныя мадэлі ў сутнасці з'яўляюцца толькі працягам бізнэс-мадэлі SaaS, якая існуе ўжо некалькі дзесяцігоддзяў.
Таксама варта прызнаць, што бессерверная мадэль не з'яўляецца архітэктурай FaaS, хаця паміж імі ёсць сувязь. FaaS – гэта, у сутнасці, арыентаваная на вылічэнні частка бессервернай архітэктуры, але яна не ўяўляе ўсю сістэму цалкам.
Дык навошта ўся гэтая шуміха? Што ж, паколькі хуткасць пранікнення інтэрнэту ў краіны, якія развіваюцца, працягвае імкліва расці, адначасова расце попыт на вылічальныя рэсурсы. Напрыклад, у многіх краінах з хутка растучымі сектарамі электроннай камерцыі проста няма вылічальнай інфраструктуры для прыкладанняў на гэтых платформах. Вось тут і з'яўляюцца платныя бессерверныя платформы.
Праблемы бессерверных мадэляў
Загваздка ў тым, што ў бессерверных мадэляў ёсць… праблемы. Не зразумейце мяне няправільна: я не кажу, што яны дрэнныя самі па сабе ці не забяспечваюць істотнай каштоўнасці для некаторых кампаній у некаторых абставінах. Але галоўнае сцвярджэнне "рэвалюцыі" - што бессерверная архітэктура хутка заменіць традыцыйную - ніколі не рэалізуецца.
Вось чаму.
Абмежаваная падтрымка моў праграмавання
Большасць бессерверных платформаў дазваляюць запускаць толькі тыя прыкладанні, якія напісаны на пэўных мовах. Гэта сур'ёзна абмяжоўвае гнуткасць і адаптыўнасць гэтых сістэм.
Лічыцца, што большасць асноўных моў падтрымліваюць бессерверныя платформы. AWS Lambda і Azure Functions таксама даюць абалонку для запуску прыкладанняў і функцый на непадтрымоўваных мовах, хоць гэта часта спалучана з выдаткамі на прадукцыйнасць. Так што для большасці арганізацый звычайна гэтае абмежаванне не мае вялікага значэння. Але вось у чым справа. Мяркуецца, што адна з пераваг бессерверных мадэляў у тым, што малавядомыя, рэдка выкарыстоўваныя праграмы можна выкарыстоўваць танней, паколькі вы плаціце толькі за час іх выканання. А малавядомыя праграмы, якія рэдка выкарыстоўваюцца, часта пішуцца на… малавядомых, рэдка выкарыстоўваюцца мовах праграмавання.
Гэта падрывае адну з ключавых пераваг бессервернай мадэлі.
Прывязка да вендару
Другая праблема з бессервернымі платформамі ці, прынамсі, з тым, як яны рэалізуюцца ў наш час, складаецца ў тым, што яны звычайна не падобныя сябар на сябра на аперацыйным узроўні. Практычна няма стандартызацыі ў частцы напісання функцый, дэплою і кіравання. Гэта азначае, што міграцыя функцый з адной платформы на іншую займае надзвычай шмат часу.
Самая цяжкая частка пераходу на бессерверную мадэль – гэта не вылічальныя функцыі, якія звычайна ўяўляюць сабой проста фрагменты кода, а тое, як прыкладанні звязаныя з падлучанымі сістэмамі, такімі як сховішча аб'ектаў, кіраванне ідэнтыфікацыяй і чэргі. Функцыі можна перамясціць, але астатнюю частку прыкладання - не. Гэта поўная супрацьлегласць абяцаным танным і гнуткім платформам.
Некаторыя сцвярджаюць, што бессерверныя мадэлі з'явіліся нядаўна, і не было чакай стандартаваць іх працу. Але яны не так ужо і новыя, як я ўжо адзначаў вышэй, і многія іншыя хмарныя тэхналогіі, такія як кантэйнеры, ужо сталі значна зручнейшымі дзякуючы распрацоўцы і шырокаму ўкараненню добрых стандартаў.
Proizvoditelnost
Вылічальную прадукцыйнасць бессерверных платформаў цяжка вымераць, збольшага таму, што вендары імкнуцца захаваць інфармацыю ў таямніцы. Большасць сцвярджае, што функцыі на выдаленых, бессерверных платформах працуюць гэтак жа хутка, як і на ўнутраных серверах, за выключэннем некалькіх непазбежных праблем з затрымкай.
Аднак асобныя факты сведчаць аб адваротным. Функцыі, якія раней не запускаліся на вызначанай платформе ці не запускаліся на працягу некаторага часу, патрабуюць некаторага часу для ініцыялізацыі. Верагодна, гэта звязана з тым, што іх код быў перанесены на нейкі менш даступны носьбіт дадзеных, хоць - як і ў выпадку з бенчмаркамі - большасць вендараў не скажуць вам аб пераносе дадзеных.
Вядома, ёсць некалькі спосабаў абысці гэта. Адзін з іх заключаецца ў аптымізацыі функцый для любой хмарнай мовы, на якім працуе ваша бессерверная платформа, але гэта некалькі падрывае сцвярджэнне аб тым, што гэтыя платформы з'яўляюцца "гнуткімі".
Іншы падыход заключаецца ў тым, каб забяспечыць рэгулярнае выкананне крытычна важных для прадукцыйнасці праграм, каб яны заставаліся "свежымі". Гэты другі падыход, вядома, крыху супярэчыць сцвярджэнню, што бессерверныя платформы больш эканамічныя, таму што вы плаціце толькі за час працы вашых праграм. Воблачнае правайдэры ўкаранілі новыя спосабы скарачэння халодных запускаў, але многія з іх патрабуюць "маштабавання да аднаго" (scale to one), што падрывае першапачатковую каштоўнасць FaaS.
Праблему "халоднага запуску" можна часткова вырашыць шляхам запуску бессерверных сістэм сваімі сіламі, але гэта звязана з уласнымі выдаткамі і застаецца нішавым варыянтам для добра забяспечаных рэсурсамі каманд.
Вы не можаце запускаць цэлыя прыкладанні
Нарэшце, магчыма, найважнейшы чыннік, па якой бессерверныя архітэктуры не заменяць традыцыйныя мадэлі хуткім часам: на іх (як правіла) нельга запускаць цэлыя прыкладанні.
Дакладней, гэта немэтазгодна з пункту гледжання затрат. Ваш паспяховы маналіт, верагодна, не варта ператвараць у набор з чатырох дзясяткаў функцый, злучаных васьмю шлюзамі, сарака чэргамі і тузінам асобнікаў БД. Па гэтым чынніку serverless лепш падыходзіць для новых распрацовак. Практычна ніводнае існуючае прыкладанне (архітэктуру) нельга перанесці. Вы можаце міграваць, але давядзецца пачынаць з нуля.
Гэта азначае, што ў пераважнай большасці выпадкаў бессерверныя платформы выкарыстоўваюцца ў якасці дадатку да ўнутраных сервераў для выканання задач, якія патрабуюць вялікіх вылічэнняў. Гэта вельмі моцна адрознівае іх ад двух іншых формаў хмарных тэхналогій - кантэйнераў і віртуальных машын, якія прапануюць цэласны спосаб выканання выдаленых вылічэнняў. Гэта ілюструе адну з цяжкасцяў пераходу ад мікрасэрвісаў да бессерверных сістэм.
Вядома, гэта не заўсёды уяўляе сабой праблему. Магчымасць перыядычна выкарыстоўваць вялізныя вылічальныя рэсурсы, не купляючы ўласнае жалеза, можа прынесці рэальную і доўгатэрміновую карысць для многіх арганізацый. Але калі некаторыя прыкладанні знаходзяцца на ўнутраных серверах, а іншыя - на бессерверных хмарных архітэктурах, то кіраванне выходзіць на новы ўзровень складанасці.
Няхай жыве рэвалюцыя?
Нягледзячы на ўсе гэтыя скаргі, я не супраць бессерверных рашэнняў як такіх. Слова гонару. Проста распрацоўшчыкі павінны разумець – асабліва калі яны ўпершыню даследуюць бессерверныя мадэлі – што гэтая тэхналогія не з'яўляецца прамой заменай сервераў. Замест гэтага азнаёмцеся з нашымі парадамі і рэсурсамі па і вырашыце, як лепш за ўсё прымяніць гэтую мадэль.
Крыніца: habr.com