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