Поиск по сайту:

Что такое бессерверные вычисления и когда их следует использовать?


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

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

Бессерверные услуги — это широкая категория, но большинство услуг включают в себя три основных элемента:

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

Это делает бессерверную модель конкурентоспособной только за счет стоимости. Для таких сайтов, как Bustle, переход на AWS Lambda позволил сэкономить 84 % средств по сравнению со старой архитектурой. Масштабирование бессерверных решений гораздо более прямолинейно, поскольку вам не придется платить за отдельные экземпляры сервера.

PaaS против FaaS

Важно прояснить разницу между «бессерверными» моделями PaaS и FaaS, потому что маркетинг для каждого типа во многом одинаков.

Платформа как услуга (PaaS) исключает серверы, но не затрагивает ваш базовый код и не применяет какие-либо новые методы кодирования. Обычно это делается с помощью контейнеров, таких как Docker, где моментальные снимки вашего приложения можно очень быстро развернуть на нескольких серверах. С некоторыми сервисами, такими как AWS Fargate и Azure Container Instances, вам вообще не нужно беспокоиться о серверах, что делает их «бессерверными». С другими сервисами, такими как Heroku, вы по-прежнему платите за сервер, но вам не нужно беспокоиться о его настройке самостоятельно, а масштабирование между несколькими экземплярами легко.

Функция как услуга (FaaS) полностью исключает идею серверов. Вместо этого ваш код запускается, запускает быструю функцию и взимает плату за память и время вычислений, которые вы использовали. Модели FaaS реализуют идею «микросервисов», разбивая ваше приложение на составные части и разрабатывая каждую из них по отдельности. Это работает не во всех случаях, но когда это работает, это может значительно ускорить разработку и обслуживание по сравнению с традиционным «монолитным» дизайном приложений. AWS Lambda, Google Cloud Functions и Azure Functions — все это модели FaaS.

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

Где сияют микросервисы

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

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

Модель приложения на основе микрослужб разделяет все на отдельные службы. Они по-прежнему могут работать на одном компьютере, но, возможно, вы захотите упаковать их с помощью Docker для работы на отдельных серверах или масштабировать их в кластере с помощью Kubernetes. Это намного проще сделать, когда вы можете масштабировать одну часть отдельно от других.

Это может быть дополнительно разбито на поставщиков FaaS, где теперь эти строительные блоки могут быть отдельными функциями, а не целыми услугами. Например, у вас может быть функция автоматического изменения размера изображений для разных устройств, например, для которой Seattle Times использует Lambda. Вы можете создать отдельные функции для каждой конечной точки REST API и вообще отказаться от запуска сервера API.

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

Микросервисы не всегда проще

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

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

А чем больше сервисов, тем больше вещей нужно отслеживать, отлаживать и обслуживать. Если у вас небольшая команда разработчиков, попытка одновременно создать и исправить множество сервисов может оказаться непосильной задачей.

В частности, FaaS также обеспечивает привязку к поставщику. Хотя обычно вы можете взять образ Docker и развернуть его у другого провайдера, сборка вашего приложения на такой службе, как Lambda, вынуждает вас использовать Lambda только для размещения вашего приложения. Вы оказываетесь запертыми в экосистеме, и внезапно вы пишете не код JavaScript, а код Lambda. У вас по-прежнему есть контроль над тем, что вы пишете, поэтому его можно перенести на другой сервис, но отсоединиться от сервиса, на который вы полагаетесь, обычно сложнее, чем кажется.

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

Когда и когда не использовать бессерверные решения

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

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

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

AWS Lambda также очень полезен в сочетании с другими сервисами AWS. Функции Lambda можно запускать на основе действий в вашей инфраструктуре AWS, например автоматически запускать функцию, когда файл помещается в корзину S3. Если вы уже используете сервисы AWS, Lambda может стать отличным инструментом автоматизации.