Serverless что это

Что такое serverless computing (бессерверные вычисления)?

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

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

Затем пришли облачные вычисления, когда нужное количество серверов или часть серверного пространства можно было арендовать в облаке. Разработчики и компании, которые арендуют эти ресурсы, обычно приобретают мощности с некоторым запасом, чтобы гарантировать, что всплеск трафика или активности пользователей не превысит их месячные лимиты в облачной инфраструктуре и не выведет их приложение из строя. Это означает, что некоторая часть оплачиваемого серверного пространства может простаивает и не используется. Для решения этой проблемы облачные провайдеры предлагают модели автоматического масштабирования, но даже при такой модели выделения ресурсов нежелательный всплеск активности, вроде DDoS-атаки, может оказаться очень дорогостоящим.

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

Термин «бессерверный» несколько вводит в заблуждение, поскольку все ещё существуют серверы, предоставляющие эти внутренние сервисы. Но все проблемы, связанные с серверным пространством и инфраструктурой, решаются поставщиком. Бессерверный режим означает, что разработчики могут выполнять свою работу, вообще не беспокоясь о серверах.

Что такое серверные службы? В чем разница между фронтендом и бэкендом?

Разработка приложений обычно делится на две части: фронтенд и бэкенд. Фронтенд — это часть приложения, которую пользователи видят и с которой взаимодействуют, например, визуальный скелет страницы. Бэкенд — это часть, которую пользователь не видит. Она включает в себя сервер, на котором находятся файлы приложения, и базы данных, где хранятся пользовательские данные и реализована бизнес-логика.

Например, представим себе сайт, продающий билеты на концерты. Когда пользователь вводит адрес сайта в окне браузера, браузер отправляет запрос на внутренний сервер, который в ответ передаёт данные сайта. Затем пользователь видит интерфейс сайта, который может включать в себя текст, изображения и поля формы, которые пользователь должен заполнить. Пользователь может взаимодействовать с одним из полей формы на интерфейсе для поиска своего любимого музыкального исполнителя. Когда пользователь нажимает «отправить», это действие инициирует другой запрос к бэкенду. Внутренний код проверяет свою базу данных, чтобы узнать, существует ли исполнитель с таким именем, и если да, то, когда он будет выступать в следующий раз и сколько билетов доступно. Затем серверная часть передаст эти данные обратно, и интерфейс будет отображать результаты таким образом, чтобы это было понятно пользователю. Аналогичным образом происходит оплата — выполняется ещё один обмен данными между интерфейсом и сервером.

Какие серверные службы могут быть представлены бессерверными вычислениями?

Большинство бессерверных провайдеров предлагают своим клиентам услуги баз данных и хранилища, у многих есть платформы Function-as-a-Service (FaaS). FaaS позволяет разработчикам выполнять небольшие фрагменты кода на границе сети. С помощью FaaS разработчики могут создавать модульную архитектуру, делая кодовую базу более масштабируемой, не тратя ресурсы на поддержку бэкенда.

Каковы преимущества бессерверных вычислений?

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

В сравнении с другими моделями облачного сервиса.

Есть ещё пара технологий, которые часто путают с бессерверными вычислениями — это Backend-as-a-Service и Platform-as-a-Service. Хотя у них есть общие черты, эти модели не обязательно удовлетворяют требованиям бессерверности.

Backend-as-a-service (BaaS) — это модель обслуживания, в которой поставщик облачных услуг предлагает серверные службы (например, хранение данных), чтобы разработчики могли сосредоточиться на написании кода фронтенда. Но хотя бессерверные приложения управляются событиями и работают на периферии, приложения BaaS могут не соответствовать ни одному из этих требований.

Платформа как услуга (PaaS) — это модель, в которой разработчики по сути арендуют все необходимые инструменты для разработки и развёртывания приложений у облачного провайдера, включая такие вещи, как операционные системы и промежуточное ПО. Однако приложения PaaS не так легко масштабируются, как бессерверные приложения. PaaS также не обязательно работает на периферии и часто имеет заметную задержку запуска, которой нет в бессерверных приложениях.

Инфраструктура как услуга (IaaS) — это общий термин для поставщиков облачных услуг, размещающих инфраструктуру от имени своих клиентов. Поставщики IaaS могут предлагать бессерверные функции, но эти термины не являются синонимами.

Развитие бессерверных технологий

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

Обычно, когда определённая бессерверная функция не вызывалась в течение некоторого времени, провайдер её отключает, чтобы сэкономить энергию и избежать избыточного выделения ресурсов. В следующий раз, когда пользователь запустит приложение, которое вызывает эту функцию, бессерверному провайдеру придётся включить его заново и снова запустить эту функцию. Это добавляет некоторую задержку, известную как «холодный старт».

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

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

Что ещё интересного есть в блоге Cloud4Y

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Бессерверные вычисления (serverless computing) — что это такое и где используются

Бессерверные вычисления (их также называют serverless computing) — это набирающий популярность способ предоставления серверных услуг без аренды/покупки физического оборудования. Сервера в этом случае, разумеется, используются, но на стороне поставщика услуги. Именно он заботится о конфигурации физических серверов, их производительности, количестве CPU и RAM. Пользователь никак не взаимодействует с инфраструктурой и не обслуживает её, но при этом может писать и развёртывать код, используя готовые вычислительные ресурсы.

Оплачиваются эти ресурсы по факту потребления (модель pay-as-you-go). Резервировать и предоплачивать определённое количество серверов или пропускную способность канала не нужно. Объём потребляемых мощностей автоматически масштабируется.

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

Эволюция технологий

С появлением облачных вычислений компании стали арендовать целые облачные сервера или часть серверного пространства. Поначалу пользователи старались брать мощности с запасом, чтобы внезапный наплыв пользователей не выводил системы из строя. Соответственно, часть облачных ресурсов оплачивалась, но не использовалась по назначению: простаивала. Чтобы решить эту проблему, поставщики облачных услуг внедрили автоматическую систему масштабирования, позволяющую эффективно справляться с внезапными пиками активности. Хотя при DDoS-атаке автоматическое масштабирование может больно ударить по кошельку. Но этот вопрос решается другими способами.

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

Не все правильно понимают, что значит serverless computing. Этот термин не должен вводить вас в заблуждение. Клиент действительно никак не взаимодействует с серверами, для него их нет. Он получает ресурсы этих серверов. И может заниматься тестированием и развёртыванием приложений, не беспокоясь о «железе». Однако физически серверы существуют и используются. Просто клиента это никоим образом не заботит.

Чем отличается фронтенд и бэкенд и при чём тут серверные службы

Разработку приложений можно разбить на две части: бэкенд и фронтенд. Бэкенд — это внутренняя инфраструктура. Та часть, которую пользователь не видит. Она состоит из сервера с файлами приложения и БД с пользовательскими данными. Там же реализована бизнес-логика. Фронтенд — это доступная пользователю часть приложения, которую он видит и с которой может взаимодействовать (например, интерфейс страницы).

Приведём пример. Есть сайт-агрегатор билетов на различные мероприятия. Когда пользователь вбивает в браузере нужный URL, браузер посылает запрос на внутренний сервер, получая в ответ данные этого сайта. В результате этого обмена пользователю показывается искомая страница. Допустим, там есть форма, которую нужно заполнить для поиска и покупки билета. Когда пользователь указывает в форме название мероприятия и нажимает «Отправить», формируется запрос к бэкенду. Внутренний код собирает информацию в БД, проверяя наличие мероприятия, когда оно состоится, есть ли билеты на него. Затем сервер возвращает эту информацию обратно, и фронтенд показывает результаты, трансформируя данные в понятный пользователю интерфейс. Покупка билетов выполняется по аналогичной схеме.

Аренда облачного сервера для разработки, хостинга, обученияПодробнее

Какие серверные службы можно использовать как бессерверные вычисления

Как правило, провайдеры предлагают клиентам услуги баз данных и хранилища. Также существует платформа Function-as-a-Service (FaaS), благодаря которой разработчики имеют возможность формировать модульную инфраструктуру и не тратить деньги на поддержку бэкенда, что делает кодовую базу дешевле, но более масштабируемой.

Преимущества serverless computing

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

Уменьшение расходов. Бессерверные вычисления позволяют тратить меньше, поскольку оплате подлежат только реально используемые ресурсы. Нет простаивающего оборудования или оплаты ресурсов «про запас».
Простая масштабируемость. При использовании бессерверной архитектуры можно не заботиться о политиках масштабирования кода приложений. Поставщик бессерверной услуги сам выполняет все масштабирования.
Упрощённый внутренний код. Использование платформы FaaS позволяет разработчикам создавать простые функции, независимо выполняющих одну задачу. Например, вызывающие API.
Высокая скорость разработки. Serverless computing сокращает время выхода продукта на рынок. Разработчики могут добавлять и изменять отдельные части кода, а не заниматься развёртыванием приложения для исправления ошибок и добавления новых функций.

Что ждёт бессерверные технологии

Serverless computing будут развиваться и дальше, поскольку поставщики работают над появлением новых услуг и устраняют имеющиеся недостатки. Например, решают проблему холодного старта. Вопрос заключается в том, что когда какая-либо бессерверная функция долго не вызывается, провайдер её отключает. Это делается для снижения объёма выделяемых ресурсов. И когда функция всё же понадобится, провайдеру требуется включить её заново и затем запустить. Это вызывает небольшую задержку, которая и получила название «холодный старт».

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

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

Что такое 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 — буду рад быть вашим ментором. Если же у вас есть конструктивная критика или предложения — буду также рад вашим личным или публичным сообщениям.

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

Почитать еще

Введение в AWS API Gateway и Lambda в моем блоге
Интеграция AWS Lambda с no-sql БД DynamoDB в моем блоге
Использование Terraform для работы с AWS Lambda в моем блоге
Доклад моего коллеги-ментора Антона Черепанова про Serverless
Основы виртуализации от Кирилла Ширинкина

Serverless по стоечкам

Serverless ― это не про физическое отсутствие серверов. Это не «убийца» контейнеров и не мимолетный тренд. Это новый подход к построению систем в облаке. В сегодняшней статье коснемся архитектуры Serverless-приложений, посмотрим, какую роль играет провайдер Serverless-услуги и open-source проекты. В конце поговорим о вопросах применения Serverless. Я хочу написать серверную часть приложения (да хоть интернет-магазина). […]

Изображение записи

Я хочу написать серверную часть приложения (да хоть интернет-магазина). Это может быть и чат, и сервис для публикации контента, и балансировщик нагрузки. В любом случае головной боли будет немало: придется подготовить инфраструктуру, определить зависимости приложения, задуматься насчет операционной системы хоста. Потом понадобится обновить небольшие компоненты, которые не затрагивают работу остального монолита. Ну и про масштабирование под нагрузкой не будем забывать.

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

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

Такие мысли привели меня к бессерверным вычислениям. Serverless в данном случае означает не физическое отсутствие серверов, а отсутствие головной боли по управлению инфраструктурой.

Идея в том, что логика приложения разбивается на независимые функции. Они имеют событийную структуру. Каждая из функций выполняет одну «микрозадачу». Все, что требуется от разработчика ― загрузить функции в предоставленную облачным провайдером консоль и соотнести их с источниками событий. Код будет исполняться по запросу в автоматически подготовленном контейнере, а я заплачу только за время исполнения.

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

Со стороны разработчика

Ранее мы начали говорить про приложение для интернет-магазина. В традиционном подходе основную логику системы выполняет монолитное приложение. И сервер с приложением запущен постоянно, даже если нагрузки нет.

Чтобы перейти к Serverless, разбиваем приложение на микрозадачи. Под каждую из них пишем свою функцию. Функции независимы друг от друга и не хранят информацию о состоянии (stateless). Они даже могут быть написаны на разных языках. Если одна из них «упадет», приложение целиком не остановится. Архитектура приложения будет выглядеть вот так:

Архитектура Serverless-приложения

Деление на функции в Serverless похоже на работу с микросервисами. Но микросервис может выполнять несколько задач, а функция в идеале должна выполнять одну. Представим, что стоит задача собирать статистику и выводить по запросу пользователя. В микросервисном подходе задачу выполняет один сервис с двумя точками входа: на запись и на чтение. В бессерверных вычислениях это будут две разные функции, несвязанные между собой. Разработчик экономит вычислительные ресурсы, если, например, статистика обновляется чаще, чем выгружается.

Serverless-функции должны выполняться за короткий промежуток времени (timeout), который определяет провайдер услуги. Например, для AWS timeout составляет 15 минут. Значит, долгоживущие функции (long-lived) придется изменить под требования ― этим Serverless отличается от других популярных сегодня технологий (контейнеров и Platform as a Service).

Каждой функции назначаем событие. Событие ― это триггер для действия:

Событие	Действие, которое выполняет функция
В хранилище загрузили картинку товара	Сжать картинку и выгрузить в каталог
В базе данных обновился адрес физического магазина	Подгрузить в карты новое местоположение
Клиент оплачивает товар	Запустить обработку платежа

Событиями могут выступать HTTP-запросы, потоковые данные, очереди сообщений и так далее. Источники событий ― это изменение или появление данных. Кроме того, функции можно запускать по таймеру.

Архитектуру проработали, и приложение почти стало Serverless. Дальше идем к провайдеру услуги.

Со стороны провайдера

Обычно бессерверные вычисления предлагают провайдеры облачных услуг. Называют по-разному: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

Пользоваться услугой будем через консоль или личный кабинет провайдера. Код функций можно загрузить одним из способов:

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

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

Интерфейс Google Cloud Platform Console

Провайдер на своей инфраструктуре построил и автоматизировал систему Function as a Service (FaaS):

Код функций попадает в хранилище на стороне провайдера.
Когда появляется событие, на сервере автоматически разворачиваются контейнеры с подготовленным окружением. Каждому экземпляру функции ― свой изолированный контейнер.
Из хранилища функция отправляется в контейнер, вычисляется, отдает результат.
Число параллельных событий растет ― растет количество контейнеров. Система автоматически масштабируется. Если пользователи не обращаются к функции, она будет неактивна.
Провайдер задает время простоя контейнеров ― если в течение этого времени функции не появляются в контейнере, он уничтожается.

Таким образом мы получаем Serverless «из коробки». Платить за услугу будем по модели pay-as-you-go и только за те функции, которые используются, и только за то время, когда они использовались.

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

Основное преимущество работы с провайдером ― возможность не беспокоиться об инфраструктуре (серверах, виртуальных машинах, контейнерах). Со своей стороны провайдер может реализовать FaaS как на собственных разработках, так и с помощью open-source инструментов. О них и поговорим дальше.

Со стороны open source

Последние пару лет сообщество open-source активно работает над инструментами Serverless. В том числе вклад в развитие бессерверных платформ вносят крупнейшие игроки рынка:

Google предлагает разработчикам свой open-source инструмент ― Knative . В его разработке участвовали IBM, RedHat, Pivotal и SAP;
IBM работали над Serverless-платформой OpenWhisk , которая затем стала проектом Apache Foundation;
Microsoft частично открыли код платформы Azure Functions .

Разработки ведутся и в направлении serverless-фреймворков. Kubeless и Fission разворачиваются внутри заранее подготовленных Kubernetes-кластеров, OpenFaaS работает как с Kubernetes, так и с Docker Swarm. Фреймворк выступает в роли своеобразного контроллера ― по запросу готовит внутри кластера среду выполнения, потом запускает там функцию.

Фреймворки оставляют простор для конфигурации инструмента под свои нужды. Так, в Kubeless разработчик может настроить timeout выполнения функции (дефолтное значение ― 180 секунд). Fission в попытке решить проблему холодного старта предлагает часть контейнеров держать все время запущенными (хоть это и влечет затраты на простой ресурсов). А OpenFaaS предлагает набор триггеров на любой вкус и цвет: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs и другие.

Инструкции к началу работы можно найти в официальной документации фреймворков. Работа с ними подразумевает наличие чуть большего количества навыков, чем при работе с провайдером ― это как минимум умение запустить Kubernetes-кластер через CLI. Максимум, включить в работу другие open-source инструменты (допустим, менеджер очередей Kafka).

Вне зависимости от того, каким способом мы будем работать с Serverless ― через провайдера или с помощью open-source, мы получим ряд преимуществ и недостатков Serverless-подхода.

С позиции преимуществ и недостатков

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

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

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

Как и любая технология, Serverless имеет недостатки.

Например, таким недостатком может быть время холодного старта (в среднем до 1 секунды для таких языков как JavaScript, Python, Go, Java, Ruby).

С одной стороны, на деле время холодного старта зависит от многих переменных: язык, на котором написана функция, количество библиотек, объем кода, общение с дополнительными ресурсами (те же базы данных или серверы аутентификации). Поскольку разработчик управляет этими переменными, он может сократить время старта. Но с другой стороны, разработчик не может управлять временем запуска контейнера ― здесь все зависит от провайдера.

Холодный старт может превратиться в теплый, когда функция переиспользует запущенный предыдущим ивентом контейнер. Такая ситуация возникнет в трех случаях:

если клиенты часто используют сервис и растет количество обращений к функции;
если провайдер, платформа или фреймворк позволяют держать часть контейнеров запущенными все время;
если разработчик запускает функции по таймеру (скажем, каждые 3 минуты).

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

Следующим недостатком Serverless называют короткое время жизни функции (timeout, за который функция должна выполниться).

Но, если предстоит работать с долгоживущими задачами, можно использовать гибридную архитектуру ― скомбинировать Serverless с другой технологией.

Не все системы смогут работать по Serverless-схеме.

Некоторые приложения по-прежнему будут хранить данные и состояние во время выполнения. Некоторые архитектуры останутся монолитными, а некоторые функции будут долгоживущими. Однако (как когда-то облачные технологии, а затем и контейнеры), Serverless ― технология с большим будущим.

В этом ключе мне бы хотелось плавно перейти к вопросу применения Serverless-подхода.

Со стороны применения

За 2018 год процент использования Serverless вырос в полтора раза. Среди компаний, которые уже внедрили технологию в свои сервисы, такие гиганты рынка как Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. При этом нужно понимать, что Serverless ― не панацея, а инструмент для решения определенного круга задач:

Сократить простой ресурсов. Не надо постоянно держать виртуальную машину под сервисы, к которым мало обращений.
«На лету» обработать данные. Сжимать картинки, вырезать фон, менять кодировку видео, работать с датчиками IoT, выполнять математические операции.
«Склеить» между собой другие сервисы. Git-репозиторий с внутренними программами, чат-бот в Slack с Jira и с календарем.
Балансировать нагрузку. Здесь остановимся подробнее.

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

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

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

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

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

Serverless и Selectel

В Selectel мы уже упростили работу с Kubernetes через нашу панель управления. Теперь мы строим собственную FaaS-платформу. Мы хотим, чтобы разработчики могли решать свои задачи с помощью Serverless через удобный, гибкий интерфейс.

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

Материалы, использованные в статье: