![image](https://habrastorage.org/getpro/habr/post_images/624/0f7/0fb/6240f70fb795d37d6f276d43ded3dbf9.jpg)
Последние несколько лет мы все чаще слышим термин «Serverless» по отношению к облачным сервисам. Более того, в Европе наш собственный Voximplant часто называют «Serverless телефонией для разработчиков». Но ведь у нас есть серверы, и много! Откуда такое странное название и что именно имеют в виду те, кто его использует? Чтобы обобщить и собрать в одном месте информацию про «Serverless», организация с длинным названием «Cloud Native Computing Foundation» посвятила ей официальный документ, Swapnil Bhartiya его внимательно изучил и написал интересную статью (интересные статьи про linux и open source он пишет уже лет 15), а мы адаптировали перевод для Хабра. Кстати, в очередной раз обновляя холивар «зачем переводить для Хабра». Во-первых, по-русски, если перевод адекватный, читать быстрее и когнитивно менее напряжно. Даже с очень хорошим английским. Физиология, ничего личного. Во-вторых, если кто-то решил перевести статью — то она, скорее всего, того стоит. Если вы не эксперт в чем-то, можно смело пропустить 100 статей, вышедшие по интересной теме за последний месяц, а посмотреть только те две, что перевели для Хабра.
«Serverless computing» или «Function as a Service» (FaaS) — новые термины, которые придумала наша индустрия, известная любовью к придумыванию новых терминов по мере развития технологий. Но что это значит? Что за «безсерверные вычисления»?
Прежде чем перейти к определению я хочу взять небольшой урок истории у Sirish Raghuram, генерального директора и сооснователя Platform9. Это прольет свет на эволюцию serverless.
В 90-е мы создавали приложения и запускали их на железе. Затем появились виртуальные машины, которые позволяли запускать много независимых приложений на одной машине. Но вы все еще запускали изолированную копию операционной системы для запуска каждого приложения. С появлением контейнеров это дублирование исчезло, сделав изоляцию процессов быстрой и гибкойКонцепция Serverless, а именно «Функция-как-сервис», продолжает этот подход, убирая шаги «сборка, разворачивание и запуск приложения». Вся эта машинерия скрывается от разработчика и больше нет необходимости думать о развертывании контейнеров с помощью Kubernetes.
Что же такое Serverless?
Единого определения нет. Чтобы помочь разработчикам, рабочая группа по Serverless организации "Cloud Native Computing Foundation" (CNCF) выпустила официальный документ с описанием что же это такое.
В соответствии с этим документом, «Serverless» называют концепцию создания и запуска приложений без необходимости настраивать серверную часть (от переводчика: включая такую «серверную часть» как описание докер-контейнера или heroku-деплоя). В рамках этой концепции приложение разбивается на функции, которые помещаются в облачную платформу и там выполняются, масштабируются и оплачиваются в зависимости от текущей нагрузки.
Ken Owens, участник Technical Oversight Committee в составе CNCF, определяет основную здачу «Serverless» как «помочь пользователям собирать и запускать приложения без необходимости управлять отдельными серверами и их масштабированием».
Chris Aniszczyk, COO в CNCF, считает что «Serverless» это естественная эволюция облачных сервисов. CNCF помогает продвигать Serverless, обеспечивая коммуникацию между использующими технологию компаниями и способствуя созданию единого стандарта.
Это не про «без серверов»
Не давайте ввести себя в заблуждение переводом «Serverless» как «без серверов». Конечно там есть серверы. Как сказано в одной из цитат выше — они «скрыты». Но не исчезли.
Очевидное преимущество подхода «Serverless» в том, что разработчики могут не беспокоиться о технических деталях, которые не добавляют ценности к создаваемому ими решению (от переводчика: а если ценность в том, чтобы решение обеспечивало минимальную себестоимость, то нужно не «Serverless», а поднимать и настраивать свой кластер). Разработчики могут перестать беспокоиться о разворачивании серверов и сфокусироваться на том коде, который приносит пользу. Время — деньги. Особенно время, которое не потрачено на DevOps-задачи управления инфраструктурой. Разработчикам не нужно самим придумывать архитектуру масштабирования, чтобы их решение переживало пиковые часы нагрузки, это происходит автоматически. Так как провайдеры «Serverless»-решений берут деньги только за время выполнения функций (или за минуту разговора, как мы в Voximplant), то стоимость облачной инфраструктуры снижается и не нужно платить за «мигающее огоньками» оборудование, ждущее пиковой нагрузки.
Но ведь эти мигающие огоньками серверы где-то должны быть!
В случае публичных облаков, таких как Google Cloud Platform, AWS и Microsoft Azure, владельцы облака используют его ресурсы для поддержки нужного количества FaaS-серверов. В случае приватных облаков или датацентров это делает отдельная команда DevOps, позволяя разработчикам не заморачиваться с серверами и писать код, приносящий пользу, а не инфраструктуру. Разделение труда!
По этой причине многие компании, такие как Suse, отходят от твермина «Serverless» и начинают использовать термин «FaaS». Ведь они предлагают решения, с помощью которых создаются серверы «Serverless».
С «Serverless» разобрались. Что за «Функции»? Новое будущее по работе с приложениями?
Пинковая тяга, или «Event-Driven Computing»
Многие рассматривают «Serverless» как «зонтичный термин», описывающий FaaS и кучу других штук. По определению CNCF, «FaaS» организует работу приложения как вызов функций в ответ на события или HTTP-запросы. Как написано в официальном документе, «разработчики организуют код приложения как набор функций, которые выполняются в ответ на события или HTTP-запросы. Разработчики помещают небольшие фрагменты кода в FaaS, и эти фрагменты дискретно выполняются, обеспечивая автоматическое масштабирование в зависимости от нагрузки, без необходимости для разработчиков управлять серверами или любой другой низкоуровневой инфраструктурой».
Значит ли это, что FaaS — новая серебряная пуля для разработки и деплоя приложений? Не похоже. По крайней мере на текущий момент. FaaS решает проблемы для ряда сценариев использования, и этот ряд постепенно расширяется. Хорошим сценарием для FaaS является «вызов кода в ответ на произошедшее событие».
Рассмотрим пример: пользователь делает фотку на своем телефоне и загружает ее в облако. В процессе загрузки происходит много разного: считываются «exif»-данные, изготавливается маленькая картинка для предпросмотра, с помощью машинного обучения анализируется содержимое, информация об изображении записывается в базу данных. Все эти функции порождаются одним событием загрузки изображения. Они прекращают свою работу после обработки события. И это именно то, что хорошо получается у FaaS: быстро запустить код для выполнения всех этих задач и так же быстро исчезнуть.
Это был один пример. В качестве еще одного можно рассмотреть устройство интернета вещей, в котором сенсор движения запускает событие, инструктирующее камеру начать запись с последующей ее отправкой кому надо. Система управления климатом может запустить вентилятор в ответ на изменение температуры. Это несколько примеров из множества, когда событийная модель хорошо подходит в качестве основы. Но, конечно, такая модель работы подходит далеко не для всех приложений.
CNCF уже провели за нас анализ и предлагают рассматривать FaaS как подходящее решение в следующих случаях:
- асинхронные и хорошо распараллеливаемые задачи;
- «плавающая» нагрузка со случайными пиками;
- отсутствие сохраненного состояния и требований к мгновенному «холодному старту»;
- быстро меняющиеся требования, когда нужно тестировать и выкидывать множество идей.
Почему это должно нас беспокоить?
«Serverless» с FaaS наперевес — новые технологии и парадигмы. Так же как в свое время виртуальные машины и контейнеры, FaaS-решения могут снова поменять правила игры. Сейчас технология только развивается, но у нее есть хороший потенциал быстро выйти за пределы простых решений и описанных выше вариантов использования.
Здравый смысл подсказывает, что компаниям, которые делают ставку на облачные вычисления, имеет смысл включить «Serverless» в свою стратегию развития. В IT всегда так: хочешь конкурентного преимущества — старайся использовать самые последние технологии.
Самое время добавить немного «Serverless» к нашим серверам.
Вопрос Хабру
Коллеги, как думаете, какой письменный термин устаканится? «Serverless»? «Серверлес»? «Безсерверно»? Или что-то другое?
Комментарии (7)
achekalin
15.05.2018 22:51Если мы берём FaaS, но в качестве функции пишем код, отдающий веб-страницу, а event-ом ставим приход http-запроса — то у нас получился обычный веб-сервер (правильнее сказать, что получилась cms-ка), так?
Одно непонятно: когда сайт не нагружен, кто платит за работу серверов, ждущих наготове приходя пика нагрузки?sub31
16.05.2018 07:47Идея в том, что для приложения с большим количеством запросов использовать минимум вычислительных мощностей и разделять вычислительные мощности между различными клиентами. Сглаживать пики потребления. Например — предоставлять одни и те же реальные сервера потребителям из разных часовых поясов с различным содержимым. Т.е. позволять мигрировать стайке виртуальных серверов или контейнеров между собой. Трансформироваться для предоставления более востребованного сервиса.
sub31
16.05.2018 07:41Тема интересная. Перевод адекватный. Для понятия Serverless наверное самое близкое понятие в русском языке серверонезависимое приложение или серверонезависимая функция. Хотя и тут слово сервер имеет смысл как-то обыгрывать.
vesper-bot
"Микросервисы"
altervision
Осталось рассказать об этом всем, кто придумывает новые термины.
dzsysop
Микросервисы это другие звери. Грубо говоря вы можете сделать микросервис на выделеном сервере, можете в облаках на контейнерах, а можете серверлес. Так что это немного из другой оперы.