Новая игрушка — бессерверное приложение

Способов, как задеплоить своё приложение, становится всё больше и больше. Не успели остыть Докер и его контейнеры, как появилась ещё одна идея: а что, если вместо упаковывания кусков приложения по контейнерам, мы отправим его логику прямиком в облако? Глупость ведь сказал ведь, правда? Но при этом практически у всех крупных провайдеров появилась такая штука как «функция-как-сервис» (FaaS), при помощи которой (а так же объектного хранилища и облачной базы данных) можно собрать полностью работоспособное приложение прямо в облаке — бессерверное приложение.

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

Переход от серверного к «бес-«

В классическом веб-приложении сервер по-любому был. Мы его нагружали статическим HTML/JS контентом, довешивали API, а на соседний хост устанавливали реляционную или документную базу данных и счастливо ждали зарплаты.

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

Но вот какая штука вырисовывается. Раз уж всё живёт в облаке, то почему бы вместо своей базы не начать использовать облачную, от провайдера? Тот же Amazon (DynamoDB) или Google (Cloud SQL) поддерживают и реляционные, и документные базы данных. Провайдер же будет отвечать за системные ресурсы, зависимости и обновления. Зачем это делать самим?

Более того, нам даже для статического контента контейнер не нужен. Объектные хранилища вроде Amazon S3 или Google Storage существовали ещё при советской власти, и контент вполне можно хранить и раздавать оттуда, и платить только за трафик и место.

Наконец, от контейнера для API, в принципе, мы тоже можем избавиться. Тот же Amazon Lambda, Google или Azure Cloud Functions могут хостить отдельные функции, и наш API можно положить прямо туда.

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

Зачем вообще это нужно

Самая приятная причина — деньги. Арендовать сервер, реальный или виртуальный, стоит денег. Работает приложение, или нет, загружает оно ресурсы на 100%, или, как мой блог, на 1-3 % — мы платим за железо одинаково и всегда. А вот FaaS модель оплачивается за количество выполнений функции (и/или за время выполнения). Пользуется кто-то нашим приложением — платим. Не пользуется — не платим. Всё просто.

Вторая приятная причина — масштабируемость. Бессерверные функции не хранят состояние между выполнениями. То есть они могут что-то записать в базу или какой-нибудь сервис, но так как функция не является методом класса и не имеет доступа к глобальным переменным, то в каком-то отношении она — чистая функция. А чистые функции  масштабируются — полный вперёд. Провайдеру вообще без разницы, запустить одну функцию или сто её копий.

Для некоторых задач бессерверный подход подходит вообще идеально. Вот, например, нужно мне раз в 10 минут проверять, дышит ли ещё продакшен сервер, или нет. Если не дышит, я бы с удовольствием получил по этому поводу письмо. В обычной жизни пришлось бы делать cron задачу, искать сервер, на который можно её закинуть, настраивать SMTP, и надеяться, что этот сервер случайно не удалят. А тут сделал облачную функцию, привязал её к облачному генератору событий с одной стороны, к облачному же сервису отправки писем с другой, и вот оно, счастье.

Чего стоит бояться

Во-первых, этому нужно учиться. Более того, тому же AWS Lambda, который является ветераном на бессерверном рынке, всего три года от роду. Из-за этого всё ещё не совсем ясно, как правильно разрабатывать такие приложения, чего стоит избегать, как подружить такую архитектуру с git, как должен выглядеть тестовый сервер, как тестировать эту штуку в принципе. Может, самое важное, куда ставить брейкпоинты и как это всё правильно дебажить?

Также не совсем очевидно, как будет масштабироваться разработка таких проектов. Понятно, что TODO приложение мы напишем без проблем. А если что-нибудь по-крупнее? Фейсбук там можно написать?

Ну и, наконец, привязка к провайдеру. Если с контейнерами и виртуальными машинами мы могли хлопнуть дверью и уйти из AWS в Azure (чтобы через месяц вернуться назад), то с serverless такой трюк не пройдёт. Тут подразумевается более тесная интеграция с облачными сервисами, которые у всех хоть и делают то же самое, но будут отличаться. Нельзя же просто так скопировать AWS функцию и вставить её в Google.

Итого

Хотя, предложи мне на работе сделать бессерверным какой-нибудь кусок приложения, я бы ответил «а давай подождём», сама идея мне очень нравится. За последние годы сложилась такая тенденция, что от приложения отшелушивалось всё то, что ему вроде как нужно для работы, но при этом самим приложением не является. Сначала реальные сервера заменились виртуальными, и мы перестали заниматься железом. Потом контейнеры оградили приложение от операционной системы и других приложений, и окружение стало не таким важным. В бессерверном же приложении кроме него самого ничего вокруг нет в принципе. И это, кажется, такой рубеж, дальше которого уже не прыгнуть. Осталось только понять, что же со всем этим богатством делать.