Ключови точки

• Вече няколко години ни беше обещано, че безсървърните компютри (без сървъри) ще започнат нова ера без конкретна операционна система за стартиране на приложения. Казаха ни, че такава структура ще реши много проблеми с мащабируемостта. Всъщност всичко е различно.
• Докато мнозина виждат безсървърната технология като нова идея, нейните корени могат да бъдат проследени до 2006 г. със Zimki PaaS и Google App Engine, като и двете използват безсървърна архитектура.
• Има четири причини, поради които революцията без сървъри е в застой, от ограничената поддръжка на езици за програмиране до проблеми с производителността.
• Компютрите без сървър не са чак толкова безполезни. Далеч от това. Те обаче не трябва да се разглеждат като директен заместител на сървърите. За някои приложения те могат да бъдат удобен инструмент.

Сървърът е мъртъв, да живее сървъра!

Това е бойният вик на привържениците на безсървърната революция. Един бърз поглед върху пресата в индустрията през последните няколко години е достатъчен, за да заключим, че традиционният сървърен модел е мъртъв и че след няколко години всички ще използваме безсървърни архитектури.

Както всеки в индустрията знае и както посочихме в нашата статия за състоянието на безсървърните компютри, това е грешно. Въпреки множеството статии по същество безсървърна революция, никога не се е състояло. Всъщност, последните проучвания показватче тази революция може би е стигнала до задънена улица.

Някои от обещанията за безсървърни модели със сигурност се сбъднаха, но не всички. Не всеки.

В тази статия искам да разгледам причините за това състояние. Защо липсата на гъвкавост на моделите без сървър все още е пречка за по-широкото им приемане, въпреки че те остават полезни при специфични, добре дефинирани обстоятелства.

Какво обещаха адептите на изчисленията без сървър

Преди да преминем към проблемите на безсървърните изчисления, нека видим какво трябваше да осигурят. Обещания за революция без сървъри бяха многобройни и на моменти много амбициозни.

За тези, които не са запознати с термина, ето кратко определение. Безсървърното изчисление дефинира архитектура, в която приложения (или части от приложения) се изпълняват при поискване в среди за изпълнение, които обикновено се хостват отдалечено. Освен това могат да се хостват системи без сървър. Изграждането на стабилни системи без сървър е основна грижа на системните администратори и SaaS компаниите през последните няколко години, тъй като (твърди се) тази архитектура предлага няколко ключови предимства пред „традиционния“ модел клиент/сървър:

1. Безсървърните модели не изискват от потребителите да поддържат свои собствени операционни системи или дори да създават приложения, които са съвместими с конкретни операционни системи. Вместо това разработчиците създават споделен код, качват го на платформа без сървър и го гледат как работи.
2. Ресурсите в безсървърни рамки обикновено се таксуват на минута (или дори секунди). Това означава, че клиентите плащат само за времето, в което действително изпълняват кода. Това се сравнява благоприятно с традиционната облачна виртуална машина, където машината е неактивна през повечето време, но трябва да платите за нея.
3. Проблемът с мащабируемостта също беше решен. Ресурсите в безсървърните рамки се присвояват динамично, така че системата да може лесно да се справи с внезапни пикове в търсенето.

Накратко, моделите без сървър предоставят гъвкави, евтини, мащабируеми решения. Изненадан съм, че не се сетихме за тази идея по-рано.

Това наистина ли е нова идея?

Всъщност идеята не е нова. Концепцията за позволяване на потребителите да плащат само за времето, за което кодът действително се изпълнява, съществува откакто беше въведена под Zimki PaaS през 2006 г. и приблизително по същото време Google App Engine излезе с много подобно решение.

Всъщност това, което сега наричаме модел „без сървър“, е по-старо от много от технологиите, които сега се наричат ​​„роден в облак“, които предоставят почти същото. Както беше отбелязано, моделите без сървъри са по същество просто продължение на бизнес модела SaaS, който съществува от десетилетия.

Също така си струва да се признае, че моделът без сървър не е FaaS архитектура, въпреки че има връзка между двете. FaaS е по същество центрираната към изчисленията част от безсървърна архитектура, но не представлява цялата система.

Така че защо е целият този шум? Е, тъй като степента на навлизане на интернет в развиващите се страни продължава да расте, търсенето на компютърни ресурси също нараства. Например, много държави с бързо развиващи се сектори на електронната търговия просто нямат изчислителна инфраструктура за приложения на тези платформи. Тук идват платените платформи без сървър.

Проблеми с модели без сървър

Уловката е, че моделите без сървър имат... проблеми. Не ме разбирайте погрешно: не казвам, че те са лоши сами по себе си или че не предоставят значителна стойност на някои компании при определени обстоятелства. Но основното твърдение на "революцията" - че безсървърната архитектура бързо ще замени традиционната - никога не се осъществява.

Ето защо.

Ограничена поддръжка за езици за програмиране

Повечето платформи без сървър позволяват да се изпълняват само приложения, написани на определени езици. Това силно ограничава гъвкавостта и адаптивността на тези системи.

Счита се, че платформите без сървър поддържат повечето основни езици. AWS Lambda и Azure Functions също предоставят обвивка за стартиране на приложения и функции на неподдържани езици, въпреки че това често има цена на производителността. Така че за повечето организации това ограничение обикновено не е голяма работа. Но тук е работата. Предполага се, че едно от предимствата на моделите без сървър е, че неясни, рядко използвани програми могат да се използват по-евтино, защото плащате само за времето, в което работят. А неясни, рядко използвани програми често са написани на... неясни, рядко използвани езици за програмиране.

Това подкопава едно от ключовите предимства на безсървърния модел.

Обвързване с доставчик

Вторият проблем с безсървърните платформи или поне с начина, по който се внедряват в момента, е, че те обикновено не си приличат на оперативно ниво. На практика няма стандартизация по отношение на функциите за писане, внедряване и управление. Това означава, че мигрирането на функции от една платформа към друга отнема изключително време.

Най-трудната част от преминаването към модел без сървър не са изчислителните функции, които обикновено са само фрагменти от код, а как приложенията комуникират със свързани системи като съхранение на обекти, управление на идентичността и опашки. Функциите могат да се преместват, но останалата част от приложението не може. Това е точно обратното на обещаните евтини и гъвкави платформи.

Някои твърдят, че моделите без сървър са нови и не е имало време да се стандартизира как работят. Но те не са толкова нови, както отбелязах по-горе, и много други облачни технологии като контейнери вече са станали много по-удобни поради развитието и широкото приемане на добри стандарти.

продуктивност

Изчислителната производителност на платформите без сървър е трудна за измерване, отчасти защото доставчиците са склонни да пазят информацията в тайна. Повечето твърдят, че функциите на отдалечени платформи без сървър работят също толкова бързо, колкото и на вътрешни сървъри, с изключение на няколко неизбежни проблема със закъснението.

Някои доказателства обаче сочат друго. Функциите, които преди това не са се изпълнявали на определена платформа или не са се изпълнявали известно време, отнемат известно време за инициализиране. Това вероятно се дължи на техния код, който е бил пренесен към някакъв по-малко достъпен носител за съхранение, въпреки че - както при бенчмарковете - повечето доставчици няма да ви кажат за пренасяне на данни.

Разбира се, има няколко начина да заобиколите това. Едната е да оптимизирате функциите за какъвто и облачен език да работи вашата безсървърна платформа, но това донякъде подкопава твърдението, че тези платформи са „гъвкави“.

Друг подход е да се гарантира, че критичните за производителността програми се изпълняват редовно, за да бъдат "свежи". Този втори подход, разбира се, е малко в противоречие с твърдението, че платформите без сървър са по-рентабилни, защото плащате само за времето, в което се изпълняват вашите програми. Облачните доставчици въведоха нови начини за намаляване на студените стартирания, но много от тях изискват „мащаб до едно“, което подкопава първоначалната стойност на FaaS.

Проблемът със студеното стартиране може да бъде отчасти решен чрез вътрешно управление на системи без сървър, но това идва на своя сметка и остава опция за ниша за екипи с добри ресурси.

Не можете да стартирате цели приложения

И накрая, може би най-важната причина, поради която безсървърните архитектури няма да заменят традиционните модели скоро е, че те (като цяло) не могат да изпълняват цели приложения.

По-точно непрактично е от гледна точка на разходите. Вашият успешен монолит вероятно не трябва да се превръща в набор от четири дузини функции, свързани заедно с осем шлюза, четиридесет опашки и дузина екземпляри на база данни. Поради тази причина безсървърният режим е по-подходящ за нови разработки. На практика нито едно съществуващо приложение (архитектура) не може да бъде пренесено. Можете да мигрирате, но трябва да започнете от нулата.

Това означава, че в по-голямата част от случаите безсървърните платформи се използват като допълнение към бек-енд сървърите за изпълнение на изчислително интензивни задачи. Това е много различно от другите две форми на облачни изчисления, контейнери и виртуални машини, които предлагат холистичен начин за извършване на отдалечени изчисления. Това илюстрира едно от предизвикателствата на мигрирането от микроуслуги към системи без сървър.

Разбира се, това не винаги е проблем. Възможността периодично да използвате огромни изчислителни ресурси, без да купувате собствен хардуер, може да донесе реални и трайни ползи за много организации. Но ако някои приложения са на вътрешни сървъри, а други са на облачни архитектури без сървър, тогава управлението навлиза на ново ниво на сложност.

Да живее революцията?

Въпреки всички тези оплаквания, аз не съм против решенията без сървър сами по себе си. Честно казано. Просто разработчиците трябва да разберат - особено ако проучват безсървърни модели за първи път - че тази технология не е директен заместител на сървърите. Вместо това вижте нашите съвети и ресурси за изграждане на безсървърни приложения и решите как най-добре да приложите този модел.

Източник: www.habr.com