Комментарии 85
Почему весь рынок все еще не перешел на Serverless
Так озаглавить раздел статьи и при этом заполнить его дифирамбами serverless-у это определенно талант.
Но будем честными, скорее всего реальной работы ваш сервер делает не так много, и нагрузка имеет свое определенный паттерн. Есть паттерны при которых вызовы функций будут многократно эффективнее, есть в которых будут значительно проигрывать. Просто инструмент, которым нужно пользоваться осмысленно.
Серверлесс аналог пустого 2xIntel Xeon Gold 6254 + 256Gb ram + intel optane будет стоить 0.00$.
Отвечу на вопрос за автора статьи.
Потому что нет единого стандарта.
Во времена cgi скриптов у нас была только файловая система и она была стандартной.
Во времена lamp у нас была база данных и файловая система и они были стандартными. (Любой хостинг предоставлял стандартную среду, которую любой разработчик за 10 минут мог воспроизвести у себя на локальной машине. Могли отличаться версии и подключенные модули, но в целом стандартное.)
Во времена кубера у нас предоставляется стандартная среда по которой в любом облаке из стандартных докер-кирпичиков поднимается ваше приложение со всем окружением. Ты уже даже не зависишь от того что там наконфигурили в апаче.
Во времена серверлеса ты получаешь вендорлок на яндекс или амазон или другую платформу. Каждый предлагает свой способ передачи и возврата из кода значений, каждый пытается завязать тебя всеми силами на свои сервисы. Можно развернуть дев версию запускалки на компе разработчика, но как минимум для амазона её поведение немного отличалась от продакшен окружения и я успел с этим столкнуться за разработку крошечного приложения. Средства отладки при такой системе недоступны. Отладка принтами встаёт из мёртвых.
Ну и цена. Конский ценник. Простенький сервис на го с двумя инстансами ec2-micro и балансировщиком обойдётся в пару десятков баксов а сможет тянуть тыщу запросов в секунду. Безсерверные функции в таком случае станут выгодны только если вы реально будильниками в Москве управляете и у вас пик нагрузки укладывается в пару часов а потом мёртвое время.
Яндекс в мире никому он нужен.
Амазон + лямбда + популярнее всего либо питон либо нода, вот вам и стандарт.
Только серверлесс нишевая технология и всё равно не заменит всего.
И всё, приплыли.
Кроме социалочки может быть приложения для конвертации чего-либо (придут жалобы от копирастов и бежать будет некуда), либо какие-то другие варианты.
Тот самый жуткий случай, когда бан у провайдера вычислительных ресурсов будет означать 100% смерть проекта.
Там набегут патентные тролли, копирасты, защитники негров; у нас ограничат право на распространение знаний («госдума приняла в третьем чтении законопроект, обязывающий согласовывать просветительскую деятельность с органами власти»).
Даже если сделать школьный чатик, придет ФСБ, как только узнает о существовании оного; если сделать каталог с картинками, посадят за мемасики с попами.
Боязнь облаков свойственна больше Российским проектам, т.к. видимо, здесь политические риски несколько выше.
Но serverless на мой взгляд, это всё же про облака, поэтому если у вашего проекта есть политические риски, то вероятно лучше использовать другую технологию, благо на serverless свет клином не сошёлся.
Но как по мне, serverless — название неудачное. Какой нафиг серверлесс, если все вычисления выполняются на серверах?
Когда пропустил появление Docker, ругал себя, и тут же следом проморгал Kubernetes.
Сейчас нужно изучать Serverless
Звучит, как будто вы боитесь, что в погоне за новинками можете зря потратить время на спорную технологию.
Мы не используем Serverless, потому что непонятно, в каких кейсах использовать эту технологию и чем она выгоднее традиционного подхода.
1) Скрипты, которые нужно запускать где-то в облаке раз-два в день максимум. Но такое мне проще закинуть на личную VPS (собственно, она у меня и превратилась в такую помойку). Всякие боты для друзей и прочее
2) Проекты с рваной нагрузкой. Но, учитывая цену той-же Lamda нужно еще посчитать, что выгоднее, держать мощный инстанс 24/7, или платить за выполнение. У меня в большинстве случаев держать инстанс было дешевле (даже без учета времени разработчиков, лол)
Но если у вас есть реальная нагрузка и вы понимаете ее паттерн, то конечно легко можно посчитать что вам выгоднее.
Например она выгодна для малонагруженных сервисов или всякой мелочевки для обслуживания других сервисов. Еще она выгодна для тестовых окружений. Наконец, выгодна для сервисов, на которые не хватило админов.
я не ощутил преимуществ этих технологий против нормально работающего k8s стека
Хм, интересно, ибо имеется диаметрально противоположный опыт — медленные, неповоротливые и глючные кубы, которые стоят как чугунный мост — с одной стороны, и быстрая, масштабируемая, надежная и очень дешевая связка из нескольких serverless — сервисов (каких именно писать не буду, чтобы не восприняли за рекламу вендора)
Пальцем в небо предположу что у вас очень несложное приложение.
Кубик и так-то выглядит оверкилом, если у вас нет хотя бы полутысячи подов.
А для той области где заходит serverless он вообще безумно громоздок.
Зато когда кубик уже есть (а пол тысячи подов это по сути набор окружений для небольшого микросервисного решения в пару десятков компонентов, что вполне себе покрывает потребности проекта даже на десяток человек), то запускать далее небольшие и редкие нагрузки в серверлесс — это хайп и каргокульт. Настроенный и отлаженный k8s в данном случае для нас вообще бесплатен, несколько кронджоб запускаемых раз в сутки не потребуют даже какого либо скейлинга нод
а пол тысячи подов это по сути набор окружений для небольшого микросервисного решения в пару десятков компонентов
Вы сильно лукавите (если не сказать врете) относительно оценки размеров «небольшого».
В большинстве случаев люди обходятся десятками подов. И вот зачем им в этом контексте кубик — я вообще не понимаю.
И вот зачем им в этом контексте кубик — я вообще не понимаю.
отсутствие vendor lock и наличие стандартных технологий в подах…
Но есть нюансы...
Сложно согласиться с Вами, поскольку опыт диаметрально противоположный, и возникает встречный вопрос — кто эти люди, кто готов платить за кублеты, которые по сравнению с 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 торчите миллион долларов амазону, значит вы что-то такое наделали на миллион долларов, а не просто нагородили кучу каких-то кластеров и забыли выключить.
Закон дырявых абстракций никто не отменял.
Вдруг окажется, что нам нужно авторизоваться в системе, и значит хранить-выдавать токены. Потом нам нужно хранить кучу информации о каждом юзер в БД. Потом строить связи между данными в БД. И мы оказываемся в ситуации, когда мы имеем базу данных и плоский набор функций для работы с этой БД. При этом нормальной локальной отладки не имеем, код локально без интернета глянуть не можем, перейти к другому провайдеру не можем — ведь мы завязаны на конкретного провайдера.
Аргумент, что можем пускать к разработке неопытных программистов звучит странно. К некритичным частям при разработке софта мы и так их пускаем, к критичным тоже пускаем, но делаем более строгий код-ревью. Что так, что так нужно проверять их код, а не надеяться, что серверлесс платформа вас защитит от дурака.
Дурак напишет вам серверлесс функцию, которая удалит вашу серверлесс базу данных. И бекапа у вас не будет, ведь все серверлесс)
Есть крутая книга на эту тему, "Мифический человекомесяц", и глава оттуда "Серебряной пули нет". Вкратце, не видно технических средств (языков, компиляторов) и т.д., которые смогут глобально ускорить разработку.
Потому что проблема не в том, чтобы записать алгоритм, а в том, чтобы его придумать. Задача же языка программирования — не мешать. Как здесь поможет серверлесс — мне непонятно. Как будет мешать — вполне понятно. Например, отсутствие нормальной IDE, которая будет показывать связи между различными частями кода уже будет тормозить вас.
Вы пишете что-то очень странное.
У serverless баз есть бэкапы, FaaS код — это просто код, он отлично будет работать и в контейнере, вообще перепаковать код — дело минутное. Нормальная отладка есть, код вы можете смотреть когда угодно, он вообще у вас в гите лежит, а плоский набор функций для работы с БД можно упаковать в один компонент и на api gateway управлять эндпоинтами. FaaS ведь по сути тот же самый контейнер, просто масштабирование делает платформа, а не вы сами.
Больше похоже на маркетинговый буллшит, а не на техническую статью.
Амазоновские и гугловские сервисы и так уже давно успешно используются совместно со старыми "serverful" подходами, и без всяких намеков на революцию.
Выше все правильно написали. Серверлесс это действительно круто, но это слишком свежая технология, к которой нет ещё устоявшихся практик отладки, развёртывания, мониторинга и пр. Сложность проектов с серверлесс никуда не девается, просто она переходит на другой уровень. И стреляет в ногу early adopter’ам
Ну, и везде сказки про pay as you go. А ничего, что любая лямбда дороже такого же докера? Или что она тащит за собой пачку скрытых расходов? На те же api gateway, к примеру, и огромный штраф, если лямбда работает дольше хх мс? Понятно, что всем хочется хайпануть, но реалии такие, что к каждой задаче надо подбирать подходящий инструмент и лямбда (серверлесс) — только один из таких инструментов. А, получается, нужен набор как у хирурга или у мастера…
Это меня так накрепко привязывает к весьма недешевому провайдеру, от которого не деться никуда, и который может выставлять счета на любые суммы (и который, будем честны, не всегда даже биллит вовремя/правильно), что — думаю, можно и пешком постоять без этого счастья.
Отдельно упомяну про мантру "Бизнес понимает, сколько по-настоящему это будет стоить. Он понимает, как это будет масштабироваться." Да о чем Вы, бизнес не понимает и не хочет понимать слово «масштабируется», ему нужна работа приложения, и нужно знать четкий ценник, что почем будет в счете за месяц. С облачными подходами это все затруднительно. Бизнес волнует, как часто оно будет падать, где гарантии, что скорости хватит, и пр. И еще бизнес должно волновать (но обычно по неопытности, до первого переезда, никто не думает), что делать, если провайдер решит сделать козу, и поменять правила игры. Блокировка со стороны AWS «соцсети для неполиткорректных» наглядно это показала: им бы за сутки свалить на условный яндекс, «но за углом с мрачной ухмылкой поджидал vendor-lock», правда?
Пределом будет напилить на serverless более-менее полноценное приложение, которое будет работать путем дергания из одной своей части функций для другой своей части. Будет круто концептуально, адски геморно по отладке и проектированию, и — как думается, недешево при первом же росте нагрузки.
Вот пример приложения — почтовый сервер
https://github.com/0x4447/0x4447_product_s3_email
Просто оцените количество компонентов
У меня почему-то не возникает желания это поддерживать или дорабатывать )
А ведь это простой (неуправляемый!) почтовый сервер. Меня в дрожь бросает от схемы и от понимания «легкости» отладки такого клубка функций:
Что интересно, даже если захочется к себе в офис его перенести (это для почты вполне законное желание) — неа, все привязано к aws!
ну, правильно — каждая пара взаимодействий требует отдельного policy. И сама по себе лямбда нафиг никому не нужна )
Лучше terraform-а?
А CDK поддерживает все фишки? Мне казалось, что это как раз у CDK проблемы с поддержкой всех функций и сервисов амазона, у terraform с этим всё очень хорошо.
Для легких задач Lambda, для тяжелых контейнеры + k8s.
У нас NLP функции, которые занимают 4гб RAM и подгружают модели в 2гб. В lambda ну никак. На AWS тоже дорого держать. Посчитали и хостим сами.
С декабря лимит по RAM до 10GB подняли, кстати.
Микросервисы очень помогаю когда есть ярко выраженные перекосы в требованиях к каким-то сервисам, когда удобнее дробить монстроузные системы на более мелкие, затачивая целые команды под них.
Serverless отлично подходит тем что можно легко прогнозировать нагрузку и несмотря на то, что цена выше позволяет вам не наращивать команду на поддержку. Отличный пример мобильные аппы, где не столь важна общая база, но при этом важно успевать за растущей аудиторией.
Но почему-то все примеряют свой личный опыт и делают на основе его какие-то выводы.
Три года назад нужно было изучать Docker, два года назад — Kubernetes. Сейчас — Serverless