Бессерверная архитектура предоставляет гибкие возможности для удовлетворения постоянно меняющихся требований бизнеса без необходимости погружения в такие тонкости, как работа операционных систем, серверы инициализации, адресация и емкости хранилища, вычислительные мощности и другие технические аспекты, которые являются глубинной прослойкой между пользователем и приложениями. В бессерверных вычислениях выделением машинных ресурсов динамично руководит облачная платформа, предоставляя их по требованию.
Низкий барьер для входа
Запуск кода в бессерверной среде относительно прост. Чтобы получить представление о том, как запрограммировать его на работу в экосистеме промышленного уровня, достаточно взять любое учебное пособие и следовать его рекомендациям. Обучение основам развертывания бессерверных окружений во многом проще, чем приобретение базовых знаний DevOps-разработки, более того, многие навыки гибкой разработки вообще не нужны для внедрения бессерверной архитектуры. К таким, например, относятся навыки по управлению серверами, конфигурирование или патчинг. Низкий барьер для входа — одна из особенностей бессерверных вычислений.
Это значит, что для их освоения разработчикам нужно меньше времени, чем для ознакомления с другими ИТ-архитектурами, а общая кривая обучения по мере изучения становится круче (освоение нового материала дается легче). В результате к бессерверным проектам подключается все больше разработчиков, внося в них эффективный вклад. Возможность быстрого освоения новых навыков — одна из причин того, что проекты выходят на рынок быстрее.
С каждым годом ИТ-инфраструктура становится сложнее, наполняясь не только физическим оборудованием, но и виртуальным, в т. ч. виртуальными машинами, контейнерами, облачными приложениями, и увязать все это хозяйство не так просто. Не теряют своего значения и традиционные инструменты, такие как «инфраструктура как код», управление журналами событий, мониторинг, а также работа в сети, и следует определить, как каждый из этих элементов будет взаимодействовать с бессерверным окружением. Если разработчик обладает отличными от бессерверной навыками разработки, ему придется овладеть некоторыми ее особенностями.
Одной из частых ошибок некоторых разработчиков является то, что они не связывают бессерверную архитектуру с разработкой кода. Они предполагают, что поскольку имеют дело только с функциями, то дизайн кода не имеет значения. На самом деле схемы разработки, такие как SOLID (объектно-ориентированное программирование), по-прежнему применяются, поэтому передача на аутсорсинг кода для собственной бессерверной платформы невозможна. Несмотря на то, что бессерверное окружение позволяет довольно просто собрать и выгрузить код в облако, делать это не рекомендуется, лучше воспользоваться методами непрерывной доставки — они по-прежнему актуальны для бессерверной архитектуры.
Безхостовость (hostless)
Отсутствие прямого взаимодействия с серверными кластерами — это суть бессерверной архитектуры. Сегодня имеется широкий выбор хостов, где можно установить и запустить сервис — будь то физические машины, виртуальные машины, контейнеры и т. д. — не прибегая к помощи серверов. Чтобы обозначить это явление, помимо термина «бессерверный» можно прибегнуть к его синониму — «безхостовый» (hostless), или децентрализованная архитектура. Одним из ее преимуществ являются значительно меньшие эксплуатационные расходы по обслуживанию парка серверов — они на порядок меньше, чем суммы, требуемые для обслуживания традиционного ИТ-окружения.
Предприятию не нужно беспокоиться об обновлении серверов — патчи безопасности будут устанавливаться автоматически. Безхостовое окружение позволяет отслеживать некоторые характеристики работы приложений, что связано с тем, что большинство используемых базовых сервисов перестанут отображать информацию о процессоре, памяти, размере диска и т. д. и поэтому администраторам более не нужно разбираться в низкоуровневых тонкостях архитектуры. Однако вместо них придется учиться настройке архитектуры. К примеру, AWS DynamoDB предоставляет базовые возможности для мониторинга и настройки возможностей чтения и записи. Сложность здесь состоит в том, что обладание этими навыками не поможет на других бессерверных платформах.
Что касается особенностей AWS Lambda, то она налагает ограничение на число одновременных запросов (событий), а не на количество ядер процессора. Но на этом особенности этой бессерверной службы не заканчиваются: к примеру, при изменении объема выделенной памяти Lambda изменит количество процессорных ядер. Если применять для тестирования производительности и коммерческих сред одну учетную запись AWS и если тестирование производительности неожиданно израсходует лимит одновременного выполнения событий, то работу Lambda можно приостановить. Как известно, AWS хорошо документирует ограничения для каждой из своих служб, поэтому прежде, чем принимать архитектурные решения, нужно убедиться в их правильности.
Нужно заметить, что традиционные средства защиты для безхостовой архитектуры недееспособны, в ней возможно применение множества векторов атаки. Тем не менее, для защиты кода приложений предприятия могут прибегать к собственным мерам обеспечения безопасности. AWS ранее выпустил циркуляр, где расписывается зона совместной ответственности, к примеру, организации несут ответственность за защиту своих данных, если они содержат конфиденциальную информацию. Более подробную информацию о векторах атак на бессерверные платформы можно почерпнуть в инструкции Serverless Top 10, которую выпустил открытый проект обеспечения безопасности веб-приложений (OWASP).
Хотя безхостовое окружение значительно уменьшает операционные издержки, стоит отметить, что в некоторых случаях приходится изменять настройки базового сервера. Это связано с тем, что приложение может полагаться на собственные библиотеки и после обновления ОС нужно убедиться, что они не вышли из строя.
Невозможность сохранения состояния
Функции как сервис (functions as a service, FaaS) — эфемерны, поэтому вычислительные контейнеры не могут хранить в памяти исполняемый код приложений — платформа будет создавать и уничтожать их автоматически. Таким образом, невозможность сохранения состояния (stateless) является еще одним признаком бессерверной архитектуры. И это большой плюс для горизонтального масштабирования приложений.
Суть stateless заключается в том, что пользователь не может сохранить промежуточные состояния приложения. Благодаря этому можно горизонтально масштабировать больше экземпляров, не беспокоясь о состоянии приложения. Примечательно, что при этом резко сокращается риск размножения ошибок. За исключением, конечно, вычислительных контейнеров — их можно разворачивать повторно с сохранением состояния, здесь следует быть осторожными.
С точки зрения разработки приложений в бессерверной архитектуре нельзя использовать технологии, требующие отслеживания состояния, поэтому бремя управления состояниями ложится на гостевую систему. Это исключает возможность запуска HTTP-сеансов, поскольку безхостовая платформа не сопрягается с традиционным веб-сервером с постоянным файловым хранилищем. Если требуется применить технологию типа WebSocket (протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером) в режиме реального времени, придется подождать, пока она станет поддерживаться соответствующим бэкэндом в качестве сервиса (Backend as a Service) или найти обходной путь.
Эластичность
Безхостовая система обладает свойством эластичности. Большинство бессерверных сервисов предназначены для задач высокой степени гибкости, где их можно масштабировать с нуля до максимально допустимого числа, а затем обратно. Управление ими проводится в основном в автоматическом режиме. Масштабируемость немыслима без гибкости, и это едва ли не основной козырь бессерверной архитектуры, который еще более ценен тем, что подавляющее большинство операций не требуют ручного управления. К примеру, администраторам не нужно распределять вычислительные ресурсы, и, что не менее важно, заказчик будет оплачивать только те ресурсы, которые он реально потребляет — это заметно снизит эксплуатационные расходы (при условии, что установлен шаблон минимального потребления ресурсов).
Не исключена вероятность, что пользователю требуется интегрировать бессерверную архитектуру с гораздо менее эластичными унаследованными системами. В этом случае поджидает опасность вывести их из строя, поскольку они не могут масштабироваться так же быстро, как безхостовая. Если нисходящие системы (состоящие из нескольких служб, вызывающих друг друга) являются для пользователя критическими важными, нужно придумать обходной маневр, к примеру, ограничить параллелизм AWS Lambda или применить очередность общения служб с нисходящими системами.
Эластичность бессерверной архитектуры значительно снижает шансы злоумышленников при атаках типа «отказ в обслуживании», однако делает ее более уязвимой для атак типа «отказ в кошельке». Их механизм состоит в том, что злоумышленник пытается взломать приложение, вынуждая превысить лимиты выделенных на учетную запись облачных ресурсов.
Чтобы предотвратить эту атаку, можно применить типовую защиту от DDoS — AWS Shield. Помимо этого не помешает установить AWS Budgets. С помощью панели управления затратами на AWS можно просматривать состояние расходов с начала месяца до текущей даты, точно определять, на какие сервисы приходится большая часть расходов, и получать общее представление о тенденциях изменения затрат. Если клиенту по каким-либо причинам не требуется высокая эластичность, он может установить для своего приложения ограничение, например, на параллелизм AWS Lambda.
Распределенность
Как уже говорилось, бессерверная архитектура не поддерживает устойчивое состояние приложения, все требования, предъявляемые организацией к хранению объектов, будут храниться в BaaS в виде комбинации, поэтому единиц развертывания и функций станет меньше привычного. Как следствие, бессерверная архитектура распространяется по умолчанию, интегрируясь с множеством компонентов через сеть. В готовом виде инфраструктура будет включать связанные службы, такие как аутентификация, база данных, распределенная очередь и так далее.
Помимо эластичности распределенные системы обладают другими преимуществами, в том числе высокой доступностью и географически распределенной базой данных, то есть когда поставщик облачных услуг теряет одну зону доступности, архитектура сможет использовать другие работающие зоны. Выбор архитектуры — это всегда компромиссное решение.
Как правило, каждая из бессерверных служб в облаке имеет свою собственную модель связности. Например, AWS S3 с помощью функции read-after-write предоставляет немедленную видимость и связность новых данных (PUT Object) для всех клиентов в букете S3. При выборе BaaS нужно проследить за тем, как они обеспечивают связность данных.
Принимаясь за внедрение безхостовой архитектуры нужно владеть распределенными методами доставки сообщений. Нужно понимать сложную проблему гарантированной доставки сообщений для распределенной очереди — сообщение может быть доставлено один и более раз (at-least-once). При ошибке доставки может быть предпринято несколько попыток отправить одно и то же сообщение. Поэтому могут возникнуть дубликаты, но потерянных сообщений быть не может. Этот способ сложнее чем at-most-once, поэтому AWS Lambda может быть вызвана более одного раза. Также надо разбираться в поведении распределенных транзакций.
Событийность
Бессерверные системы по своей сути являются системами, управляемыми событиями (event driven), и поэтому являются представителями cобытийно-ориентированной архитектуры. Это меняет подход к разработке, управлению и архитектуре. Многие BaaS, предоставляемые бессерверными платформами, поддерживают события в сторонних (клиентских) службах, которые частично компенсируют тот факт, что пользователи не обладают контролем за кодовой базой своих сервисов. По некоторым наблюдениям, cобытийно-ориентированная архитектура нравится командам разработчиков, но это еще не означает, что ее нужно внедрять. Как и в случае с эластичностью, ее можно отключить.
Событийность приносит много преимуществ. Во-первых, это слабая связь между компонентами архитектуры. Во-вторых, в бессерверной архитектуре легко добавить новую функцию, которая считывает изменения в хранилище BLOB-объектов (blobstore), но при этом добавление функции B не изменяет функцию A, что повышает согласованность функций. Наличие связности (когезионной функции) в архитектуре означает, что операцию — функцию B — при сбое можно повторить без дорогостоящего запуска функции A. Поставщики облачных услуг предлагают услуги по интеграции FaaS и BaaS. FaaS будет приводиться в действие с помощью уведомлений о событиях.
Недостатком событийной архитектуры является то, что она не дает целостного представления о системе в целом, что усложняет устранение неполадок. Облегчить эту проблему позволяет распределенная трассировка — это новая область в безхостовой архитектуре. Чтобы опробовать ее, можно воспользоваться AWS
Выводы
Аналитики, пользователи и скептики спорят о том, насколько большое значение имеет бессерверная технология. Является ли она эволюционной или революционной? Будет ли она применяться для выполнения большинства или лишь части приложений? Рынок еще в зачаточном состоянии, и ответов пока нет. Но шумиху вокруг технологии, интерес к ней и ее потенциальные преимущества игнорировать невозможно. Важнейшее отличие бессерверных платформ в том, что оплачивается ровно столько процессорного времени, сколько израсходовано, точность учета составляет плюс-минус 100 мс. При этом не нужно ждать запуска серверов и настраивать балансировку нагрузки — задания просто выполняются автоматически столько раз, сколько потребуется. Специалисты отмечают, что такие платформы быстрее, чем другие, позволяют разработчикам проверять идеи и выводить продукты на рынок.
Бессерверные вычисления не панацея, и у них есть свои недостатки. В частности, управлять крупномасштабными приложениями, работающими в бессерверном режиме, весьма сложно. Не хватает инструментов для координации выполнения групп функций. Слабо развито соответствующее ПО безопасности, мониторинга и оптимизации. И, наконец, бессерверные вычисления требуют от разработчиков иного подхода к созданию приложений.
Источник: ITWeek
