Что такое Serverless Архитектура и в чём её преимущества?

Illustration of a person with wings holding a glowing bowl, connected by lines to flying birds around them, representing a network or communication concept.

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

Определение

Начнем с Вики-определения Serverless.

Serverless computing is a cloud-computing execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.

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

Function as a service (FaaS) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage application functionalities without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app.

В этих определениях собраны три основные черты того, что называют Serverless:

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

Области применения

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

Это случаи отложенных, или фоновых задач. Например:

создание дополнительных копий изображения после загрузки его на сайт;
создание бэкапа по расписанию;
асинхронная отправка уведомления пользователю (push, email, sms);
различные экспорты и импорты.

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

Однако, это не означает, что Serverless нельзя использовать в частях приложения, с которыми взаимодействует пользователь, и для которых важно время ответа. Напротив, Serverless функции широко применяются для, например:

чатботов;
бэкендов для IoT приложений;
манипуляции запросов к вашему основному бэкенду (например, для идентификации пользователя по User-Agent, IP и прочим данным, или для получения информации о его геопозиции по IP);
даже как совершенно самостоятельные API endpoint'ы.

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

Автор статьи, может стать твоим ментором и научить всему этому и многому другому Нанять

Поставщики услуг

Один из лидеров рынка FaaS услуг в наши дни — это AWS с их сервисом AWS Lambda. У них есть поддержка большого числа языков программирования (включая Ruby, Python, Go, NodeJS, C# и Java) и огромного количества сервисов, которые позволяют вам использовать не просто Serverless computing, но также и Database as a service, очереди сообщений, API Gateway и прочие, которые значительно упрощают работу с этой моделью.

Помимо AWS стоит отметить Google Cloud и Microsoft Azure с их продуктами Google Functions и Azure Functions, с которыми лично у меня опыта меньше и, насколько я могу судить, они все же пока отстают от AWS в этой сфере. Например, Google поддерживает лишь NodeJS и Python. Azure поддерживает гораздо больше, но многие из них только в экспериментальном статусе.

Кроме того, вы можете построить Serverless не только у публичных облачных провайдеров, но и в своем дата-центре. Если хочется подробнее узнать про такой подход, рекомендую посмотреть в сторону KNative, который позволяет вам построить подобную архитектуру поверх Kubernetes или OpenWhisk, который был первым проектом, привлекшим внимание сообщества на возможность Serverless на собственных серверах.

Резюмируя преимущества

Перед завершением статьи я бы хотел еще раз отметить плюсы применения Serverless.

Максимальная эластичность. Быстрое масштабирование от нуля до тысяч параллельно работающих функций.
Полная абстракция от операционной системы или любого софта, использующегося для выполнения приложения. Вам неважно, запускаются ли ваши Serverless приложения на Линуксе, Винде или самописной OS. Всё, что вас волнует — это способность платформы выполнять Python/Java/Ruby/YouNameIt код и сопутствующие библиотеки для этого ЯП.
При правильном проектировании функций легче построить слабо-связанную архитектуру, при которой ошибка в одной функции не скажется на работоспособности всего приложения.
Ниже порог входа для новоприбывших. Понять "наносервис" из 100-500 строк (а это и есть обычный размер функции в Serverless) для нового разработчика в команде гораздо проще, чем понять legacy проект с миллионом строк и сложных связей.

Не обойтись и без недостатков

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

Необходимо всегда заботиться о сохранении обратной совместимости, ведь от вашего интерфейса или бизнес-логики потенциально может зависеть другой сервис/функция.
Схема взаимодействия в классическом монолитном приложении и в распределенной системе очень сильно отличаются. Необходимо думать об асинхронном взаимодействии, возможных задержках, мониторинге отдельных частей приложения.
Хоть ваши функции и изолированы, неправильная архитектура все равно может привести к cascade failure — когда ошибка в одной из них приведет к неработоспособности большого количества других.
Цена прекрасной масштабируемости — это то, что пока ваша функция не вызывается, она и не запущена. И когда требуется ее запустить — это может занять до нескольких секунд, что может быть критично для вашего бизнеса.
Когда запрос от клиента проходит через десяток функций, становится очень сложно дебажить возможную причину ошибки, если таковая случается.
Так называемый vendor lock. Функции, разработанные для AWS будет очень сложно портировать на, например, Google Cloud. Причем не из-за самих функций, JS он и в гугле JS, а скорее из-за того, что вы редко используете Serverless функции в изоляции. Помимо них, вы будете использовать БД, очереди сообщений, системы логирования и прочее, что совершенно точно отличается от провайдера к провайдеру. Однако при большом желании даже эту функциональность вы можете сделать не зависящей от облачного провайдера.

Заключение

Хоть минусов и получилось больше чем плюсов, это не значит, что Function as a Service это плохое движение и после прочтения этой статьи вам следует забыть про него навсегда. Совершенно напротив, многие риски могут быть или минимизированы, или просто приняты как факт. Например, можно прогревать функции, чтобы пользователю никогда не приходилось ждать, когда она запустится. Для дебага существуют подходы, которые делают его менее болезненным. Vendor lock не будет проблемой для большинства бизнесов.

Кроме того, Serverless подход не подразумевает перехода всего приложения в один миг. Гораздо лучше здесь применим эволюционный подход, когда вы начинаете писать функции для некритичных или не customer-facing частей вашего приложения. Считаю ли я, что за Serverless (хотя бы частичным) будущее — однозначно да. Считаю ли я, что этот подход подойдет всем компаниям — однозначно нет. Считаю ли я, что стоит инвестировать время в то, чтобы попробовать его на практике — без сомнений.

Это то знание, которое вам точно пригодится. Чтобы попробовать Serverless в AWS самостоятельно, предлагаю следовать моей вводной практической статье в моем блоге или же дождаться обновленной и переведенной на русский версии здесь на mkdev.

Спасибо за внимание, если вам интересны Serverless и Microservices подходы, языки Ruby и JS, а также Cloud Infrastructure — буду рад быть вашим ментором. Если же у вас есть конструктивная критика или предложения — буду также рад вашим личным или публичным сообщениям.

Благодарю и желаю вам успехов в работе и образовании, дорогие читатели!