Что, почему и как перейти на бессерверную версию!

Что такое бессерверное?

Нет серверов? Нет. Есть еще серверы. Бессерверные системы - это просто новая парадигма вычислений, которая абстрагирует сложность, связанную с управлением серверами. Как разработчик вы будете сосредоточены на написании логики приложения, не беспокоясь о конфигурации или работе сервера. Об этом полностью позаботится облачный провайдер. Вы пишете и развертываете код как функцию, а затем начинаете ее использовать. Так просто. Не нужно запускать экземпляры или выбирать операционные системы. Также не нужно беспокоиться о балансировке нагрузки или простоях. Об этом в Serverless позаботится облачный провайдер.

Почему бессерверный?

Низкая стоимость: в бессерверном режиме нет запущенных экземпляров. Код / функция будет запускаться только при ее вызове. Таким образом, с вас будет взиматься плата только за те ресурсы, которые он потребляет при выполнении. Время простоя не начисляется. Это одна из основных причин перехода на бессерверную версию.

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

Масштабируемость. Традиционно для обеспечения масштабируемости приложения для входящего трафика необходимо запускать несколько экземпляров приложения и балансировщик нагрузки для маршрутизации потока трафика. Кроме того, очень сложно справиться с внезапными колебаниями движения. Для запуска дополнительных экземпляров может потребоваться время. Где, как и в случае с Serverless, он полностью обрабатывается провайдером. Для обслуживания пользовательского трафика может быть запущено любое количество экземпляров функции.

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

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

Начиная

Давайте разберемся, настроив бессерверную службу. В рамках статьи мы будем использовать AWS Lambda и API Gateway для создания службы с Node.js в качестве среды выполнения.

// Install serverless
npm install -g serverless
// Create a simple application for the serverless.
sls create --template aws-nodejs --path demo

Шаблон по умолчанию содержит два файла: serverless.yml и handler.js.. Файл yml содержит конфигурацию службы, такую ​​как поставщик, среда выполнения, функции, события http и т. Д.

service: demo
provider:
  name: aws
  runtime: nodejs8.10
functions:
  hello:
    handler: handler.hello
    events:
     - http:
         path: hello/test
         method: get

Эта базовая конфигурация при развертывании создает демонстрационную службу с функцией hello и конечной точкой http / hello / test для запросов GET.

handler.js экспортирует функцию hello с простым определением, как показано ниже.

module.exports.hello = (event, context, callback) => {
  const response = {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Welcome to the Serverless World !!'
    }),
  };
  callback(null, response);
};

Мы готовы развернуть сервис.

sls deploy --region ap-south-1 --stage development

Служба может быть развертыванием дает больше контроля, например развертывание в определенном регионе и в таких средах, как dev, test, uat, prod и т. д.

И Готово !! Сервис теперь доступен всему миру со следующим шаблоном URL.

https://<id>.execute-api.ap-south-1.amazonaws.com/<stage>/hello/test

Каждый раз, когда URL-адрес попадает, функция будет вызываться и отправлять ответ.

Итак, все ли мы готовы использовать бессерверную версию для всех приложений?

Может быть не всегда. Говоря о Serverless, мы часто слышим о «холодном запуске». Иногда решающим моментом становится выбор бессерверной архитектуры для приложения. Давайте разберемся, что это такое и как ее решить.

Проблема холодного старта

Когда функция вызывается в первый раз, она должна загружаться на некоторых серверах в облаке перед запуском, поскольку не будет никаких запущенных экземпляров. Итак, общее время, которое требуется = (время загрузки) + (время выполнения). Из-за этой функции запуска в первый раз требуется больше времени. Это явление называется холодным запуском. Любой запрос, сделанный позже, не требует запуска, поскольку функция уже загружена и готова к запуску.

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

Примечание. Все значения представляют собой общее время выполнения запроса в миллисекундах. А инструмент, с помощью которого выполняются эти тесты, доступен здесь.

Тест 1: параллелизм

Это поясняет, что каждый первый параллельный запрос - это холодный старт. Короче говоря, холодный старт не для первого вызова вашей функции, он происходит при каждом первом параллельном вызове.

Тест 2: Функциональная память (для работы требуется память)

Выделение большего объема памяти улучшило результаты. Холодный старт значительно лучше для функций с большим объемом памяти.

Тест 3: размер кода

Функция с большим количеством кода заняла немного больше времени холодного старта, чем меньшая.

Примечание. Большие пакеты npm были импортированы для увеличения размера пакета приложения, но не использовались. Функция оставалась такой же, как и в приведенных выше тестах.

Тест 4: разные времена работы

У каждой среды выполнения разные холодные старта. Такие среды выполнения, как Node.js, Go работали намного лучше, чем Java, в отношении холодного запуска. (Кстати, я не предвзято отношусь к какой-либо среде выполнения 😄).

Как избежать?

Это действительно зависит от типа приложения. Для таких приложений, как портфолио пользователей, холодный старт не проблема. Что касается таких приложений, как электронная коммерция с крупными пользователями, действительно важно как можно быстрее обработать запрос.

Сохраняйте функции в тепле: холодный старт для теплых функций отсутствует. Итак, сохраняйте функции в тепле с помощью таких сервисов, как AWS CloudWatch. Поскольку мы поняли, что холодный старт происходит для каждого параллельного запроса, нам нужно понимать, сколько экземпляров должно быть теплым. Например, предположим, что некоторая продажа происходит в 14:00, и ожидаемый трафик будет составлять 10 000 одновременных запросов, эти многочисленные экземпляры функций можно предварительно подогреть за пару минут до продажи.

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

Сохраняйте оптимальный код. Функция запускается с большим количеством кода медленно. Всегда важно поддерживать оптимальный размер кода. Удалите ненужные зависимости.

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

Перейти без сервера !! 🤘

Демоверсии, использованные в статье, доступны по адресу: https://github.com/madhusudhand/serverless-demo.

Github: https://github.com/madhusudhand

Twitter: https://twitter.com/madhudollu