Ключови моменти
- Вече няколко години ни обещават, че безсървърните изчисления (serverless) ще открият нова ера без конкретна ОС за изпълнение на приложения. Казваха ни, че тази структура ще реши множество проблеми със мащабируемостта. Всъщност всичко е различно.
- Въпреки че много хора разглеждат безсървърната технология като нова идея, корените й могат да се проследят чак до 2006 г., когато се появиха Zimki PaaS и Google App Engine — в двата случая се използва безсървърна архитектура.
- Има четири причини, поради които безсървърната революция затъна: от ограничената поддръжка на програмни езици до проблеми с производителността.
- Безсървърните изчисления не са толкова безполезни. В никакъв случай. Обаче не бива да се разглеждат като пряка замяна на сървърите. За някои приложения те могат да бъдат удобен инструмент.
Сървърът е мъртъв, да живее сървърът!
Така звучи боен вик на адептите на безсървърната революция. Достатъчно е да прегледате индустриалната преса през последните няколко години, за да стигнете до извода, че традиционният сървърен модел е мъртъв и че след няколко години всички ще използваме безсървърни архитектури.
Както е известно на всеки в индустрията, и както ние също посочихме в нашата статия за , това не е така. Въпреки множеството статии за предимствата на , тя така и не се състоя. Всъщност, , че тази революция може би затъна.
Някои от обещанията за безсървърни модели безспорно са се реализирали, но не всички. Далеч не всички.
В тази статия искам да разгледам причините за това състояние. Защо липсата на гъвкавост в безсървърните модели все още е пречка за тяхното по-широко внедряване, въпреки че остават полезни в конкретни, ясно определени обстоятелства.
Какво обещаваха адептите на безсървърните изчисления
Преди да преминем към проблемите на безсървърните изчисления, нека да видим какво те трябваше да осигурят. бяха многобройни и — понякога — много амбициозни.
За тези, които не са запознати с термина, ето кратко определение. Безсървърните изчисления определят архитектура, в която приложения (или части от приложения) се изпълняват при поискване в среда на изпълнение, която обикновено е хоствана отдалечено. Освен това безсървърните системи могат да се хостват и на местно ниво. През последните няколко години създаването на устойчиви безсървърни системи беше основна грижа за системните администратори и SaaS компаниите, тъй като (както се твърди) тази архитектура предлага няколко ключови предимства в сравнение с "традиционния" клиент-сървърен модел:
- Безсървърните модели не изискват от потребителите да поддържат свои собствени операционни системи или дори да създават приложения, съвместими с определени ОС. Вместо това, разработчиците създават общ код, качват го на безсървърна платформа и наблюдават как се изпълнява.
- Ресурсите в безсървърните фреймворкове обикновено се заплащат на минута (или дори на секунда). Това означава, че клиентите плащат само за времето, когато действително се изпълнява код. Това е значително различно от традиционната облачна виртуална машина, при която машината е в голяма част от времето бездействуваща, но за нея трябва да се плаща.
- Проблемът със скалируемостта също е решен. Ресурсите в безсървърните фреймворкове се разпределят динамично, така че системата лесно се справя с неочаквани пикове в търсенето.
Накратко, безсървърните модели предлагат гъвкави, икономически ефективни и скалируеми решения. Удивително е, че не сме си помислили за тази идея по-рано.
Наистина ли е нова идея?
Всъщност, идеята не е нова. Концепцията, която позволява на потребителите да плащат само за времето, когато кодът действително се стартира, съществува откакто тя беше представена в рамките на през 2006 година, и около същото време Google App Engine предложи много подобно решение.
Наистина, това, което сега наричаме "безсървърна" модел, е по-старо от много технологии, които в момента наричаме "нативни облачни", а които предлагат почти същото. Както вече беше посочено, безсървърните модели по същество са просто продължение на бизнес модела SaaS, който съществува вече няколко десетилетия.
Също е важно да признаем, че безсървърната модел не е архитектура FaaS, въпреки че между тях има връзка. FaaS е по същество изчислителна част от безсървърната архитектура, но не представя цялата система.
И така, защо всичко това? Ами, тъй като скоростта на проникване на интернет в развиващите се държави продължава да нараства бързо, нараства търсенето на изчислителни ресурси. Например, в много страни с бързо развиващи се сектори на електронната търговия просто няма изчислителна инфраструктура за приложения на тези платформи. Тук се появяват платените безсървърни платформи.
Проблеми с безсървърните модели
Проблемът е, че безсървърните модели имат… проблеми. Не ме разбирайте погрешно: аз не казвам, че са лоши сами по себе си или не предлагат съществена стойност за някои компании в определени обстоятелства. Но основното твърдение за "революцията"— че безсървърната архитектура бързо ще замени традиционната — никога няма да се реализира.
Ето защо.
Ограничена поддръжка на програмни езици
Повечето безсървърни платформи позволяват пускането само на приложения, написани на определени езици. Това сериозно ограничава гъвкавостта и адаптивността на тези системи.
Счита се, че безсървърните платформи поддържат повечето основни езици. AWS Lambda и Azure Functions също предоставят обвивка за пускане на приложения и функции на неподдържани езици, въпреки че това често е свързано с разходи за производителност. И така, за повечето организации обикновено това ограничение няма голямо значение. Но ето какво. Предполага се, че едно от предимствата на безсървърните модели е, че по-неизвестни, рядко използвани програми могат да се използват по-евтино, тъй като плащате само за времето на изпълнение. А по-неизвестни, рядко използвани програми често се пишат на… по-неизвестни, рядко използвани програмни езици.
Това подкопава едно от основните предимства на безсървърния модел.
Привързаност към доставчика
Втората проблема с безсървърните платформи или, поне с начина, по който те се реализират в момента, е, че те обикновено не си приличат на операционно ниво. Практически няма стандартизация по отношение на написването на функции, деплойването и управлението. Това означава, че миграцията на функции от една платформа на друга отнема изключително много време.
Най-трудната част от преминаването към безсървърен модел не са обчислителните функции, които обикновено представляват просто фрагменти от код, а начинът, по който приложенията са свързани с свързаните системи, като съхранение на обекти, управление на идентификацията и опашките. Функциите могат да бъдат преместени, но останалата част от приложението – не. Това е пълната противоположност на обещаните евтини и гъвкави платформи.
Някои твърдят, че безсървърните модели са се появили наскоро и не е имало време да се стандартизира работата им. Но те не са толкова нови, колкото вече споменах, и много други облачни технологии, като контейнери, вече станаха много по-удобни благодарение на разработването и широкото внедряване на добри стандарти.
Производителност
Общата изчислителна производителност на безсървърните платформи е трудна за измерване, отчасти защото доставчиците се стремят да запазят информацията в тайна. Повечето твърдят, че функциите на отдалечените, безсървърни платформи работят толкова бързо, колкото и на вътрешните сървъри, с изключение на няколко неизбежни проблема с времето за забавяне.
Въпреки това отделни факти свидетелстват за обратното. Функции, които преди не са се изпълнявали на определена платформа или не са се изпълнявали за известно време, изискват известно време за инициализация. Вероятно това е свързано с факта, че техният код е пренесен на по-малко достъпен носител на данни, въпреки че – както и с бенчмарковете – повечето доставчици няма да ви кажат за преноса на данни.
Разбира се, има няколко начина да се заобиколят тези проблеми. Един от тях е оптимизацията на функциите за всеки облачен език, по който работи вашата безсървърна платформа, но това малко подкопава твърдението, че тези платформи са „гъвкави“.
Друг подход е да се осигури редовно изпълнение на критично важни за производителността програми, за да останат "свежи". Този втори подход, разбира се, малко противоречи на твърдението, че безсървърните платформи са по-икономични, защото плащате само за времето на работа на вашите програми. Облачните доставчици внедриха нови начини за намаляване на студените стартирания, но много от тях изискват "масштабиране до един" (scale to one), което подкопава първоначалната стойност на FaaS.
Проблемът с "студеното стартиране" може частично да се реши чрез стартиране на безсървърни системи самостоятелно, но това е свързано с собствени разходи и остава нишов вариант за добре обезпечени екипи.
Не можете да стартирате цели приложения
Накрая, може би най-важната причина за това, че безсървърните архитектури няма да заменят традиционните модели в близко бъдеще: те (обикновено) не могат да стартират цели приложения.
По-точно, това не е икономически целесъобразно. Вашият успешен монолит вероятно не си заслужава да бъде преобразуван в набор от четиридесет функции, свързани с осем шлюза, четиридесет опашки и дузина екземпляри на БД. Поради тази причина безсървърното е по-подходящо за нови разработки. Практически никое съществуващо приложение (архитектура) не може да бъде пренесено. Можете да мигрирате, но ще трябва да започнете от нулата.
Това означава, че в подавляващото мнозинство от случаите безсървърните платформи се използват като допълнение към вътрешните сървъри за изпълнение на задачи, изискващи голямо изчислително натоварване. Това много силно ги отличава от другите две форми на облачни технологии - контейнери и виртуални машини, които предлагат цялостен начин за извършване на отдалечени изчисления. Това илюстрира една от трудностите при прехода от микросервизи към безсървърни системи.
Разбира се, това не винаги представлява проблем. Възможността периодично да се използват огромни изчислителни ресурси, без да се купува собствена техника, може да донесе реални и дългосрочни ползи за много организации. Но ако някои приложения се намират на вътрешни сървъри, а други на безсървърни облачни архитектури, управлението преминава на ново ниво на сложност.
Да живее революцията?
Въпреки всички тези оплаквания, аз не съм против безсървърни решения като такива. Честна дума. Просто разработчиците трябва да разберат — особено ако за първи път изследват безсървърни модели — че тази технология не е директна замяна на сървърите. Вместо това се запознайте с нашите съвети и ресурси за и решете как най-добре да приложите този модел.
Източник: habr.com
