Serverless-архитектура сегодня: как бессерверные решения меняют разработку
Привет, Хабр! В комментариях к статьям из нашего хаба часто спорят: полезна ли Serverless. Хочу поднять флаг миротворца — и сказать, что бессерверная технология меняет весь рабочий процесс и взгляд на разработку. Для этого есть несколько причин.
Serverless смещает оплату в сторону подхода pay-as-you-go: вы платите столько, сколько израсходовано процессорного времени (плюс-минус 100 мс). Вы не ждёте запуска сервера, не распределяете нагрузку и не заморачиваетесь с техобслуживанием. Задача написана — задача исполнена. С другой стороны, возникают проблемы холодного старта, а многим проектам не подходит отсутствие чёткого контроля контейнера. В этой статье я расскажу, в каких именно случаях может пригодиться Serverless и когда к ней надо присмотреться.
От микросервисов к бессерверности
Бессерверные технологии функционируют по принципам микросервисов. Сперва в глаза бросаются сходства — управление на основе событий. В обеих архитектурах используют автономные модули, которые запускаются для исполнения конкретных задач в логических контейнерах и скрыты от глаз конечного пользователя.
Разница в том, что микросервисы работают по системе «запрос-ответ». В Serverless же функции однонаправленные (только запрос или только ответ) и ставятся в очереди. Вместо одной прокси-функции в Serverless используются комплекс однонаправленных элементов. Если есть баг, приложение не упадёт, а не выполняться будет только одна функция вместо всего набора. Ошибку в этом случае легче найти и поправить.
Микросервисы также приходится масштабировать вручную при резком всплеске нагрузки. Даже если есть настройка автомасштабирования, с каждым сервисом приходится работать отдельно, задавая нужные параметры. Такой проблемы с Serverless нет — головная боль уходит провайдеру.
Набор микросервисов — это ещё не бессерверность. У Serverless свои преимущества, а работая по логике микросервисов, их очень просто упустить. Многие попались на эту удочку.
Лего для взрослых: как с помощью Serverless собрать любой проект
Создать сервис микроблогов? Да пожалуйста! Трекинг пульсометрии? Подержите моё пиво. Не обязательно смотреть в сторону масштабных проектов — тут вот недавно даже голосовую запись к врачу организовали.
Для простых ботов или микросервисов не обязательно вводить сразу все запланированные функции в приложение. Можно начать и добавлять по мере расширения. Масштабирование происходит автоматически и практически неограниченно.
Бессерверные технологии позволяют быстро интегрироваться в уже существующее приложение: на этот случай практически все платформы предоставляют API (через REST или очереди сообщений), с помощью которых можно разрабатывать дополнения независимо от ядра приложения.
Serverless, микросервисы, облака: что общего у ворона и письменного стола
Бессерверные технологии наследуют качества как облачных сервисов, так и микросервисов в целом.
В одах облакам всегда звучит примерно следующее: не нужно закупать оборудование, подбирать подходящее помещение и нанимать системного администратора — и хорошо, если только одного. А оплата идёт по мере использования.
Микросервисы любят за упрощённый внутренний код для простых функций (FaaS наше всё), быстрый оборот из-за возможности изменять и добавлять код по частям, не беспокоясь о том, упадёт ли проект целиком, и безграничный горизонтальный рост.
Это основы. А в чем вообще преимущества Serverless?
Изучение основ использования бессерверных технологий проходит проще и быстрее, чем обучение полноценной DevOps-разработке. Чем входной порог ниже, тем легче найти подходящего специалиста и тем скорее можно заняться непосредственно самим проектом.
Не нужно высчитывать пропускную потребность самостоятельно: бессерверные решения автоматически масштабируются вместе с поступающим трафиком.
Нет необходимости настраивать и поддерживать Kubernetes или контролировать состояние контейнеров. Правда, стоит быть внимательнее к конфигурации, иначе есть риск оказаться на грани банкротства, как случилось с разработчиками сервиса Announce.
Принципы взаимодействия бессерверных технологий с контейнерами напоминают докер — и то и другое отлично подходит для работы с микросервисами. Бессерверные технологии экономят время и нервы тем, кто не хочет беспокоиться об архитектуре, зато докер обеспечивает независимость от поставщика услуг и абсолютный контроль проекта на любой стадии. Что выбрать? Зависит от приоритетов — платформа ShoutOUT, например, перешла с докера на бессерверные технологии, чтобы снизить затраты и решить вопросы своего масштабирования и не только.
Где Serverless не подходит
Чаще всего критикуют холодный старт. Ради экономии ресурсов провайдер отключает функции, которые не вызывались в течение некоторого времени, поэтому при новом запуске функции провайдеру приходится включать её заново — и это вызывает задержку в несколько миллисекунд или даже секунд. Об этом можно почитать здесь.
Проблема решается несколькими способами — к примеру, можно запускать функции с некоторой периодичностью, чаще запускать сервис или держать часть контейнеров запущенными всё время, что сделает возможную задержку практически неощутимой… Или поддерживать минимальный размер пакетов для развёртывания — чем они меньше, тем быстрее загрузка. Некоторые провайдеры предлагают создание гибридной инфраструктуры, другие используют систему мониторинга, которая помогает оптимизировать процесс холодного запуска функций.
Как метод решения порой используется распределённая трассировка — например, AWS X-Ray. AWS X-Ray помогает анализировать приложения во время разработки и на стадии развёртывания, благодаря чему легче определить уровень производительности и найти ошибки, которые препятствуют его повышению.
При работе с Serverless важно сразу определиться с языком программирования, потому что набор поддерживаемых языков у всех провайдеров разный. К примеру, AWS поддерживает Java, Go, PowerShell, Node.js, C#, Python и Ruby, а Yandex.Cloud использует Python, PHP, Go, Node.js и Bash.
Вместе с тем AWS Lambda и Azure Functions дают возможность запуска на неподдерживаемых языках. Парадокс! Serverless продвигается как архитектура, состоящая из модулей, которые могут не так уж часто запускать, а они их не так уж часто пишут на распространённых языках программирования.
Проблема ограничений
Происходит привязка к поставщику облачных услуг. Сменить его с уже написанным приложением — дело сложное и трудоёмкое. Но возможное, и в нашем telegram чате мы обсуждаем такие случаи. На операционном уровне провайдеры не похожи, практически нет стандартизации, но по факту все ориентируются на крупных провайдеров — особенно тех, что предлагают совместимости. Например, Yandex.Cloud отлично сочетается с AWS и может использовать в числе методов интеграции HTTP API Amazon S3, SQS и DynamoDB. Помимо кода, приложения связаны с хранилищем, специфическим строением очереди и так далее. Во многих случая можно переместить не только функции. Хотя иногда проще написать новый продукт.
В качестве особенностей внесерверных платформ также упоминают отсутствие целостности приложения из-за дробления на автономные микросервисы. С одной стороны, Serverless пользуется плюсами микросервисов — структура позволяет быстрее выпускать обновления и дополнения, а ошибка в одном её фрагменте не приведёт к тому, что весь проект прекратит работу. С другой стороны, это означает, что уже готовый монолит приложения переносить на Serverless попросту слишком дорого и затратно. Бессерверные структуры сейчас часто служат как дополнение к монолиту, а не единый, готовый продукт.
Кроме того, как уже упоминалось, есть особенности, связанные с ограниченным доступом. Serverless предоставляет меньший контроль над вычислительными ресурсами: нельзя подключиться по SSH к вычислительным инстансам и выполнить настройки вручную.
Разница между провайдерами
Так как Serverless появилась на рынке относительно недавно и сильно зависит от поставщика, у каждого сервиса есть свои особенности, которые уже описывали на Хабре.
Amazon Web Services
Amazon Web Services считается самым большим и продуманным сервисом, а Amazon Free Tier позволяет начать совершенно бесплатно, и на Хабре рассказывали об опыте работы с этой платформой:
Основы Serverless-приложений в среде Amazon Web Services
Цены и затраты на Serverless: AWS Lambda
Microsoft Azure
Облачные службы Microsoft включают более двухсот различных решений. Можно использовать в любых непонятных ситуациях: например, чтобы интегрировать приложение Slack в качестве Serverless-бэкенда.
Google Cloud
Инфраструктура Google Cloud, которую платформа предлагает клиентам, точно так же используется для собственных продуктов Google, например Google Search и YouTube. Это внушает доверие, но платформа отказалась от обратной совместимости — и это приводит к некоторым любопытным последствиям. Ещё можно почитать про разбор вычислительного стека Google Cloud Platform.
Firebase
В 2018 году сервисы Firebase считались чуть ли не стандартом в индустрии разработки мобильных приложений. Сейчас их вспоминают… потому что они входят в пакет поддержки Google Cloud Platform. Интересные ссылки:
Firebase снова стала предметом исследований
ХабрВведение в Firebase: пишем простое социальное приложение на Swift
Yandex Cloud Functions
Классический представитель бессерверных технологий. Легко интегрируется с другими сервисами в Yandex.Cloud, так что, если захотите создать навык для Алисы — это ваш выбор. Интересные ссылки:
Интернет вещей в «Яндекс.Облаке»: как устроены сервисы Yandex IoT Core и Yandex Cloud Functions
Куда идёт Serverless
Современная разработка требует быстрого внедрения новых функций, Serverless же позволяет быстро создавать и сразу тестировать новые фичи. Это даёт возможность оперативно добавлять к существующим монолитам новые функции.
Бессерверные технологии хороши в условиях пиковых нагрузок благодаря автоматическому масштабированию и модерации внешних взаимодействий — при необходимости их можно попросту отрезать от основного сервиса. Так приложение Auto.ru для тестирования по ПДД успешно выдержало участие более ста тысяч человек.
Высокую нагрузку создаёт не только наплыв пользователей, но и коннект с большим количеством устройств — и разработчик из Сиднея использовал бессерверные решения для реализации приложения, в котором как раз необходима интеграция с несколькими сторонними поставщиками, а также возможность подключения к устройствам IoT для обработки данных в полевых условиях.
Интернет вещей не лучшим образом поддерживает монолитные конструкции, поэтому Serverless в этом случае — отличный выбор. В будущем бессерверные технологии будут всё шире использоваться при работе с интернетом вещей, искусственным интеллектом, мобильными приложениями — везде, где монолитные конструкции скорее минус.
Лично я не жду, что процесс будет быстрым. Массовых отказов от старой архитектуры в ближайшее также не предвидится. Чтобы работать с Serverless, нужно не просто выучить пару новых штук, а изменить своё мышление под новый тип разработки. О новых шагах Serverless-сервисов, подробностях и нюансах разработки можно узнать в сообществе Serverless в Telegram: Yandex Serverless Ecosystem.
