Comments 9
А для НЕ-google-like пользователей есть смысл и реальные примеры использований serverless?
Я вот не могу придумать ситуации, когда оно будет выгоднее чем некая фиксированная машина (пусть даже с запасом мощности на всплески).
Привет! Вот пример из реально жизни.
Есть сервис, который ставит цифровые подписи на пдф. Подписи начинают ставить ближе к вечеру. Днем нагрузки вообще нет.
Серверлесс помогает в трех ситуация.
Вы не потребляете ресурсов, когда нет нагрузки. То есть нет документов на подпись зачем крутить целый сервис? Учитывая, что многие компании сейчас начинают экономить ресурсы - это несравнимый плюс.
Когда запросов становится очень много, система начинает плодить новые инстансы функции, чтобы справится с запросами. И это все из коробки, ничего не надо самому накручивать.
Удобство для разработчика. Мне как разработчику нужно написать только метод, который получает байтовый массив и еще какие параметры и отдает документ с подписью. А уже на уровне инфраструкруты мы настраиваем откуда нам попадают эти параметры - через http, очередь или файл с диска. То есть я пишу только бизнеслогику, не заморачиваясь маштабированием, подключением к источникам данных и т.д.
Я примерно так это и представлял, но интересуют реальные цифры все же, потому что:
Сервис, который ничего не делает и так не потребляет ресурсов, пусть крутится.
"Очень много" - это так много, что все свободные "другие" ресурсы не справятся? А точно? А проверяли? А каждый раз так?
Мне лично нравится работать с со всем стеком целиком, но тут вкусовщина конечно.
Само-собой, в теории, потребление "только вечером" будет дешевле. Но вот на практике, условная дополнительная VDS на bare-metal k8s кластере будет обходиться в несколько раз дешевле, чем реальное облако. Плюс безлимитный трафик.
P.S. Мои наблюдения относятся к "земным" потреблениям. Если у вас миллионный трафик, возможно разница в затратах будет не такая существенная конечно.
Есть плюс в том, что проблемы reliability остаются за кадром и не нуждаются в отдельной обработке приложением.
Это наверное не так актуально для http-функций, но например для функций которые обрабатывают сообщения проходящие из условной очереди - это позволяет не думать о том что подписка на очередь может внезапно оборваться из за проблем с сетью. Или лок на партишен не переосвободится из за рестарта процесса.
С точки зрения функции - ей на вход просто приходит одно сообщение, которое надо обработать, а вся инфраструктура и работа по преобразованию «источник данных => входные параметры» остаётся за кадром.
Можно ли это обеспечить своими силами на голом железе? Можно, однозначно, вопрос только в объёме работы. Retry, DLQ, Throughput limiter. Обо всем этом надо вспомнить и подумать на этапе проектирования/разработки и корректор сделать. А в случае Azure Functions - это все есть из коробки и позволяет сосредоточиться на бизнес-логике.
Есть неточности в разделе про Knative. Во-первых, он не требует Istio, это лишь опция. Во-вторых, не упомянут GCP Cloud Run.
Сначала 1 человек форсил serverless, потом 2. Теперь Флант подключился. Как-то вас кусают...неспешно.
Совсем не вижу «форсинга» в этой статье ;-)
ну, да, это модная и хипстерская тема. Не говорите никому, но тут даже вроде деньги предлагают за статьи про серверлесс...
Вообще на самом деле я уже видел много проектов на knative и люди с этой технологией счастливы, так как она позволяет упростить создание приложений.
Внутри кластера фреймворк поддерживается силами Knative operator, который использует Serving и Eventing, чтобы создавать необходимые объекты в Kubernetes — например, Pod’ы.
это не так. Оператор сам по себе нужен, чтобы настроить среду для Serving и Eventing - вместо установки через kn или хельм чарты. Сами пользовательские приложения через оператор, как я понял, не заезжают.
Для работы в Kubernetes требуется Docker — не понятно, как быть, когда от Docker окончательно откажутся.
такая ли большая это беда для OpenWhisk при условии, что даже с containerd мы прекрасно можем гонять dind?
Обзор self-hosted serverless-фреймворков для Kubernetes