Комментарии 29
Очень лукавый диалог: опровержение антитезисов, которые сам вбрасываешь.

Самая большая проблема Serverless в том, что не существует сложившихся практик по управлению ответственностью за части и функции систем в serverless-парадигме. Ответственность за функции становится размазана по всей кодовой базе, и все отвечают за все
Да тут разные варианты возможны. Для небольшой команды наверное лучше что то вроде serverless который сам создаст функцию и нужные ресурсы для нее, и все это в одном репо.
Для больших проектов — terraform для самой функции, ее настроек, IAM ролей и тп а деплой кода через deployment pipeline (jenkins например).
Уже пару лет пишу функции в GCP.
Функциональный компонент — несколько связанных по смыслу, целям и данным функций вместе с другими ресурсами — 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. И возни меньше — в смысле каждодневной поддержки.
Если я правильно понял, то вы «сервис» разбиваете на несколько функций? Если так то очень интересны 2 момента, если конечно не секрет:
  1. Как вы решаете вопрос с общей логикой (бизнес- и инфрастуктурной) при разделении приложения на несколько функций? Это какой-то общий модуль который есть в каждой функции и все функции деплоятся одновременно по каждому коммиту или как-то иначе?
  2. По каким критериям вы решаете что нужно разбивать сервис/приложение на несколько функций вместо одной?
Сначала про деплоймент. Cloud Build trigger based on git push (to origin). Все ресурсы деплоятся с помощью terraform. В простейшем случае всего две команды — init, apply. Код может деполоится как с помощью того же terraform, так и отдельно, следом (в том же yaml файле). Если функций много и они живут в отдельных директориях, лучше деплоить их отдельно. Пример (аналогичный) — что делать если функций много — на stackoverflow — stackoverflow.com/questions/65826696/how-to-implement-ci-cd-using-google-cloud-build-for-multiple-google-cloud-functi
На мой взгляд, cloud function не панацея, и пихать везде не нужно. Желательно оценивать — где cloud function хорошо будут работать, а где нет. При этом учитывать ограничения. Например — максимальное время выполнения, или максимальный доступный объем памяти. Есть и другие ограничения…

Мне кажется, что есть ситуации, когда функции очень хорошо подходят.

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

Довольно большая задержка, большое время отзыва (latency). То есть если нужны миллисекунды или секунды — то сложно будет реализовать. Если десять секунд на вызов (всего процесса, или одной функции) это всё ещё годится — то можно рассматривать функции.

Функции должны быть полностью idempotent. Не важно сколько раз она вызывается на одинаковом наборе данных — результат будет один и тот же. Например, если один набор данных уже обработан, то при вторичной обработке результат не меняется. Очень может быть, что для такой работы нужно будет где-то снаружи функции («база данных» в любом виде) хранить машину состояний процесса (для данного набора данных).

Функции между собой взаимодействуют строго асинхронно — через сообщения в pubsub топиках.

Таким образом всю задачу функционального компонента нужно разбить на этапы, которые выполняются последовательно (некоторые могут идти и асинхронно параллельно, а потом на каком-то этапе результаты синхронизируются), с временными разрывами между выполнением каждого этапа, и с возможностью повторения этапа при сбое.
Тут недавно одни жаловались на AWS из-за кучи скрытых лимитов и невозможности пользоваться встроенными системами для балансировки и HA, везде есть глюки, для этого есть целая команда которая занимается изучением возможностей AWS и подстраиваются под них или делают свои решения. А а тут вообще хрен знает как оно будет работать и будет ли вообще так как мне надо работать да и дорого. А если не будет, то всё переделывать при резко выросшей нагрузке?
Для меня непрозрачность и непортируемость serverless решений перекрывают все достоинства.

Spring cloud function решает вашу проблему (если вы пишите на. Java)

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

Пользуюсь по работе для message driven data pipelines. Стоит копейки, основная проблема для меня — ограниченный размер контейнера: нельзя скачать большой файл, чтобы обработать и залить обратно. Приходится разбавлять контейнерами на Fargate.

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

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


Я отношусь к тому малому бизнесу (стартап) который получает указанные приеимущества скорости разработки и цены. Роботал 30+ лет в индустрии


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


Проблемы упомянутые в комментариях решаются грамотной архитектурой и планированием devops.


Trade-offs всегда будут присутствовать, задача из определить и сделать выбор наиболее подходящий для бизнеса.


Автор явно понимает как это делать.

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

Наверное бывает много ситуаций, когда скорость отклика важна. Для пользователя, который «сидит» и ждёт этот отклик. И ничего при этом не делает.

С другой стороны бывает очень много случаев, когда абсолютно неважно — будут ли данные обработаны за 15 секунд, или за 18, к примеру. Или за 3 минуты, или за 4 минуты. Потребителю данных это не очень важно. Он занят чем-то ещё. Когда данные будут готовы — он к ним обратится.

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

Конечно. Абсолютно с Вами согласен.

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

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

Раньше было просто refused to connect, если апач прилег то и 503 отдать некому (если нет лб).
Не хватает пункта: просто используем для подходящих задач.

Пробовал серверлесс, оно даже в проде постоянно AWS Lambda на Python крутится, но, как разработчик могу добавить минусов:


  • гораздо дороже в разработке, отладке и развёртывании — или неэффективное использование времени разработчиков на то самое администрирование, от которого облака обещали избавить, или найм администраторов (которые нынче дороже разработчиков если дописали "девопс" к позиции), которые будут делать это эффективнее
  • инфраструктура усложняется: чтобы запустить скрипт на десяток строк в ответ на http-запрос, нужно настроить больше десятка сущностей "мышкой" чтоб хоть как-то завелось, предварительно решив финансово-организационные вопросы типа создания корпоративной карты для оплаты и пинания бухгалтерии чтобы там деньги были
  • риски влететь на деньги из-за непредсказуемой нагрузки и невозможность оперативно это понять, если не тратить ещё больше денег. Вон недавно влетели на 250$ долларов сверх обычных счетов, потратил своего времени уже на 2000$ чтобы не допустить подобного в будущем и то, понимаю, что это лишь уменьшает вероятность попасть, а не исключает.
  • ограниченный список поддерживаемых языков/платформ. Для части неподдерживаемых есть костыли, но они жрут ресурсы и увеличивают время отклика
Изучите SAM и CDK и «ваши волосы снова станут шелковистыми»
С точки зрения бизнеса проблема не в vendor lock-in — закрытость OSX, Windows и OracleDB никого в enterprise не пугает. Проблема в ценообразовании пропорционально выручке, потому что общая нагрузка на все подсистемы прямо коррелирует с выручкой.
Google или Amazon становится вашим миноритарным акционером.
С учетом истории с telegram и parler, понятно, что у этого акционера есть место в совете директоров и должность зам президента по инфраструктуре с правом операционных решений.

Могу лишь процитировать шутку Александра Горного из United Investors:
— Сколько будет стоить ежедневная уборка моего бизнес-центра?
— 0.2% вашей выручки.
— Можете организовать обеды для сотрудников?
— 3% выручки.
— Бумагу для принтера?
— 0.01% выручки.
зато на этапе стартапа можно жить вообще бесплатно. А учитывая что 99 из 100 стартапов так никогда до прибыли и не доживают, то это просто лучшее решения для старта
Pay-as-you-go (плата за реальное пользование)

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

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