Комментарии 29
Самая большая проблема Serverless в том, что не существует сложившихся практик по управлению ответственностью за части и функции систем в serverless-парадигме. Ответственность за функции становится размазана по всей кодовой базе, и все отвечают за все
Функциональный компонент — несколько связанных по смыслу, целям и данным функций вместе с другими ресурсами — storage buckets, bigquery datasets and tables, pubsub topics, servcice accounts, IAM roles, secrets, cloud schedulers, log sinks, firestore collections, subnetworks, routers, nats, etc. Все эти ресурсы — в одном репозитарии, и управляются в помощью cloud build + terraform…
Из недостатков — парадигма очень непривычная. И часто отторгается прямо сходу.
Из того, что мне нравится — операционные затраты (в моём случае) как минимум раз десять меньше, чем AppEngine, GCE or GKE. И возни меньше — в смысле каждодневной поддержки.
- Как вы решаете вопрос с общей логикой (бизнес- и инфрастуктурной) при разделении приложения на несколько функций? Это какой-то общий модуль который есть в каждой функции и все функции деплоятся одновременно по каждому коммиту или как-то иначе?
- По каким критериям вы решаете что нужно разбивать сервис/приложение на несколько функций вместо одной?
Мне кажется, что есть ситуации, когда функции очень хорошо подходят.
В качестве возможного критерия — очень неравномерная и случайная нагрузка — например десять минут (полчаса) ничего нет, потом сотня (или тысяча, или десять тысяч) вызовов, потом опять несколько минут (или десятков минут) — пауза. И так далее. В паузах тоже могут быть вызовы, но редко, к примеру.
Довольно большая задержка, большое время отзыва (latency). То есть если нужны миллисекунды или секунды — то сложно будет реализовать. Если десять секунд на вызов (всего процесса, или одной функции) это всё ещё годится — то можно рассматривать функции.
Функции должны быть полностью idempotent. Не важно сколько раз она вызывается на одинаковом наборе данных — результат будет один и тот же. Например, если один набор данных уже обработан, то при вторичной обработке результат не меняется. Очень может быть, что для такой работы нужно будет где-то снаружи функции («база данных» в любом виде) хранить машину состояний процесса (для данного набора данных).
Функции между собой взаимодействуют строго асинхронно — через сообщения в pubsub топиках.
Таким образом всю задачу функционального компонента нужно разбить на этапы, которые выполняются последовательно (некоторые могут идти и асинхронно параллельно, а потом на каком-то этапе результаты синхронизируются), с временными разрывами между выполнением каждого этапа, и с возможностью повторения этапа при сбое.
Serverless хорош когда тебе нужно закинуть личного бота для телеграма или сайт визитку, и пускай он там себе крутится за копейки, если не вообще бесплатно, использовать serverless для чего-то большего дикое извращение, ограничений выши крыши, расходов тоже, в добавок туда идет еще тераформ и прочее, в итоге нужна пачка клауд инженеров, чтоб хоть что-то двигалась, при этом плюсов больше нет, есть только минусы, и дыры в бюджете.
Самая большая проблема Serverless это её стоимость при большом скейле. Все остальное решается и решается довольно просто. За три года разработки мы уже наступили на все вышеупомянутые грабли и нашли им решение. При больших нагрузках намного дешевле содержать stateless решение на автоскейлинг группе на тех же спотах, к примеру, чем поднимать миллионы функций.
Хочу сделать комплимент автору за сбалансированный взгляд на проблему. Даже создал аккаунт специально для этого.
Я отношусь к тому малому бизнесу (стартап) который получает указанные приеимущества скорости разработки и цены. Роботал 30+ лет в индустрии
Мы используем Microsoft Azure и они предлагают более дорогой сервис, чтобы увеличить скорость первого ответа холодного микро сервиса.
Проблемы упомянутые в комментариях решаются грамотной архитектурой и планированием devops.
Trade-offs всегда будут присутствовать, задача из определить и сделать выбор наиболее подходящий для бизнеса.
Автор явно понимает как это делать.
Дочитал до того что скорость отклика не важна для разработчика, после этого не смог себя заставить читать дальше. Паноптикум девелоперский. Софт для пользователя, и пользователю всегда важна скорость отклика. И как отличать тормоза нового релиза от проблемы холодного старта?
С другой стороны бывает очень много случаев, когда абсолютно неважно — будут ли данные обработаны за 15 секунд, или за 18, к примеру. Или за 3 минуты, или за 4 минуты. Потребителю данных это не очень важно. Он занят чем-то ещё. Когда данные будут готовы — он к ним обратится.
Скорость отклика важна для всех интерактивных приложений, где установленные десктопными приложениями тридцать лет назад стандарты — отклик менее 300 мс — уже давно являются привычными, а значит необходимыми для того, чтобы пользователь от вас не свалил.
Просто, кроме работы с людьми, есть очень много случаев, когда потребитель данных — просто не человек за GUI, который ждёт синхронного ответа здесь и сейчас.
снижение риска сбоев в работе
Откуда вы вообще взяли это смелое утверждение. В микросервисной архитектуре всё как раз наоборот – с ростом количества отдельных компонент экспоненциально растёт сложность целой системы, и такими же темпами растёт вероятность отказов и сбоев. Особенно это касается межпроцессного и тем более сетевого взаимодействия, где ошибки соединения это вообще в порядке вещей. Именно поэтому сейчас часто на всяких сайтах можно наблюдать 500-е ошибки, вызванные разрывом связи между фронтовым нджинксом и бэком. Раньше таких ситуаций почти не было, я не помню ни одной.
Пробовал серверлесс, оно даже в проде постоянно AWS Lambda на Python крутится, но, как разработчик могу добавить минусов:
- гораздо дороже в разработке, отладке и развёртывании — или неэффективное использование времени разработчиков на то самое администрирование, от которого облака обещали избавить, или найм администраторов (которые нынче дороже разработчиков если дописали "девопс" к позиции), которые будут делать это эффективнее
- инфраструктура усложняется: чтобы запустить скрипт на десяток строк в ответ на http-запрос, нужно настроить больше десятка сущностей "мышкой" чтоб хоть как-то завелось, предварительно решив финансово-организационные вопросы типа создания корпоративной карты для оплаты и пинания бухгалтерии чтобы там деньги были
- риски влететь на деньги из-за непредсказуемой нагрузки и невозможность оперативно это понять, если не тратить ещё больше денег. Вон недавно влетели на 250$ долларов сверх обычных счетов, потратил своего времени уже на 2000$ чтобы не допустить подобного в будущем и то, понимаю, что это лишь уменьшает вероятность попасть, а не исключает.
- ограниченный список поддерживаемых языков/платформ. Для части неподдерживаемых есть костыли, но они жрут ресурсы и увеличивают время отклика
Google или Amazon становится вашим миноритарным акционером.
С учетом истории с telegram и parler, понятно, что у этого акционера есть место в совете директоров и должность зам президента по инфраструктуре с правом операционных решений.
Могу лишь процитировать шутку Александра Горного из United Investors:
— Сколько будет стоить ежедневная уборка моего бизнес-центра?
— 0.2% вашей выручки.
— Можете организовать обеды для сотрудников?
— 3% выручки.
— Бумагу для принтера?
— 0.01% выручки.
Pay-as-you-go (плата за реальное пользование)
Так, можно запускать функции с некоторой периодичностью, чаще запускать сервис или держать часть контейнеров запущенными все время
Действительно, никакого противоречия.
Почему разработчики не дружат с Serverless