Привет, Хабр! В комментариях к статьям из нашего хаба часто спорят: полезна ли 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.
maslyaev
Присматриваюсь к серверлесс-архитектуре, и пока что-то не пойму как применить это в свей реальной жизни так, чтобы потом не пришлось всё срочно переделывать.
Адепты этого подхода из каждого утюга кричат, что "подходит для всего" и "можно реализовать что угодно", но это очевидно… мягко говоря… хм… неправда.
Начать с того, что серверлесс он ещё и неизбежно стэйтлесс. Если разрабатываемая штучка обязана быть стейтфул, то серверлесс сразу мимо.
У меня есть архиполезный для бизнеса сервис, который стартут пять минут, зажирает 2ГБ оперативы, но после этого выдаёт ответы с ураганной скоростью. Очевидно, что из-за этих самых 2ГБ и пяти минут этот сервис не может быть серверлесс.
И ещё я понимаю, что слегка попервой накосячить и вызвать сход лавины вызовов (примерно как у ребят по приведённой Вами ссылке) — ну это просто святое. Когда такое происходит (а оно неизбежно происходит), в "обычной" архитектуре тестовый кластер просто покрасится красненьким, да и ничего страшного. Серверлесс же всё стерпит и пришлёт конский счёт за услуги.
Кстати, а кто-нибудь знает, как развернуть модельку серверлесс-среды у себя на локалке? Или предлагается сразу запускаться в очень платном облаке?
Если продолжить занудствовать, то уверен, наберётся ещё список на сорок листов архитектурных ограничений и тонкостей. Кто-нибудь об этом говорит? Кто-нибудь проводит инструктаж по технике безопасности? Как раз строго наоборот, "подходит для всего" и "можно реализовать что угодно".
Задача правильной декомпозиции разрабатываемых систем и так чудовищно сложная. А с учётом дополнительных архитектурных ограничений она становится кошмаром. А с учётом того, что эти ограничения ещё и старательно замалчиваются, всё превращается в какую-то совсем мерзкую липкую хтонь.
Так что пока у меня есть только ощущение, что вся эта история про то, чтобы доверчивого и падкого на диковинки клиента (т.е. меня) меньше кормить и больше доить. Охотно готов оказаться не прав.
golodnyj Автор
Очень много вопросов в одном комментарии. Сразу на все не ответить. Прежде всего начнем с того что «очень платное облако» дает возможность потестировать и поучиться вполне себе бесплатно через программу free tier. Для примера, 1 000 000 вызовов функций каждый месяц бесплатно.
Реализация через стэйтлесс функции это правильный путь использования и конечно он не всем подходит. Вопрос декомпозиции приложения всегда непростой. В идеале построить бизнес-процесс, где каждым этапом является вызов небольшой функции. В сложных случаях получается развесистая схема, но она того стоит. Особенно если вы понимаете что большая часть вызовов почти никогда не дергается.
Большую часть вопросов можно обсудить в комьюнити, в нем активно участвуют разработчики сервисов и могут пояснить за нюансы.
maslyaev
Спасибо что откликнулись. На сообщество пока подписываться не буду т.к. сидим на Ажуре и переезжать не планируем. Хотя кто знает. В Ажуре тоже есть функции, которые, догадываюсь, идейно есть то же самое. И вот смотрю на эти функции (вот они, рядом, нажимай кнопочку "add new" и получай неземное наслаждение) и не понимаю зачем мне это. Есть смутное ощущение, что может очень даже пригодиться, но как и зачем — no idea.
Можно я порассуждаю вслух? Если забреду куда-нибудь не туда, пожалуйста поправьте.
Итак, функция. Как мы уже выяснили, оно без вариантов должно быть стейтлесс. То есть данные в себе не хранит. Если нужно хранить, то пользуемся живущими вовне базами данных, файлохранилищами, кафками и прочими товарищами, которые уже не функции, потому что они стейтфул.
Ещё функция не должна выполняться слишком долго. 30 секунд максимум. Или сутки тоже нормально, если задача достойная?
И ещё она не должна пожирать слишком много оперативы. На какое ограничение ориентироваться?
Быстрый холодный старт. Т.е. если нужен длительный предрасчёт чего-то или кеширование куска БД, то функцию делать лучше не надо.
С кешированием, насколько я понимаю, у функций вообще всё странно — его невозможно применить эффективно т.к. экземпляры функций как попало рождаются и умирают. Да и вообще, любое кеширование это уже маленький такой безобидный стейтфул.
Что у нас с параллелизмом внутри функции? Однотредовую асинхронщину, если язык позволяет, однозначно можно, но что с многопоточностью? Можно? Нельзя? Можно, но не рекомендуется?
Насколько я понимаю, GPU — запретная тема для функций, сразу и навсегда. То есть нейросети и прочие ML-дела в любом виде, что обучение, что инференс, точно не про функции.
Что с аутентификацией/авторизацией? Всё плохо или наоборот, организация авторизованного доступа это как раз тот случай, когда имеет смысл в первую очередь подумать о функциях?
Пока что я вижу следующие сценарии использования функций:
golodnyj Автор
Начнем с начала. Все верно про стейтфул-стейтлес, по хорошему для функций есть инструменты для хранения состояния:
Лучше декомпозировать задачу и автоматически у вас ограничится время выполнения. Если вы возьмете приложение и реально построите его в Serverless-стиле то много памяти вам для каждой отдельной функции и не понадобиться. При этом «предрасчет» или «кеширование» дает некий результат и именно этот результат может быть входом для следующей функции.
Прям для эксперимента возьмите алгоритм, накидайте блоков, прикиньте: что каждый блок реализует некую функцию, и вот у нее вход, вот выход, вот ветвления разных вызовов функций.
Для сложных, емких задач, которых не так много, лучше использовать специализированные инструменты. Например, для ML почти у каждого взрослого облака что-то есть, например Yandex DataSphere
maslyaev
Спасибо большое за статью и ответы. Наконец-то заставил себя поразбираться с этой штукой.
Немножко дополнительно погуглив, выработал для себя чёткий набор критериев, по которым можно определить, имеет ли смысл реализовывать задачу на серверлесс. Если хотите, могу поделиться.
golodnyj Автор
Делитесь, хабр для того и создан. Я бы правда предложил следующий вариант: попробовать в вашем облаке возможности serverless и оформить впечатления в виде статьи на нашем хабе. Будет хороший материал с личным опытом и мнением.
maslyaev
Обещать не могу, но идея интересная.
Итак, как понять, что для реализации задумки годится серверлесс.
Во-первых, что логично, оно должно укладываться в архитектурные ограничения. Читаем доки по используемому облаку и, например, выясняем, что для того, чтобы завершиться, у функции есть не больше пяти минут. Если была идея сделать функцией какой-нибудь нудный и долгий ETL, то не судьба. Допустим, в ограничения укладываемся, потому что если нет, то здесь разговор закончен.
Во-вторых, сразу прикидываем, пугает ли нас привязка к конкретному облачному провайдеру. И если пугает, то насколько. А если не пугает, сразу пытаемся прикинуть, какова вероятность того, что мнение по этому вопросу не изменится. Допустим, всё ОК, не пугает и пугать не собирается, потому что иначе… ну, понятно.
Если эти два барьерчика пройдены, то дальше вопрос целесообразности, где у нас развилка на три семейства ситуаций.
(а) Нам надо выкинуть в облако нечто действительно простое. Например по запросу от фронтенда выдернуть немножко данных из базы, сунуть их в пандас, немножко там покрутить, скормить матплотлибу и отдать получившийся PNG клиенту. Уже есть готовый Юпитер-ноутбук, который это умеет делать, надо только опубликовать в виде сервиса. Погружаться в хтонь девопса со всеми этими терраформами, хельм-чартами и прочими тяжеловесными CI/CD нет ни сил, ни желания, ни квалификации. Предоставляемая функциями фича "NoOps" это как раз то, что нужно.
(б) Прямо противоположная ситуация. У нас всё сложно и мощно, и фича, которая нас интересует — автоскейлинг до небес на пиковых нагрузках. И вот здесь включаем голову и смотрим, что конкретно у нас является узким местом. Если всё тормозит, то это вовсе не значит, что оно тормозит процессором. В 99% случаев оно отдыхает на операциях ввода-вывода. В этом случае асинхронка поможет лучше автоскейлинга функций хотя бы потому, что можно накрутить дополнительных плюшек типа кеширования. Плюс к тому так будет легче контролировать транзитивную нагрузку и избежать того, что функция-то справилась, но сервер базы лёг. Короче, в этом сценарии функции применяются только для вычислений. И то только если уже перевели вычисления на быстрый язык, а не на эти ваши пандасы. Да, ещё на всякий случай убедимся, что сложность, с которой воюем это O(n). В случае с O(n^p) горизонтальный скейлинг всё равно счастья не принесёт. В сухом остатке: чисто вычислительные задачи сложности O(n), уже переведённые на гошечку или С++.
(в) Лепим халтуру, главное запуститься, подписать акт и успеть добежать с деньгами до канадской границы. Серверлесс поможет проскочить нагрузочные испытания, а дальше хоть трава не расти.
Мне ближе сценарий (б), но я отдаю себе отчёт, что это весьма редкая (хотя, конечно, меткая) ситуация. Ожидаю, что подавляющее большинство поделий будут по сценариям (а) и (в).
Вообще я очень насторожено отношусь к технологиям, которые развращают разработчиков, давая им ложное ощущение снятия ресурсных ограничений. В конце концов мы живём в физической реальности, и по-настоящему неограниченные у нас только глупость и жадность.
achekalin
Free Tier… это, конечно, клёво, но вот как себе локально (или на dev-сервере в пределах офиса) собрать то же — непонятно.
Т.е. мы имеем некий подход (который проживет N лет, и будет вымыт новым, еще более революционным чем-то там — да-да, с переделкой всего и вся), в котором привязаны не только к облакам, а именно к реализации облаков именно у этого провайдера. Это такой вендор-лок, который врагу не пожелаешь: вообще вариантов нет уйти — нет, и не будет.
golodnyj Автор
На тему вымывания. Я тут сел посчитал:
Я не показателен и нужно смотреть отрасль, окружение. Но если вы попробуете проанализировать ваше окружение то есть не нулевая вероятность что прийдете к следующим выводам. За три-пять следующих лет большая частью ваших проектов будет переписана, переделана и способ дистрибуции будет сменён. А еще есть вероятность, что и у значительной части проектов и язык разработки будет сменен.