Почему разработчики не дружат с Serverless

Original author: Anna Anisienia
  • Translation

Недавно я посмотрела видео одного хорошего разработчика и ютубера, которое называется «Бессерверная бессмысленность». Мне понравились мысли автора, но я не согласна с некоторыми его высказываниями и хочу обсудить их в этой статье.

Ролик начинается с шутки: «В мире есть две вещи, которые я не понимаю, — девушки и бессерверные вычисления». Я ничего не знаю об отношениях этого разработчика с девушками, но прав ли он в отношении Serverless? Давайте рассмотрим его основные критические тезисы и обсудим возможные аргументы, защищающие бессерверные вычисления.

Спойлер: я верю в пользу Serverless. Просто нужно знать, когда и как использовать эту технологию.


Критика Serverless


Основным аргументом против бессерверных вычислений является их скорость. Или хорошо известная проблема холодного старта. Холодный старт — это задержка выполнения кода (может достигать до 1 секунды для таких языков, как JavaScript, Python, Go, Java, Ruby), которая происходит из-за необходимости выделения вычислительных ресурсов, извлечения кода и запуска контейнера со стороны провайдера.

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

Как человек, который работал в IT и сталкивался с разработкой актуальных технологий, я не уверена, что именно метрика скорости является ключевой. Ведь есть еще такие критерии, как скорость циклов разработки, простота обслуживания, время окупаемости продукта, низкие затраты для конечного пользователя, снижение риска сбоев в работе за счет обеспечения бесперебойных IT-операций. Наконец, экономия времени разработчиков. Если задуматься, то бессерверные вычисления удовлетворяют всем этим критериям.

Что упускают разработчики? Настоящие преимущества Serverless


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

Бессерверные вычисления — это действенный способ управления IT-инфраструктурой, особенно для компаний, у которых может не быть ресурсов для покупки собственной инфраструктуры и найма специалистов, которые бы обслуживали серверы 24/7.

В нашем блоге мы уже как-то писали о Serverless в подробном тексте. Также предлагаем вам опробовать бессерверные вычисления с помощью сервиса «Облачные функции». На странице продукта в Панели управления уже есть несколько примеров использования Serverless, а также шаблоны кода.

Низкая стоимость бессерверных вычислений может перекрыть все недостатки


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

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

Холодный старт можно нивелировать


Возвращаясь к вопросу о времени выполнения кода, проблема холодного запуска во многом от зависит от того, как вы пишете код и настраиваете Serverless.

В целом, существует немало способов смягчить холодный запуск, «подогрев» его. Так, можно запускать функции с некоторой периодичностью, чаще запускать сервис или держать часть контейнеров запущенными все время (если это позволяет провайдер). Эти действия обеспечат необходимую «теплую среду» для запуска функций.

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

Какая задержка приемлема для ваших рабочих нагрузок?


Хорошо, если вы знаете ответ на этот вопрос. Говоря о задержке, вызванной холодным запуском, речь обычно идет о миллисекундах. Во всех случаях использования, с которыми я сталкивалась в работе в качестве дата-инженера, задержки в повседневной работе не заметны.

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

Бессерверные вычисления — это про «NoOps» и масштабируемость


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

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

В каких случаях использовать бессерверные вычисления особенно полезны


Представьте, что вы основали стартап. Сначала вам может не понадобиться значительная инфраструктура, и у вас может быть только один разработчик. Парадигма Serverless позволяет вам начать с малого и автоматически масштабировать ресурсы по мере роста вашего бизнеса с помощью модели затрат Pay-as-you-go (плата за реальное пользование).

Еще одна группа, которая может получить большую выгоду от бессерверных вычислений, — это малые предприятия, у которых нет крупного ИТ-отдела. Возможность управлять всем жизненным циклом приложения с помощью всего лишь одного DevOps-инженера (а не команды программистов) — это огромное преимущество бессерверных вычислений.

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

Также не все события в жизни можно предугадать. Представьте, что вы продаете дезинфицирующие средства для рук, иные антисептики, маски для лица и подобные товары в своем интернет-магазине. Затем случилась глобальная пандемия, и теперь ваши продукты нужны всем. С бессерверной инфраструктурой вы будете готовы к любой нагрузке.

Скорость выполнения кода против скорости циклов разработки


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

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

Недостатки Serverless, которые не были упомянуты в видео


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

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

  1. Существует риск вендор-лока. Провайдеры делают свои услуги настолько удобными и экономичными, что вы рискуете привязаться к конкретному поставщику облачных услуг.
  2. При сравнении бессерверных вычислений и физических ресурсов, размещенных на собственном хостинге, в первом случае у вас меньше контроля. Например, вы не можете подключиться по SSH к инфраструктуре, ​​чтобы выполнить некоторую настройку вручную, также есть ограничения по типу инстансов.
  3. Если ваши политики безопасности и требования хранения информации не позволяют обрабатывать данные на общем клиенте в облаке, бессерверные вычисления могут вам не подойти.
  4. Дробление вашей ИТ-инфраструктуры на автономные микросервисы позволяет сократить циклы выпуска, но это создает проблему контроля и управления всеми микросервисами.

Вывод


В целом, использовать новые парадигмы в IT, такие как бессерверные вычисления или другие облачные сервисы, в той же логике, что и привычные нам «домашние» on-premises технологии, едва ли самая хорошая идея. Когда вы занимаетесь прямым «копипастгом» рабочих процессов с физической инфраструктуры в облако, вы теряете многие преимущества облачных сервисов, если вообще не лишаете их смысла.

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

С моей точки зрения, мы не должны говорить о Serverless (как, впрочем, и о других IT-решениях) категорично, рассматривая только один аспект работы и игнорируя остальные. Бессерверные вычисления имеют смысл. Если вы знаете, когда и как их использовать.

Only registered users can participate in poll. Log in, please.

Пробовали Serverless?

  • 5.1%Первый раз о нем прочитал(-а)5
  • 19.4%Для моих задач не подходит19
  • 19.4%Пробовал(-а), не зашло19
  • 18.4%Использую, нравится18
  • 37.8%Пока не очень понятно, как это использовать37
Selectel
IT-инфраструктура для бизнеса

Comments 29

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

    Самая большая проблема Serverless в том, что не существует сложившихся практик по управлению ответственностью за части и функции систем в serverless-парадигме. Ответственность за функции становится размазана по всей кодовой базе, и все отвечают за все
      0
      Да тут разные варианты возможны. Для небольшой команды наверное лучше что то вроде serverless который сам создаст функцию и нужные ресурсы для нее, и все это в одном репо.
      Для больших проектов — terraform для самой функции, ее настроек, IAM ролей и тп а деплой кода через deployment pipeline (jenkins например).
        0
        Уже пару лет пишу функции в 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. И возни меньше — в смысле каждодневной поддержки.
          0
          Если я правильно понял, то вы «сервис» разбиваете на несколько функций? Если так то очень интересны 2 момента, если конечно не секрет:
          1. Как вы решаете вопрос с общей логикой (бизнес- и инфрастуктурной) при разделении приложения на несколько функций? Это какой-то общий модуль который есть в каждой функции и все функции деплоятся одновременно по каждому коммиту или как-то иначе?
          2. По каким критериям вы решаете что нужно разбивать сервис/приложение на несколько функций вместо одной?
            0
            Сначала про деплоймент. 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
              +1
              На мой взгляд, cloud function не панацея, и пихать везде не нужно. Желательно оценивать — где cloud function хорошо будут работать, а где нет. При этом учитывать ограничения. Например — максимальное время выполнения, или максимальный доступный объем памяти. Есть и другие ограничения…

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

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

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

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

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

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

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

              +2

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

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

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

                    0

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


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


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


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


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


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

                      +3

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

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

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

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

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

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

                                Оно интерактивное?

                          +2
                          снижение риска сбоев в работе

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

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

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


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

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

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

                                  Действительно, никакого противоречия.

                                  Only users with full accounts can post comments. Log in, please.