Бессерверный режим имеет подводные камни. Вот как их можно избежать.

1656629531 besservernyj rezhim imeet podvodnye kamni vot kak ih mozhno izbezhat

Николя Дао

oqbuJP3C3Gww0qSIAUrUm3zo8H4ku1558rBV
Фотография Луиса Ханфилаке на Unsplash

В этом сообщении я поделюсь уроками, которые я получил за прошлый год, используя бессерверное обеспечение для создания мобильных и веб-приложений для технической консультации в Сиднее. Для каждого недостатка я тоже буду рекомендовать одно или несколько решений.

1. FaaS – Ограничение пула подключений

Разговоры о FaaS не часто упоминают это ограничение. Облачные провайдеры продают FaaS как решение, которое может нескончаемо масштабироваться. Хотя это может относиться к самой функции, большинство ресурсов, от которых зависит ваша функция, нельзя бесконечно масштабировать.

Количество одновременных подключений, поддерживаемых вашей реляционной базой данных, является одним из таких ограниченных ресурсов. Неудобство FaaS к объединению соединений делает эту проблему столь серьезной.

Действительно, как я уже упоминал ранее, каждый экземпляр вашей функции живет в своей изолированной среде без состояния. Это означает, что когда он подключается к реляционной базе данных (например, PostgreSQL, MySQL, Oracle), он, скорее всего, должен использовать пул соединений во избежание повторного подключения туда и обратно к вашей базе данных.

Ваша реляционная база данных может управлять только определенным количеством одновременных подключений (обычно по умолчанию 20). Создание более 20 экземпляров вашей функции быстро исчерпает соединение с базой данных, исключая доступ к ней другим системам.

По этой причине я рекомендую избегать любого FaaS, если ваша функция нуждается в связи с реляционной базой данных с помощью пула соединений. Если вам нужно использовать пул подключений, то доступны несколько вариантов:

2. FaaS – отсутствие поддержки WebSockets

Это вроде бы очевидно. Но для тех, кто думает, что может получить торт и съесть его, вы не можете надеяться поддерживать WebSocket в системе, по своей природе эфемерной. Если вы ищете бессерверный WebSocket, вместо этого вам нужно использовать BaaS, например Zeit Now.

Кроме того, если вы пытаетесь создать бессерверный GraphQL API, можно использовать подписки (которые полагаются на WebSockets) с помощью AWS AppSync. Замечательная статья, в которой подробнее объясняется этот случай использования, это «Запуск масштабированной и надежной конечной точки GraphQL без сервера».

3. FaaS – холодный старт

Решения FaaS, такие как AWS Lambda, продемонстрировали огромные преимущества при решении задач Map-Reduce (например, использование AWS Lambda для масштабного сжатия изображений). Однако, если вы пытаетесь обеспечить быстрый ответ на такие события, как HTTP-запросы, вам нужно будет принять во внимание время, необходимое для разогрева.

Ваша функция живет в виртуальной среде, которую нужно создать для увеличения на основе получаемого ею трафика (то, что вы, естественно, не контролируете). Этот процесс создания занимает несколько секунд, и после того, как ваша функция простаивает через низкий трафик, его нужно будет создать снова.

Я узнал об этом за свой счет при развертывании относительно сложной REST API отчетности на Google Cloud Functions. Этот API был частью рефакторинга микросервиса, чтобы сломать наш обширный монолитный веб-API. Я начал с конечной точки с низким трафиком, что означало, что эта функция была часто в состоянии ожидания. Отчеты, которые создавались этим микросервисом, стали медленными при первом доступе.

Чтобы решить эту проблему, я перенес наш микросервис из Google Cloud Function (FaaS) на Zeit Now (BaaS). Эта миграция позволила мне постоянно поддерживать как минимум один экземпляр (подробнее о Zeit Now в моей следующей публикации: Почему мы любим Zeit Now и когда использовать его через FaaS).

4. FaaS – долгоживущие процессы, не беспокойтесь!

AWS Lambda и Google Cloud Functions могут работать не более 5 и 9 минут соответственно. Если ваша бизнес-логика является долговременной задачей, вам придется перейти к BaaS, например Zeit Now.

Дополнительные сведения об ограничениях FaaS см. в квотах AWS Lambda и квотах Google Cloud Functions.

5. BaaS & FaaS – потеря контроля над инфраструктурой

Если ваши требования к продукту требуют определенной степени контроля над вашей инфраструктурой, то бессерверный режим, скорее всего, оставит вас в тупике. Примером таких проблем могут служить:

  • Оркестровка развертывания микросервисов. Получение множества бессерверных микросервисов скоро станет кошмаром развертывания, в особенности если им необходимо управлять версиями в целом либо за доменом.
  • Контроль жизненного цикла каждого сервера для экономии издержек.
  • Наличие долгосрочных задач на нескольких серверах.
  • Управление точной версией базовой ОС сервера или установка определенных библиотек, необходимых для программы.
  • Контролируйте точную георепликацию вашей программы или данных для обеспечения согласованной и быстрой работы во всем мире (есть способы преодолеть это в некоторых сценариях. Ознакомьтесь с созданием бессерверного многорегионального бекенд-решения активный-активный за час).

Бессерверный режим может оказаться недостаточным во всех вышеприведенных случаях использования. Однако, как я уже обсуждал ранее, Serverless является только расширением PaaS. Чтобы максимально сосредоточиться на написании кода, а не слишком беспокоиться о масштабируемости и надежности основной инфраструктуры, используя новейшие стратегии контейнеризации PaaS, такие как Google Kubernetes Engine, можно приблизить вас к тому, что может предложить Serverless.

6. BaaS & FaaS – Соответствие и безопасность

Serverless разделяет все обычные жалобы, связанные с облаком. Вы отдаете контроль над своей инфраструктурой одному или нескольким третьим лицам. В зависимости от поставщика, Serverless может обеспечивать или не обеспечивать соответствующие SLA и уровни безопасности для вашего бизнес-случая.

Бессерверный доступ или нет с точки зрения соответствия и безопасности на самом деле зависит от вашего конкретного случая. Многие статьи подробно обсуждают эту тему (например, Состояние безопасности без серверов).

Вывод

Бессерверный режим – это не идеальный шар. Прибыль, которую вы можете получить от этого, зависит от вашего знания. Хорошая часть заключается в том, что барьер для входа настолько низок, что вы должны быстро овладеть.

ДАЛЬШЕ…

Конечно, бессерверный режим ограничен. Они есть во всех технических решениях. Вопрос в том, как мы их преодолели. В своем следующем сообщении я напишу о предложениях, которые мы с моей командой разработали для решения этих ограничений: Почему мы любим Zeit сейчас и когда использовать его через FaaS.

Следите за мной на Medium — Nicolas Dao — если вам интересно, что будет дальше:

Текущие публикации в этой бессерверной серии:

Предстоящие публикации в серии:

  • Почему мы любим Zeit сейчас и когда использовать его через FaaS
  • Бессерверная архитектура, управляемая событиями: естественный подход
  • Как управлять обратным давлением с помощью бессерверного доступа?
  • GraphQL на сервере менее чем за 2 минуты

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *