Бессерверные вычисления: почему некоторые разработчики упускают главное?

На эту тему перевели для вас интересные и достаточному простые мысли дата-инженера Анны Аннисени.

Чем опасен однобокий взгляд на ИТ-архитектуру?

Недавно я посмотрела видеоролик замечательного разработчика и ютубера Бена Авада (Ben Awad), в котором он высказал мнение, что бессерверные технологии лишены смысла. Ролик мне смотреть было интересно – но я не могу сказать, что полностью разделяю отношение автора к бессерверным технологиям. Своим мнением я хотела бы поделиться в этой статье.

В начале ролика автор шутит:

В этом мире есть две вещи, которых я не понимаю, — девушки и бессерверные вычисления.

Ничего не могу сказать об отношениях Бена с девушками, – но прав ли он, когда речь заходит о бессерверных вычислениях? Давайте рассмотрим приведенные им критические доводы и обсудим возможные контраргументы. Спойлер: Я считаю, что в бессерверных технологиях ЕСТЬ смысл, – если знать, КОГДА и КАК их использовать.

Критика бессерверных технологий

Основной аргумент, упомянутый в этом несколько спорном YouTube-ролике – это недостаточно высокая скорость выполнения кода. Если говорить конкретнее, основной недостаток бессерверных приложений с позиций автора – это (общеизвестная) проблема «холодного запуска» . Она связана с появлением дополнительной задержки, при которой код может не начать выполняться до тех пор, пока облачная инфраструктура не выделит необходимые вычислительные ресурсы, не подтянет программный код или образ контейнера, не установит дополнительные пакеты и не настроит среду выполнения.

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

Почему некоторые инженеры не видят истинных преимуществ бессерверных технологий?

Если скорость выполнения кода настолько важна для вас, что лишние 200 мс задержки (по оценкам AWS задержка может достигать 1 сек) не приемлемы для ваших рабочих нагрузок, в таком случае бессерверные технологии и в самом деле не вариант, и это абсолютно нормальная ситуация. Однако не стоит заходить слишком далеко и утверждать, что такая задержка сводит на нет всю пользу бессерверных технологий. Каждый должен сам для себя решить, какая задержка приемлема в конкретном сценарии.

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

Низкие затраты на бессерверную инфраструктуру могут существенно перевесить любые недостатки

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

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

Проблема холодного запуска – это вопрос правильной настройки и бюджетирования

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

Если вы готовы заплатить чуть больше, есть много способов смягчить проблему холодных запусков, например, при помощи предварительно прогретых виртуальных машин (механизм Provisioned Concurrency). Еще можно намеренно генерировать больше запросов (так называемые фейковые запросы), чтобы ваша операционная среда не успевала остыть. Используя платформу мониторинга, например, Dashbird, очень легко настроить уведомления о любом холодном запуске и оптимизировать нагрузку на бессерверные ресурсы. На картинке ниже видно, что на 29 выполненных вызовов пришелся всего один холодный запуск, что добавило примерно 180 миллисекунд задержки к общему времени выполнения.

Функционал наблюдаемости в Dashbird помогает выявить и предотвратить холодные запуски 

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

Настройка оповещения о холодных запусках в Dashbird

Методы сокращения задержек при выполнении функций AWS Lambda

Вы можете уменьшить задержку выполнения функций при бессерверных вычислениях, если правильно настроите повторное использование контекста. AWS замораживает и сохраняет контекст выполнения функции AWS Lambda – то есть все, что происходит за пределами функции-обработчика. Если в течение последующих 15 минут такая же функция будет запущена еще раз, «замороженная» среда выполнения будет использована повторно. Это означает, что производительность будет существенно выше, если вынести затратные по времени операции, например, подключение к реляционной базе данных, за пределы обработчика в функции AWS Lambda. В данной статье эта тема разъяснена очень подробно.

Существует масса прекрасных статей, в которых рассказывается, как уменьшить или даже полностью устранить проблемы, связанные с холодным запуском: например, эта и эта. Более того, в Dashbird есть открытая библиотека Python под названием xlambda, которая не даст остыть функциям AWS Lambda, написанным на языке Python.

Какая задержка приемлема для ваших рабочих нагрузок?

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

Наконец, такие платформы, как бессерверный сервис Kubernetes от AWS (также известный под названием "EKS на Fargate") позволяет объединить бессерверный и серверный уровни данных на одном кластере Kubernetes. Такое сочетание позволяет запускать критически важные рабочие нагрузки, требующие низкой задержки, на серверном уровне данных на базе Amazon EC2, а другие виды рабочей нагрузки (например, пакетную обработку данных) – на бессерверном уровне данных, – и получить лучшее из двух подходов. Подробнее об этом можно узнать в этой статье.

Бессерверные вычисления – это про “NoOps” и масштабируемость

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

Автоматизированные средства обеспечения бессерверной инфраструктуры высвобождают ценные временные ресурсы высококвалифицированных инженеров и дают им возможность сосредоточиться на решении бизнес-задач, а не на управлении кластерами. Это позволяет делегировать операционное обеспечение ИТ-процессов экспертам DevOps из AWS. У них, пожалуй, столько наработок в области управления вычислительными ресурсами, сколько не снилось ни одной другой компании.

Сценарии использования, которые сильно выигрывают от бессерверных вычислений

Представьте себе, что вы только что основали стартап. В начале вам может и не понадобиться большой кластер ресурсов, да и разработчик, вероятно, всего один. Концепция бессерверных вычислений позволяет вам начать с малого и автоматически масштабировать свои ресурсы по мере роста стартапа, используя принцип оплаты по мере использования («pay-as-you-go»).

Еще одна группа, которой очень выгодны бессерверные вычисления – это малый бизнес с небольшим ИТ-отделом. Возможность управлять всем жизненным циклом приложения, имея в распоряжении ресурс единственного профильного DevOps-инженера (а не целой команды) – неоспоримое преимущество бессерверной модели.

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

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

Скорость выполнения кода и скорость циклов разработки

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

Если бессерверная технология оперативно предоставляет доступ к самым первым версиям вашего приложения всем заинтересованным лицам и ускоряет итерации в цикле разработки (одновременно снижая затраты), – может быть, иногда можно пережить задержку в несколько миллисекунд при эпизодических холодных запусках?

Бесшовная интеграция с другими облачными сервисами

По примеру AWS все бессерверные сервисы интегрировались с CloudWatch – для поддержки логирования, с IAM – для управления правами доступа, с CloudTrail – для сбора метрик и трассировки, а также со многими другими системами. Помимо этого, бессерверные платформы обычно предоставляют базовые конструктивные блоки для создания более крупных слабо связанных микросервисных архитектур, включая интеграцию с бессерверной очередью сообщений (SQS), бессерверной шиной сообщений «publish-subscribe» (SNS), бессерверным хранилищем данных NoSQL (DynamoDB), а также объектным хранилищем данных (S3).

Недостатки бессерверных технологий, не рассмотренные в видеоролике

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

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

  • Вы рискуете попасть в зависимость от поставщика: облачные провайдеры стараются сделать свои услуги настолько удобными и экономически эффективными, что риск остаться на конкретной платформе присутствует с самого начала.
  • По сравнению с размещением ресурсов на собственном хостинге, использование бессерверной инфраструктуры дает вам несколько меньший контроль над вычислительными ресурсами. Например, вы не можете подключиться по SSH к вычислительным инстансам и выполнить настройки вручную. Также у вас меньше свободы и в выборе типа инстанса. Например, вы не можете запускать свои бессерверные функции или контейнеры на вычислительных инстансах с GPU (по крайней мере, на текущий момент).
  • Если у вас есть регламентные требования, не позволяющие обрабатывать данные на общем клиенте в облаке, то бессерверное решение может вам не подойти.
  • Несмотря на то, что разделение ИТ-инфраструктуры на автономные микросервисы помогает управлять зависимостями и ускорить релизный цикл приложения, при этом создается проблема, связанная с управлением большим количеством «подвижных деталей». Притом что многие системы мониторинга, например, Dashbird, позволяют в значительной степени решить эту конкретную задачу, необходимо осознавать компромиссы, на которые вы идете.

Выводы по критике бессерверных технологий

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

Я считаю, что мы не должны говорить о бессерверных вычислениях (впрочем, как и о каких-либо других информационных технологиях) в контексте какого-то одного аспекта, игнорируя другие, не менее важные, – особенно те, для которых эта технология исходно разрабатывалась. В этом ключе в бессерверных технологиях ЕСТЬ смысл, если знать, КОГДА и КАК их использовать.

Подписывайтесь на блог Yandex.Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.

Другие истории, которые активно читают наши подписчики:

0
43 комментария
Написать комментарий...
Владимир Чернышев

Почему-то говоря о серверлесс, часто забывают или лишь вскользь упоминают про "ноготок увяз - всей птички пропасть". Что серверлесс это не просто вынести одну функцию в облако, это сразу предполагает кучу дополнительных сервисов приобретать у облака и как-то интегрировать с существующими. Задаёшь вопросы типа а как логи будут попадать в наш эластик, метрики в наш прометей, а в ответ купите то, купите это, переведите своё легаси на EC2, постгресс на managed наш и выкиньте свои эластики и прометеи - тогда сможете экономить на воркере переведя его на лямбду , но при этом в три раза больше платить будете за всё остальное и в штат ещё девопса нужно брать, который будет поддерживать облако, в дополнении к имеющемуся админу, который будет поддерживать так называемое легаси в EC2. И легко затраты на порядок могут вырасти только за счёт зарплаты этого девопса

Ответить
Развернуть ветку
leo krich

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

Ответить
Развернуть ветку
Артём Лисовский

Как активный пользователь Y.functions могу сказать следующее - напрямую их использовать немного страшно, так как флудер легко может покушать ваши деньги. Поэтому оборачиваю в cloudflare.workers, тогда можно придумать и простейший csrf, и вписаться в бесплатный лимит, и сделать базовые методы защиты в духе csrf. Лично мне не хватает дешевого serverless KV-хранилища(такое есть у cf от 5$ в месяц вместе с прочими плюшками) для простейшей логики, платить за Redis дороговато для простого интернет-магазина(про RDBMS речи нет вообще, serverless тоже не хватает, но хотя бы KV). В итоге приходится делать следующую связку:
- cf as nginx
- cf as proxy for Y.functions
- persistance storage at S3/B2/YOS, cache on cf
получается дешево и приятно. Но пока нет под это хорошего фреймворка приходится писать кучу легаси-кода и интегрировать несколько систем.
Serverless прекрасен и его уже можно использовать как PoC или mvp для несложных сайтов/ИМ, но это легаси-легаси.

Я понимаю, что развернуть CMS на serverless легко и если у вас фронт отдельно(грузим в s3/b2/yos), бек отдельно(api на serverless или кеш в s3/b2/yos), то получается всё красиво, но если у вас CMS(для примера django framework с внутренним jinja шаблонизатором), то serverless для средненагруженного сайта без защит может скушать как простая vds(а учитывая, что базово для CMS нужен RDBMS/Redis/memcached, то влетает в копеечку). В итоге приходится рисовать костыли в виде легаси или юзать это для решения каких-то частичных задач. В общем, коробки не хватает под это и кучки сервисов рядом(serverless KV, serverless RDBMS, balancer/router/antiddos). Уже сейчас мы имеем интернет-магазины со не очень большой посещаемостью за копейки в месяц, но это легаси и не каждый масс-маркет разработчик это поймет и сможет связать. Им проще взять хост за 100 руб в месяц и установить, условно, wordpress - поэтому они еще не юзают Y.functions. А если к вам заказчик приходит с запросом какой-нибудь Magento/Bitrix, то тут уже никаким serverless as main не пахнет, только под микросервисы. Такие проблемы.

Ответить
Развернуть ветку
Артём Лисовский

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

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

Ответить
Развернуть ветку
Антон Черноусов

Кстати, мы переодически устаиваем zoombar в нашем сообществе телеграм Yandex Serverless Ecosystem https://t.me/YandexCloudFunctions. Было бы круто послушать ваш кейс. Хотите? Это такие посиделки неформальные, чисто под кофе сидим трепимся. 

Ответить
Развернуть ветку
Артём Лисовский

присоединился

Ответить
Развернуть ветку
Владимир Хазов

Промики на Яндекс.Еду для посиделок раздаете? )))

Ответить
Развернуть ветку
Антон Черноусов

Мы же идейные +) для поделиться опытом, а не для хайринга зазываем +)

Ответить
Развернуть ветку
yesYouStp

приходится писать кучу кода ради экономии на vps, чтобы поставить redis? великолепная математика

интересно либо сколько у тебя стоит написать кучу кода (300рублей чтоли?) или сколько тебе заплатили яндекс.клоуд, чтобы ты заманивал в эти сети

по итогу я видел как такие заманившиеся за обычные пару сервисов, где хватил бы vps за 20 евро, платят по 800-1200 евро в месяц за «умные» слова

разводка на уровне наперсточника на базаре

Ответить
Развернуть ветку
Артём Лисовский
 приходится писать кучу кода ради экономии на vps, чтобы поставить redis?

если вы начнете мыслить проектами с HA scalable, то быстро перейдёте на serverless.
кейсов много - начиная от формирований отчетов раз в месяц, которые жрут ресурсы(не будете же держать инфраструктуру под это регулярно uptime или включать-выключать ручками), заканчивая быстро мастштабируемыми проектами(или event-based проектами, например, голосования онлайн, то же евровидение раз в год условно). тут вас managed не спасёт от падения при наплыве RPS

 интересно либо сколько у тебя стоит написать кучу кода (300рублей чтоли?) или сколько тебе заплатили яндекс.клоуд, чтобы ты заманивал в эти сети

нисколько, напротив, я им плачу

 по итогу я видел как такие заманившиеся за обычные пару сервисов, где хватил бы vps за 20 евро, платят по 800-1200 евро в месяц за «умные» слова

монолит имеет свои плюсы и минусы. у нас есть несколько интернет-магазинов, которые экономят благодаря придуманной инфраструктуре сотни тысяч рублей в год и не знают бед с HA и scalable. монолит прекрасен, но пока у вас vps за 20 евро не начнет захлебываться. про региональные привязки вообще молчу.
по вашей логике swarm/k8s/open shift - вообще непонятно зачем. желаю дорасти и до них :)

 разводка на уровне наперсточника на базаре

видимо, люди, которые платят за страхование жизни 160к в год для вас полные идиоты. не осуждаю, просто вы живёте с другим мировоззрением.
у монолита свои плюсы, у serverless - свои. как только столкнетесь с релевантными проблемами, начнёте понимать зачем serverless, объяснять плюсы serverless разработчику(не про вас, беру сферического коня в вакууме), который делает шаблоны под сайты на wordpress - сложно. ему чужды проблемы, с которыми сталкиваются более крупные ребята, а его задачи решает shared-хостинг за 69 рублей. но это не означает, что Youtube смог бы жить на таких shared-хостингах.

Ответить
Развернуть ветку
Артём Лисовский

допустим, у вас тг-бот который делает N ф-ий, держать под него vps онлайн 24/7 выйдет 5$+, держать под него serverless выйдет в 0.03 рубля в месяц.
аналогичная история для небольших сайтов и ИМ, где нет брони товара в моменте и можно всё закешировать, а ф-ия vps по большей части - сбор заказов, да отправка заявок. тогда ваш хост опять же vps за 5$(вряд ли вы найдёте дешевле) или serverless за 1 рубль в месяц. кроме того, если завтра вы раскрутитесь и будете держать 1000 RPS shared-хостинг быстро скажет вам адьёс, а serverless смаштабируется до любого значения(в случае с кешем - стремимся к бесконечности).

есть еще много разовых задач типа сделать ml-вычисления, тут вам либо в почасовую, либо в serverless по запросу.
или тривиальная задача - html2pdf на бекенде. можно поднять vps с 4гб озу и двумя ядрами(меньше вряд ли потянет puppeter комфортно) за 20$ или перетащить в serverless и запускать по требованию с неограниченными лимитами. кейсов очень много, но опять же повторюсь, чаще это микросервисы.

Ответить
Развернуть ветку
leo krich

"vps онлайн 24/7 выйдет 5$+, держать под него serverless выйдет в 0.03 рубля в месяц"

Это экономия на спичках. Для серьёзного дела нет особой разницы: 5 баксов или 3 копейки. Тем более, что на 5-долларовый сервер можно запихнуть не только бота, но и много чего ещё.

А вот надёжность облаков крайне низкая. По сути, всё завязывается на одного облачного поставщика. Если Яндекс или Амазон вдруг решат отказать в обслуживании (какие-нибудь санкции или что-нибудь ещё), то всё летит к чёрту. Вот vds можно перенести к новому хостеру за пару часов (при наличии бэкапа, разумеется).

Ответить
Развернуть ветку
Артём Лисовский

и часто вам отказывают? берите комплекс из серверлессов в разных облаках,
альтернативу кейсам для обработок(ниже примеры паспорт, из насущного - htm2pdf, video converting и прочие) дешевле на микросервисе облака крутить. держать толпу машин для стихийно возросшего rps - пустая трата денег. но опять же, возможно вы не сталкивались с заказчиками с крупными штрафами за каждую минуту downtime, которая выливается в потерю ими круглых сумм и репутации.

Ответить
Развернуть ветку
Bulat Ziganshin
и часто вам отказывают?

не слышали как РКН положил пол-aws? :)

Ответить
Развернуть ветку
Артём Лисовский

так серверлесс под приватной сеткой как положишь? это ж микросервисы

Ответить
Развернуть ветку
Артём Лисовский
на спичках

так зачем носить коробок, когда можно не носить?)

запихнуть не только

пропускная способность vps в моменте ограничена, серверлесс - автоскейл

не только бота

да, можно, сколько ботов надо по три копейки, чтобы выкупить 5$?
потом один упадёт, надо будет менеджить

надежность

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

Ответить
Развернуть ветку
Александр Епихин

Уточните пожалуйста насчет
- cf as nginx
- cf as proxy for Y.functions
1) cf - в данном случае это Cloudflare Workers?
2) Если ответ на вопрос 1 да, то как маршрутизируете в воркерах и как отсекаете флудеров чтобы они не долбились в Y.functions?

Ответить
Развернуть ветку
Артём Лисовский

1) да
2) капча

Ответить
Развернуть ветку
Артём Лисовский

воркеру можно задать любой урл, поэтому считаю воркера роутером(aka nginx/apache/HAproxy/..)
более дешевого и при этом serverless метода пока не нашли.

Ответить
Развернуть ветку
Александр Епихин

А AWS WAF и throtlling с их API Gateway не пробовали?

Ответить
Развернуть ветку
Артём Лисовский

не пробовал, посмотрю, интересно

Ответить
Развернуть ветку
Антон Черноусов

Скажите а почему не хотите в качестве serverless KV-хранилища попробовать использовать Yandex Database в режиме serverless?

Ответить
Развернуть ветку
Артём Лисовский

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

допустим хочу сделать serverless интернет-магазин, фронт решил полностью хостить статикой, фронт бегает за данными в какой-то кеш(=должно быть апи, апи должно подтягивать данные из кеша), функции выполняются через Y.functions.

и получается, что YDB становится бессмысленной. точнее смысл как персистентное хранилище есть, но как кеш юзать этот KV невозможно.

вторая проблема - стоимость. плюс vps за 5$ с редисом и API в том что можно "RU"(яндексовая условная единица для подсчета операций чтения/записи) проводить без ограничений по количеству. в случае с Y.DB первый млн бесплатно, подойдет для небольшого проекта, но если посчитать для среднего ИМ(20RPS), то 20*60*60*24*31 = 53.568.000, выходит в два раза дороже, чем self-management хост с redis и простейшим api. и тут опять же в лимиты 1RU/request не всегда можно уложиться(4кб на чтение).

Конечно, это намного дешевле, чем держать машину у яндекса, но пока на даже средних оборотах дороже, чем маленький self-hosted, который выдержит куда больше 20RPS в случае с redis на одном shared vps за 5$. получается, что дешевле поднять replicated redis на двух хостах и балансить туда запросы.

к слову, сейчас решаем следующим образом:
- фронт статикой, неважно где хостится, юзаем cf workers as nginx. плюс cf workers - можно сделать роутинг, HA, CDN без ограничений, в случае nuxt(vue) можно полностью сделать "ssr"(беру в кавычки потому что это не совсем так, но мы не об этом) либо сослаться на redis/s3/b2/YOS(обернутые в CDN cloudflare) и оттуда выплёвывать полностью готовые страницы
- для данных имеем бд с cms неважно где(хоть на локали, хоть sqlite или ydb)
- бд преобразуем в кеш в s3/b2/YOS
- чтобы не попасть на read requests YOS оборачиваем в CDN cloudflare(free) и получаем по урлу все наши нужные ответы по api почти совсем бесплатно
- все запросы на вычисления(оформленный заказ, запрос в сапорт, ...) хостим на Y.functions

получается достаточно большая архитектура, но супердешевая(несколько рублей в месяц) с неограниченным масштабированием.
итого, что не хватает в Я:
- balancer aka nginx с роутингом и ssl
- CDN(чтобы снизить запросы на чтение YOS)
- коробки под выгрузку персистентных данных в кеш(YOS)
приходится городить огород, зато полностью serverless и HA за три копейки. как сделать аналогичное еще дешевле и доступнее - не представляю.

YOS крут, но если захостить там картинку для сайта, то может скушать много денег
YDB крут, но к нему напрямую по урлу не обратиться
YF крут, без "но"

Ответить
Развернуть ветку
Александр Епихин

Что такое "- бд преобразуем в кеш в s3/b2/YOS" и как это работает?

Ответить
Развернуть ветку
Артём Лисовский

берем таблицу, например, продуктов, конвертим в json, сохраняем в s3/b2/YOS, получаем ссыль. если у вас 100 категорий, то либо на cf workers фильтруем основной json, либо создаем 100 json-файлов(автоматизировано ес-но).
ссыль с json загоняем в кеш CF(чтобы read-операции не кушали деньгу), при обновлении - скидываем кеш CF

Ответить
Развернуть ветку
Александр Епихин

Так можно закэшировать статичный данные. А как быть с динамикой? Например рекомендации товаров?

Ответить
Развернуть ветку
Артём Лисовский

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

Ответить
Развернуть ветку
Bulat Ziganshin

и после этого встанет вопрос - нафига яндексу такой сервис, на котором он будет зарабатывать 3 копейки? :)

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

Ответить
Развернуть ветку
Артём Лисовский

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

у меня раньше была гипотеза, что при смене оборудования(когда ставят новое) все компании пытаются сдать старое в аренду и делают облака(кому его столько продашь? еще демонтажить же), но далеко не уверен)

Ответить
Развернуть ветку
Bulat Ziganshin

я читал что AWS начался с того, что большая часть серверов амазона была занята только в период рождества LOL

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

Ответить
Развернуть ветку
Борис Ванин

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

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

Ответить
Развернуть ветку
Артём Лисовский
 - у серверлеса совсем другие подходы

да, если плюсы серверлесса не очевидны, видимо у вас не те проблемы, которые требуют серверлеса. это нормально. также как и утверждение "говноязыках вроде жс или питон". посмотрел бы я на web без js - грустное зрелище. на самом деле не важно на чем писать, в jvm-based свои плюсы и минусы, в python - свои. на вкус и цвет фломастеры разные.

 всё равно приходится педалить свои решения

да, но это вопрос времени. Яндекс за пару лет облаков далеко продвинулись.

Ответить
Развернуть ветку
Bulat Ziganshin
если плюсы серверлесса не очевидны, видимо у вас не те проблемы,

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

осмотрел бы я на web без js

ну так фронт пишут на js исключительно потому что выбора нет

Ответить
Развернуть ветку
Борис Ванин
 да, если плюсы серверлесса не очевидны, видимо у вас не те проблемы, которые требуют серверлеса

это точно ответ на мой комментарий?

 да, но это вопрос времени

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

Ответить
Развернуть ветку
Артём Лисовский
точно ответ на мой комментарий?

прошу прощения, видимо другой тред читал перед комментом

Ответить
Развернуть ветку
Rustam Apaev

Бен Авад тот ещё тролль. Через неделю он выпустит видео, где будет угорать над подписчиками: "Вы не поняли что это шутка? Я обожаю серверлесс, не думал что вы воспримите всерьез".

Ответить
Развернуть ветку
Аккаунт заморожен

Очень много слов без конкретики. Разве что про зависимость от поставщика сказали. "Несколько меньший контроль над ресурсами" – на сколько меньший и каким образом проявляется? Для каких случаев это будет критично, для каких не принципиально?

Ответить
Развернуть ветку
yesYouStp

“Бессерверные вычисления позволяют быстрее создавать бизнес-ценность” - это очевидная ложь

Ответить
Развернуть ветку
Артём Лисовский

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

Ответить
Развернуть ветку
Артём Лисовский

допустим, вы распознаете серию-номер паспорта по фотке в банке. как будете решать?
можно взять vps, но тогда встает кучка вопросов - операция требует ресурсов, окей, купим. данные нормально защищены? постоянно работающая машина, при том, что ночью запросов в 20 раз меньше - это эффективное использование ресурсов? а если завтра про вас снимет рекламу Дудь, вы справитесь с потоком 20000 обработок паспорта в секунду?
и тут приходит serverless как микросервис - он выполняет ровно одну задачу без ограничений по ресурсам, экономя вам моменты простоя. бизнес-ценность? именно она

в случае с managed вам ни один сисадмин не обеспечит увеличение потока в 100 раз, а если в ДЦ оборвался интернет, вы не потеряете клиентов. serverless это может уже вчера

Ответить
Развернуть ветку
Артём Лисовский

не пытаюсь сказать, что это silver bullet, но это решает определенные проблемы, список которых достаточно велик.

Ответить
Развернуть ветку
Yuri Trenin

Начнем с того, что под "бессерверными вычислениями" их популяризаторы-курильщики подразумевают FAAS, а вовсе не вычисления на ресурсах распределенной мэш-сети, как бы мог подумать здоровый человек.

Далее, да просто вдумайтесь, а где происходят эти самые "бессерверные вычисления"? Да на серверах они и происходят. Но, как же так, они же бессерверные! То-то же робята, такое чувство, что нас снова пытаются где-то нахлобучить...

Но это все лирика, а по фактам имеем с облаками и FAAS две большие проблемы:
№1 Архитектурная
№2 Экономическая

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

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

2 Просто посчитайте себестоимость выполнения сферической pure function в вышеупомянутой стойке, с учетом з/п администраторов / тех. персонала, стоимости аренды стоек в ДЦ, амортизации оборудования на 5-летнем горизонте. И вы снова удивитесь насчет нахлобучить. Вроде бы в облаке вы не несете всех вышеуказанных расходов и на это напирают продавцы белогривых лошадок. А по факту FAAS выходит в раз пять дороже. Пруфов этому утверждению не будет, реально заинтересованный начнет считать, гуглить расходы стартапов на облака и все сам себе докажет. А облачнонутым товарищам я предоставляю полное право написать что-нибудь токсичное, ну и далее все также с хрустом пилить деньги инвесторов, они ведь не ваши, чего стеснятся. Ну ничего страаашного, уаф уаф!       
    

Ответить
Развернуть ветку
Артём Лисовский
 никогда не сможет сесть на динамически выделяемые и массово переиспользуемые множеством клиентов облачного провайдера вычислительные ресурсы

вы из мира монолита? просто микросервисная архитектура как раз делает то, что является FAAS. на входе лежит очередь(rabbit/kafka/YQ/plain requests..), из неё растут сервисы, каждый под свою задачу. если у вас 20 раз в день надо html2pdf сделать, держать в поднятом режиме под это сервис/машину(а там будет какой-нибудь puppeteer которому дай 4гб оперы) - неэффективная в плане денег затея, тут и приходит FAAS/Serverless - когда машина не запущена 100% времени, а запускается по требованию за три копейки под запрос с нужным количеством памяти и прочего.

 по факту FAAS выходит в раз пять дороже

вы явно из мира монолитов. есть тысячи задач, которые требуются раз в день/месяц/...(например, составить отчет, который скушает 4гб оперативы пока будет вычисляться, datascience/ml/..). держать под каждую из них машину - дорого. особенно, если у вас будет в моменте запрос на 40 таких отчетов. тут либо очередь, либо serverless, когда ты просто на минуту берешь 40 машин и выдаешь результат. не представляю как ваш сисадмин в момент запроса соскалирует ваш монолит(или его часть) в 40 раз(никак). а держать пул suspended-машин - дорого и подниматься они будут не милисекунды. а FAAS это делает уже вчера за милисекунды. в итоге это и быстро, и дешево. если для вашего клиента на монолите нормально сообщение "мы предоставим вам сервис в порядке очереди и отправим ответ на почту, вы 45ый, обработаем ваш запрос через полчаса", то да, монолит с очередью - гуд. иначе у вас выход только медленно скалируемый и золотой оверхед из машин или быстроскалируемый и дешвый серверлесс.

безумно можно быть пеервым...

Ответить
Развернуть ветку
40 комментариев
Раскрывать всегда