Как стать автором
Обновить

Комментарии 85

Почему весь рынок все еще не перешел на Serverless

Так озаглавить раздел статьи и при этом заполнить его дифирамбами serverless-у это определенно талант.
Сколько будет стоить серверлесс аналог 2xIntel Xeon Gold 6254 + 256Gb ram + intel optane?
Если вы равномерно плотно займете весь озвученный объем вызовами круглосуточно то конечно чистое железо обойдется вам значительно дешевле, на вскидку в два раза у любого провайдера.

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

Ваша "вскидка" очень далека от реальности.
Четыре года назад aws lambda была примерно в два раза дороже облачных решений от самого же амазона.
Разница облачных решений амазона к bare metal на единицу производительности была емнип х10

да, я конечно имел ввиду FaaS против серверов от провайдера, а не bare metal

Два года назад считал, получалось что ec2 выгоднее lambda при утилизации больше 60%, а если еще оптимизировать косты на ec2 (RI, spot-ы) — то в разы.

Серверлесс аналог пустого 2xIntel Xeon Gold 6254 + 256Gb ram + intel optane будет стоить 0.00$.

Как на CAPEX расходы смотрит финансовый директор?
> Почему весь рынок все еще не перешел на Serverless?

Отвечу на вопрос за автора статьи.
Потому что нет единого стандарта.
Во времена cgi скриптов у нас была только файловая система и она была стандартной.
Во времена lamp у нас была база данных и файловая система и они были стандартными. (Любой хостинг предоставлял стандартную среду, которую любой разработчик за 10 минут мог воспроизвести у себя на локальной машине. Могли отличаться версии и подключенные модули, но в целом стандартное.)
Во времена кубера у нас предоставляется стандартная среда по которой в любом облаке из стандартных докер-кирпичиков поднимается ваше приложение со всем окружением. Ты уже даже не зависишь от того что там наконфигурили в апаче.

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

Ну и цена. Конский ценник. Простенький сервис на го с двумя инстансами ec2-micro и балансировщиком обойдётся в пару десятков баксов а сможет тянуть тыщу запросов в секунду. Безсерверные функции в таком случае станут выгодны только если вы реально будильниками в Москве управляете и у вас пик нагрузки укладывается в пару часов а потом мёртвое время.
Холодный старт еще забыли. Причем это проблема by design. Никто не будет вам держать инстансы с задеплоенным кодом наготове что-бы обслужить внезапно прилетевшие запросы. Единственное что могут предложить облачные провайдеры это «прогрев» инстансов, что очевидно противоречит pay-as-you-go.

Яндекс в мире никому он нужен.
Амазон + лямбда + популярнее всего либо питон либо нода, вот вам и стандарт.
Только серверлесс нишевая технология и всё равно не заменит всего.

А потом Амазон говорит, что вы разработали серверлесс социалочку, которая им не нравится, пожалуйте на выход.
И всё, приплыли.
Кроме социалочки может быть приложения для конвертации чего-либо (придут жалобы от копирастов и бежать будет некуда), либо какие-то другие варианты.
Тот самый жуткий случай, когда бан у провайдера вычислительных ресурсов будет означать 100% смерть проекта.
Подавляющее большинство серьёзных проектов используют AWS, но, естественно, нужно планировать с учётом специфики вашего проекта. Некоторые сомнительные проекты не могут себе позволить размещаться где либо, кроме собственных серверов в принципе и прячутся за различными зеркалами.
Мы просто живём в такое время и в таком мире, где сомнительной может быть признана любая деятельность.
Там набегут патентные тролли, копирасты, защитники негров; у нас ограничат право на распространение знаний («госдума приняла в третьем чтении законопроект, обязывающий согласовывать просветительскую деятельность с органами власти»).
Даже если сделать школьный чатик, придет ФСБ, как только узнает о существовании оного; если сделать каталог с картинками, посадят за мемасики с попами.
Я говорю о бизнес проектах и просчитывать бизнес риски, в том числе политические, нужно заблаговременно и строить архитектуру проекта с их учётом обязательно.
Боязнь облаков свойственна больше Российским проектам, т.к. видимо, здесь политические риски несколько выше.
Но serverless на мой взгляд, это всё же про облака, поэтому если у вашего проекта есть политические риски, то вероятно лучше использовать другую технологию, благо на serverless свет клином не сошёлся.
Та же история с Azure Functions. Пару лет назад эмулятор сильно сильно отличался от облака. С холодным стартом вообще жопа, первый запрос поднимает хост за 20-30 сек на Y1 tier. А еще баги хостового приложения… там еще боль в общем.
Еще один довод не пользуваться сервисами от Azure
Пару лет назад Azure был сырым, сейчас он гораздо более зрелый, но дебаг серверлесс это в любом случае боль.
Просто следующая ступень декомпозиции и выворачивания кишками наружу минимальных единиц исполнения кода. Были уже IaaS, PaaS, SaaS, теперь доехали до FaaS (function as a service).
Но как по мне, serverless — название неудачное. Какой нафиг серверлесс, если все вычисления выполняются на серверах?
Вы правы, началось все с FaaS, но стало понятно что одними функциями нельзя ограничиваться. Тогда нашли название, под которое можно собрать ряд сервисов с похожим способом использования. Под капотом как и прежде работают сервера и от этого никуда не уйти.
Когда пропустил появление Docker, ругал себя, и тут же следом проморгал Kubernetes.

Сейчас нужно изучать Serverless

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

Мы не используем Serverless, потому что непонятно, в каких кейсах использовать эту технологию и чем она выгоднее традиционного подхода.

НЛО прилетело и опубликовало эту надпись здесь
Я лично для себя увидел только 2 применения:
1) Скрипты, которые нужно запускать где-то в облаке раз-два в день максимум. Но такое мне проще закинуть на личную VPS (собственно, она у меня и превратилась в такую помойку). Всякие боты для друзей и прочее
2) Проекты с рваной нагрузкой. Но, учитывая цену той-же Lamda нужно еще посчитать, что выгоднее, держать мощный инстанс 24/7, или платить за выполнение. У меня в большинстве случаев держать инстанс было дешевле (даже без учета времени разработчиков, лол)
Почти у всех провайдеров есть программы типа free tier и если реально сесть и посчитать то большинство рутинных операций укладывается в предоставленные лимиты для хоббийного применения.

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

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

НЛО прилетело и опубликовало эту надпись здесь
я не ощутил преимуществ этих технологий против нормально работающего k8s стека

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

Пальцем в небо предположу что у вас очень несложное приложение.


Кубик и так-то выглядит оверкилом, если у вас нет хотя бы полутысячи подов.
А для той области где заходит serverless он вообще безумно громоздок.

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

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


Вы сильно лукавите (если не сказать врете) относительно оценки размеров «небольшого».

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

отсутствие vendor lock и наличие стандартных технологий в подах…
Но есть нюансы...

Риски вендор лока сильно переоценены, как по мне.

Сколько работал с микросервисами в энтерпрайзах и в стартапах, готовый продукт обычно был от двух десятков до сотни компонентов. И обычно это несколько девелопмент окружений, qa, perf, стейджинг. Да имхо даже десяток подов, но когда есть разграничение по командам разработки и окружениям удобнее запускать в кубернетс. И с точки зрения централизованного управления правами, политиками, внешним доступом, и с точки зрения оптимального использования ресурсов виртуалок.
НЛО прилетело и опубликовало эту надпись здесь

Сложно согласиться с Вами, поскольку опыт диаметрально противоположный, и возникает встречный вопрос — кто эти люди, кто готов платить за кублеты, которые по сравнению с FaaS в связки с прочим serverless, стоят как космическая программа NASA :)


В случае serverless Вы получаете три неоспоримых преимущества (не буду указывать провайдера, чтобы не сочли за рекламу)
1) Плата только за использование, то есть стоимость равна интегралу под графиком используемых ресурсов — в случае же кубов, приходится платить за весь прямоугольник, причем высота прямоугольника — это точка пиковой нагрузки
2) Условно-бесконечная масштабируемость — количество ресурсов предоставляется по требованию, причем масштабирование — мгновенное, в то время как кубов лимитированное количество
3) Отсутствие накладных расходов на обслуживание — FaaS доступен с огромным SLA, и вендор гарантирует это финансово, в то время как парк кубов вполне себе может зависнуть или подвергнуться взлому из-за неправильного администрирования


В целом, мне так и не удалось представить ситуацию, когда кубы будут выгоднее serverless. Если мощность кубов огромная, то придется платить 24/7 даже при нулевой нагрузке на приложение. Если кубов мало, то при пиковых нагрузках будет просто отказ от обслуживания :)
Если вы не размером с Booking или Tripadvisor, которыми пользуются круглосуточно, то большую часть времени кубы будут просто простаивать и потреблять огромное количество денег
С serverless такие проблемы забыты как страшный сон

1) Плата только за использование, то есть стоимость равна интегралу под графиком используемых ресурсов — в случае же кубов, приходится платить за весь прямоугольник, причем высота прямоугольника — это точка пиковой нагрузки

hpa, descheduler, и прочие технологии — позволяют делать "дышащий" кластер k8s. И экономить деньги относительно его размера при пиковой нагрузке.


2) Условно-бесконечная масштабируемость — количество ресурсов предоставляется по требованию, причем масштабирование — мгновенное, в то время как кубов лимитированное количество

это недостоверная инфа.


3) Отсутствие накладных расходов на обслуживание — FaaS доступен с огромным SLA, и вендор гарантирует это финансово, в то время как парк кубов вполне себе может зависнуть или подвергнуться взлому из-за неправильного администрирования

скорее да, чем нет. Но все равно сложность FaaS с точки зрения количества компонентов и взаимосвязей между ними существенно выше, чем у контейнеров,


Если вы не размером с Booking или Tripadvisor, которыми пользуются круглосуточно, то большую часть времени кубы будут просто простаивать и потреблять огромное количество денег

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

скорее да, чем нет. Но все равно сложность FaaS с точки зрения количества компонентов и взаимосвязей между ними существенно выше, чем у контейнеров

Serverless это не только FaaS. Это еще и базы, хранилища, шины и тд. И сложность взаимосвязей здесь определяется архитектурой вашего сервиса, а не платформой. Может быть s8s несколько сложнее в разворачивании и конфигурации (потому что для s8s пока нет пока такого комбайна, как кубер), зато задач обслуживания гораздо меньше

Кстати опять-таки по опыту serverless куда проще и удобнее в разворачивании и конфигурации, как минимум есть SLS (serverless framework) и аналогичные утилиты для автоматизации, но и вендорные SDK тоже простые и удобные
Чего не сказать о кубах, в которых конфигурация по сложности как отправка космического корабля :)
И очень верное замечание про БД и шину — в кубах это все ложится на плечи администратора, и если где-то все зависнет или застрянет в deadlock-е, но это нереально сложно и найти, и отладить
В случае serverless есть просто БД, шина, HTTP(S) сервер бесконечного* объема, который сам масштабируется под капотом, и единственное что необходимо — только оплата


* Конечно бесконечный объем ограничен возможностями дата-центров вендора, но он на порядки больше, чем любая мыслимая конфигурация кубов

И очень верное замечание про БД и шину — в кубах это все ложится на плечи администратора, и если где-то все зависнет или застрянет в deadlock-е, но это нереально сложно и найти, и отладить

ну что за чушь… Прям набор стереотипов. Нормальные пацаны (с) с кубами используют точно так же managed DB и managed queue. По возможности.


Чего не сказать о кубах, в которых конфигурация по сложности как отправка космического корабля :)

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

Лямбду тоже можно запустить локально, только зачем? Зачем сейчас что-то запускать локально?

Зачем сейчас что-то запускать локально?

я, надеюсь, это риторический вопрос?
Ну, например, потому что такой цикл разработки принят в конкретно взятой команде или учреждении.

А с точки зрения цикла разработки, какая разница, где конкретно запущен код, в облаке или локально? Более того, отлаживать лучше там, где код будет исполняться, а не в симулированном окружении локально.

Ну, тут Вы и попались.
Разрабатывать — лучше в изолированном окружении. Чтобы не аффектить прод. К тому же — чем более удалён стенд разработки от машины разраба, то тем медленнее разработка. Цикл внесения изменений. Это неприемлемо.
С чем соглашусь — так это с тем, что разработческий стенд и стенды для тестов/превью должны быть максимально приближены к продакшену, но это в каждом случае решается индивидуально и полного соответствия никогда получить не получается. Всегда есть какая-то, но минимальная погрешность. Поэтому — стоит ли вообще сильно переживать из-за этого?

Точно, Вы напомнили еще одно огромное преимущество serverless — возможность разработки и отладки прямо в облаке :)
Благодаря тому, что без нагрузки serverless бесплатен, это дает возможность каждому разработчику отлаживаться прямо в облаке
В нашем проекте у каждого разработчика есть несколько изолированных stage-ей, и все это почти ничего не стоит по деньгам
Чего не сказать о кублетах, которые всегда присутствуют как синглтон, и развернуть рядом вторые кубы — уже очень дорого и нерентабельно

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

Ниже уже объяснял, почему это не так ) Уж не знаю, чем Вас куб обидел, но обида явно очень глубокая, прям смертельная )

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

Ну код FaaS можно запускать локально, это ж код. Но удобство FaaS в том, что развернуть код в облаке можно очень быстро, буквально несколько секунд (почти все IDE умеют сейчас это делать по щелчку), и вы можете проверять именно в том виде, в котором он будет работать на проде. Естественно что отлаживаться вы будете в тестовом окружении, но оно будет как прод. Например, вы можете на этом окружении запросто запустить нагрузочные тесты в полном масштабе.
И те секунды, которые тратятся на отправку кода в облако, не замедляют разработку, это порой быстрее, чем даже контейнер пересобрать из кеша.

А вы точно программист?

Уже давно нет, а вы точно с облаками работаете?

Может быть в этом и проблема? А то нам Serverless пытаются продать люди, которые не пишут код, и да представьте себе, я работаю с лямбдами в aws.

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

Лимиты на размер функции, лимиты на время исполнения, холодный старт, ну и в целом основной минус в том что локальная разработка очень отличается от того что на проде, особенно в плане проверить работу 2 или 3 компонентов вместе.

Мы же не говорим о том, что serverless сейчас может полностью заменить всё. Все технологии имеют ограничения. В конце концов, решение как раскатывать код принимается исходя из SLA и бюджета. И тут у lambda (хотя s8s это не только лямбда, но об этом как-то все забывают) есть преимущество в перед другими технологиями в некотором диапазоне задач.
Лимиты на размер функции (для lambda, как вы знаете, это 10Гб в контейнере) и время исполнения (15 минут), 8 vCPU и соответственно RAM достаточны для огромного числа задач (но естественно не для всех), да и холодный старт не обязательно несет какие-то проблемы.
С другой стороны вы получаете очень быстрый скейлинг, хорошую интеграцию с другими сервисами (iam, sqs/sns/apigw, etc) и очень неплохой SLA. А дальше надо считать, что выгоднее. Не всегда такой SLA нужен, иногда у вас уже есть в бюджете кластер кубов с админами, и настроенный pipeline для кубов. А иногда у вас этого нет, зато есть требования к скорости и цене обработки запроса, например. И тут lambda даст вам то, что надо.
Так что s8s прекрасный инструмент, которым, как всегда, надо пользоваться тогда, когда он уместен.

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

1) Плата только за использование, то есть стоимость равна интегралу под графиком используемых ресурсов — в случае же кубов, приходится платить за весь прямоугольник, причем высота прямоугольника — это точка пиковой нагрузки


Теоретические выкладки это хорошо, но практика говорит что все плохо. Достаточно посчитать конечные деньги. И тут serverless тупо проигрывает в большинстве типичных приложений.
НЛО прилетело и опубликовало эту надпись здесь

А зачем переписывать? Код из FaaS будет бежать внутри контейнера без проблем (кроме проблем контейнера). Да, придется потратиться на то, чтоб чем-то заменить serverless-хранилища, базы и прочую обвязку типа очередей и мониторинга, но это именно то, что сэкономили вначале. Ну и да, если вы с serverless торчите миллион долларов амазону, значит вы что-то такое наделали на миллион долларов, а не просто нагородили кучу каких-то кластеров и забыли выключить.

Мысль «наделали на миллион долларов» многим не очевидна. Тут же дело в том что это кост на оказание какой-то услуги или предоставления какого-то сервиса. И эти косты очень просто складываются в P&L табличку, но обычно этим оперирует уже бизнес и потому эти вещи не матчатся у многих.

Закон дырявых абстракций никто не отменял.


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


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


Дурак напишет вам серверлесс функцию, которая удалит вашу серверлесс базу данных. И бекапа у вас не будет, ведь все серверлесс)


Есть крутая книга на эту тему, "Мифический человекомесяц", и глава оттуда "Серебряной пули нет". Вкратце, не видно технических средств (языков, компиляторов) и т.д., которые смогут глобально ускорить разработку.


Потому что проблема не в том, чтобы записать алгоритм, а в том, чтобы его придумать. Задача же языка программирования — не мешать. Как здесь поможет серверлесс — мне непонятно. Как будет мешать — вполне понятно. Например, отсутствие нормальной IDE, которая будет показывать связи между различными частями кода уже будет тормозить вас.

Вы пишете что-то очень странное.
У serverless баз есть бэкапы, FaaS код — это просто код, он отлично будет работать и в контейнере, вообще перепаковать код — дело минутное. Нормальная отладка есть, код вы можете смотреть когда угодно, он вообще у вас в гите лежит, а плоский набор функций для работы с БД можно упаковать в один компонент и на api gateway управлять эндпоинтами. FaaS ведь по сути тот же самый контейнер, просто масштабирование делает платформа, а не вы сами.

Завязался ты на серверлесс от Яндекса и тут РКН решил заблокировать Твиттер… но паровозом пострадал и Яндекс…

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


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

Выше все правильно написали. Серверлесс это действительно круто, но это слишком свежая технология, к которой нет ещё устоявшихся практик отладки, развёртывания, мониторинга и пр. Сложность проектов с серверлесс никуда не девается, просто она переходит на другой уровень. И стреляет в ногу early adopter’ам
Ну, и везде сказки про pay as you go. А ничего, что любая лямбда дороже такого же докера? Или что она тащит за собой пачку скрытых расходов? На те же api gateway, к примеру, и огромный штраф, если лямбда работает дольше хх мс? Понятно, что всем хочется хайпануть, но реалии такие, что к каждой задаче надо подбирать подходящий инструмент и лямбда (серверлесс) — только один из таких инструментов. А, получается, нужен набор как у хирурга или у мастера…

Сейчас Serverless строго vendor lock-in — бизнесу это не нужно. Сделайте единый стандарт и открытый софт, чтобы можно было поднять на своем железе — тогда возможно.
Скажем прямо: когда говорят о функционале, который локально никак не поднять (т.е. на своем буке я не могу поднять этот чудесный движок, чтобы «на своем поле» строить приложение), меня начинают терзать сомнения: очень уж кастомное решение получается.

Это меня так накрепко привязывает к весьма недешевому провайдеру, от которого не деться никуда, и который может выставлять счета на любые суммы (и который, будем честны, не всегда даже биллит вовремя/правильно), что — думаю, можно и пешком постоять без этого счастья.

Отдельно упомяну про мантру "Бизнес понимает, сколько по-настоящему это будет стоить. Он понимает, как это будет масштабироваться." Да о чем Вы, бизнес не понимает и не хочет понимать слово «масштабируется», ему нужна работа приложения, и нужно знать четкий ценник, что почем будет в счете за месяц. С облачными подходами это все затруднительно. Бизнес волнует, как часто оно будет падать, где гарантии, что скорости хватит, и пр. И еще бизнес должно волновать (но обычно по неопытности, до первого переезда, никто не думает), что делать, если провайдер решит сделать козу, и поменять правила игры. Блокировка со стороны AWS «соцсети для неполиткорректных» наглядно это показала: им бы за сутки свалить на условный яндекс, «но за углом с мрачной ухмылкой поджидал vendor-lock», правда?

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

Вот пример приложения — почтовый сервер
https://github.com/0x4447/0x4447_product_s3_email
Просто оцените количество компонентов
У меня почему-то не возникает желания это поддерживать или дорабатывать )

А ведь это простой (неуправляемый!) почтовый сервер. Меня в дрожь бросает от схемы и от понимания «легкости» отладки такого клубка функций:



Что интересно, даже если захочется к себе в офис его перенести (это для почты вполне законное желание) — неа, все привязано к aws!

Всего 4 лямбды вижу я? А если каждый policy разрисовать — то и стены не хватит :)

ну, правильно — каждая пара взаимодействий требует отдельного policy. И сама по себе лямбда нафиг никому не нужна )

Все нужные полиси легко не ненапряжно генерит сам CDK при деплое. Я уже не помню когда их руками писал. Если вы на AWS и не пользуетесь CDK — я прямо ОЧЕНЬ рекомендую потратить время и разобраться. Ваша жизнь после этого никогда не будет прежней!

Лучше terraform-а?

Я к сожалению не в курсе насколько полно terraform поддерживает всякие фишки AWS.

А CDK поддерживает все фишки? Мне казалось, что это как раз у CDK проблемы с поддержкой всех функций и сервисов амазона, у terraform с этим всё очень хорошо.

CDK разрабатывается и пожжерживается в основном командой AWS. Да, я встречал некоторые новые вещи не полностью поддерживаемые CDK, но там есть способы обычно обойти через поддержку CFN и их достаточно оперативно добавляют и фиксят.
Перепись серверлесс-ненавистников прямо :) Чтобы разбавить вашу компанию скажу, что мы в хвост и в гриву используем serverless на проектах наших клиентов и все у них прекрасно работает. В основном это orchestration и нетяжелая обработка, те реально миллисекунды и стоит копейки. Тяжелая обработка — в Docker на Fargate (те по сути тот же серверлесс, только в профиль).
Мы в Yandex Serverless Ecosystem время от времени проводим zoombar, было бы круто послушать ваш опыт. Совершенно не важно на базе какого провайдера вы работаете.
Разным задачам свое решение.
Для легких задач Lambda, для тяжелых контейнеры + k8s.
У нас NLP функции, которые занимают 4гб RAM и подгружают модели в 2гб. В lambda ну никак. На AWS тоже дорого держать. Посчитали и хостим сами.

С декабря лимит по RAM до 10GB подняли, кстати.

Сколько полезных новостей c одного комментария.
Благодарю за инфу, в выходные попробую containerized lambdas.
чё не продаётся вас серверлесс? Раз в неделю надо эту хрень запостить и комменты каждый раз одни и теже, но вы я смотрю настойчивые :D
Никогда не понимал тех кто травит за\против микросерсисы, Serverless.
Микросервисы очень помогаю когда есть ярко выраженные перекосы в требованиях к каким-то сервисам, когда удобнее дробить монстроузные системы на более мелкие, затачивая целые команды под них.
Serverless отлично подходит тем что можно легко прогнозировать нагрузку и несмотря на то, что цена выше позволяет вам не наращивать команду на поддержку. Отличный пример мобильные аппы, где не столь важна общая база, но при этом важно успевать за растущей аудиторией.
Но почему-то все примеряют свой личный опыт и делают на основе его какие-то выводы.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий