Бессерверные вычисления становятся всё более популярны среди организаций любого размера, начиная с облачных стартапов и заканчивая крупными предприятиями. Благодаря бессерверным вычислениям команды разработчиков могут сосредоточиться на продвижении своих идей на рынке, не задумываясь об управлении инфраструктурой, — и платить только за фактически использованный объём ресурсов. При подготовке этого отчёта мы изучили миллионы бессерверных функций, выполняемых в тысячах компаний. Задача наша заключалась в том, чтобы понять, как же используются бессерверные вычисления в реальном мире.
Бессерверные вычисления применяются в широком спектре сценариев — от решения краткосрочных задач до создания ориентированных на пользователей приложений. AWS Lambda — наиболее проработанная и широко используемая FaaS-платформа, основанная на модели «функция как услуга», но далеко не единственная. Распространение таких систем, как Azure Functions и Google Cloud Functions, также идёт впечатляющими темпами. Сегодня бессерверная экосистема вышла уже далеко за пределы модели FaaS и теперь включает десятки сервисов, помогающих разработчикам создавать более быстрые и динамичные приложения. Четверть клиентов Amazon CloudFront уже используют бессерверные периферийные вычисления, а также применяют функции AWS Step Functions для управления прикладной логикой самых разных распределённых компонентов.
В этом отчёте мы расскажем вам о важнейших инсайтах и трендах бессерверного ландшафта.
1. Функции AWS Lambda вызываются в 3,5 раза чаще, чем два года назад
AWS Lambda позволяет разработчикам быстрее создавать инновационные решения, не задумываясь об инфраструктуре. Современные ИТ-команды не только экспериментируют с бессерверными вычислениями, но и используют их в качестве жизненно важного компонента программных комплексов. В самом деле, по результатам нашего исследования, компании, которые работают с AWS Lambda начиная с 2019 года, существенно увеличили объём использования функций. Среднее число вызовов функций AWS Lambda в 2021 году в 3,5 раза выше, чем два года назад. Более того, среди той же когорты пользователей AWS Lambda функции выполнялись в среднем 900 часов в день для каждой организации.
Отчёт Datadog «Бессерверные вычисления — состояние индустрии» рассказывает о разработчиках, которые всё активнее применяют бессерверные архитектуры при решении новых, более сложных бизнес-задач. Нас очень радует, что многие организации находят пользу в гибкости, эластичности и экономической эффективности бессерверных технологий, например AWS Lambda, и готовы помочь всему разнообразию быстро развивающегося сообщества разработчиков.
— Аджай Наир (Ajay Nair), генеральный менеджер направления Lambda Experience, Amazon Web Services
2. Функции Microsoft Azure и Google Cloud набирают обороты
AWS Lambda, безусловно, дала импульс развитию бессерверной экосистемы, но это далеко не единственный игрок на рынке. Функции Azure и Google Cloud всё более активно применяются на своих «родных» платформах. За последний год среди пользователей платформы Azure доля компаний, работающих с Azure Functions, выросла с 20 до 36%. На платформе Google Cloud практически четверть организаций теперь использует Cloud Functions. Несмотря на то что Cloud Functions — самое молодое FaaS-решение «большой тройки», бессерверные вычисления — далеко не новое понятие для Google Cloud. Эта облачная платформа запустила свой первый полномасштабный бессерверный сервис Google App Engine ещё в 2008 году. Однако мы видим, что сегодня акцент смещается в пользу более молодых бессерверных предложений Google, в частности Cloud Functions и Cloud Run.
Вне зависимости от того, какой фреймворк, язык или облако вы используете, бессерверные вычисления могут помочь вам с лёгкостью создавать решения и проводить итерации в ходе разработки. Два года назад в Next.js появилась первоклассная поддержка бессерверных функций, что позволяет реализовать отрисовку на стороне сервера (Server-Side Rendering, SSR) и API-маршруты. С того момента среди пользователей платформы Vercel наблюдается взрывной рост использования бессерверных функций: суммарный объём вызовов увеличился с 262 млн в месяц до 7,4 млрд в месяц — в 28 раз!
— Гильермо Раух (Guillermo Rauch), генеральный директор и один из создателей Next.js
3. Вызовы функций AWS Lambda длятся сегодня гораздо меньше, чем год назад
Lambda-функции всё чаще используются для работы клиентоориентированных приложений, требующих низкой величины задержки. В 2020 году продолжительность среднего вызова Lambda-функции составила всего 60 мс — примерно в два раза меньше, чем в прошлом году. Объясняется это тем, например, что сегодня всё больше организаций пользуется практическими рекомендациями от AWS Lambda и создаёт функции, прицельно оптимизированные под рабочие нагрузки. Это позволяет снизить длительность вызовов. Мы также обнаружили, что для распределения вызовов Lambda-функций по задержкам характерен длинный «хвост». На основании этого можно сделать вывод, что AWS Lambda не только обеспечивает работу краткосрочных заданий, но и обслуживает сценарии, требующие более интенсивных вычислений.
4. Сервис AWS Step Function позволяет оркестрировать всё что угодно — от веб-приложений до конвейеров обработки данных
Платформа AWS Step Functions помогает разработчикам создавать событийные технологические процессы, использующие различные Lambda-функции и сервисы AWS. В рамках этих процессов Step Functions координирует процессы обработки ошибок, повторные попытки вызова, тайм-ауты и прочие элементы прикладной логики, что помогает снизить уровень операционной сложности при масштабировании бессерверных приложений. Наше исследование показало, что средний workflow-процесс Step Functions содержит четыре функции AWS Lambda — и эта цифра с каждым месяцем увеличивается.
Step Functions поддерживает два вида workflow-процессов: Standard Workflows и Express Workflows. Мы заметили, что более 40% workflow-процессов выполняется менее чем за минуту. Это говорит о том, что организации, вероятнее всего, используют Express Workflows для обработки событий с интенсивной рабочей нагрузкой. Многие workflow-процессы выполняются быстро, однако есть и такие, которые занимают целый день. Самые «выносливые» workflow-процессы Step Function растягиваются на неделю и даже дольше. Workflow-процессы Step Functions могут включать в себя рабочие процессы activity workers, способные запускаться на виртуальных машинах Amazon ECS или EC2, а значит, выполняться дольше стандартного для Lambda-функций тайм-аута в 15 мин. Благодаря этому платформа Step Functions поддерживает широкий набор сценариев, начиная с задач, чувствительных к задержке, например связанных с выполнением запросов, и заканчивая сложными, долгоиграющими процессами, такими как обработка больших данных.
В нашей полномасштабной бессерверной архитектуре сервис AWS Step Functions используется широко. Благодаря этому мы создаём надёжные рабочие процессы, которые обрабатывают большие объёмы транзакций на нашей торговой B2B-платформе и позволяют нам снизить уровень операционной сложности.
— Зак Кантер (Zack Kanter), генеральный директор компании Stedi
5. Каждый четвёртый пользователь CloudFront уже применяет периферийные бессерверные вычисления
На волне обещаний сделать обработку данных более быстрой периферийные вычисления успели вызвать к себе немалый интерес. Сегодня уже четверть клиентов Amazon CloudFront используют Lambda@Edge, чтобы предоставлять более персонализованные сервисы для своих пользователей по всему миру. Например, Lambda@Edge может динамически преобразовывать изображения, исходя из характеристик пользователей (например, типа используемых ими устройств), либо обслуживать разные версии веб-приложений в рамках A/B-тестирования.
Используя сеть центров периферийной обработки данных CloudFront, Lambda@Edge позволяет организациям выполнять функции в непосредственной близости к конечным пользователям, не задумываясь о сложностях настройки и управления серверами-источниками. Согласно нашим данным, 67% функций Lambda@Edge выполняются менее чем за 20 мс. Это говорит о том, что у периферийных бессерверных вычислений огромный потенциал — они способны поддержать даже самые требовательные к задержке приложения при минимальных накладных расходах. Мы ожидаем, что с развитием этой технологии ещё больше организаций сделают ставку именно на неё, чтобы повысить уровень обслуживания своих клиентов.
Разработчики всё чаще переносят компоненты своих приложений на периферию. Возможность динамически подгружать и изменять данные из периферийной CDN-сети означает, что вы сможете быстрее обслуживать своих пользователей. Платформа Lambda@Edge сделала это возможным в 2017 году, а сегодня функции CloudFront упростили и удешевили весь процесс, позволяя разработчикам выполнять полноценные JavaScript-приложения в непосредственной близости к своим клиентам.
— Фаррах Кэмпбелл (Farrah Campbell), старший продакт-менеджер по маркетингу современных приложений, Amazon Web Services
6. Организации слишком много тратят на поддержку Provisioned Concurrency для большинства своих функций
Когда Lambda-функция вызывается после периода бездействия, она запускается с задержкой. Такое явление получило название холодного старта. Для приложений, требующих времени отклика на уровне нескольких миллисекунд, холодный старт может обернуться полным провалом. В конце 2019 года на платформе AWS появился механизм Provisioned Concurrency. Задача его заключалась в том, чтобы помочь пользователям AWS Lambda решить проблему холодного старта, поддерживая среды выполнения в инициализированном состоянии, готовыми в любой момент ответить на запросы пользователей.
Как следует из наших данных, многие пользователи по-прежнему считают выбор оптимального уровня Provisioned Concurrency для Lambda-функций непростой задачей. Более половины функций не используют даже 80% из выделенных на них ресурсов Provisioned Concurrency. При этом более 40% функций исчерпывают все отведённые им ресурсы Provisioned Concurrency, а следовательно, холодный старт для них всё равно возможен и выделение дополнительных ресурсов пошло бы им на пользу. Автоматическое масштабирование приложений предлагает ещё один путь решения этих проблем, позволяя пользователям автоматически масштабировать уровень Provisioned Concurrency в зависимости от фактической интенсивности использования функций.
7. The Serverless Framework — самый популярный способ развёртывания Lambda-приложений на платформе AWS CloudFormation
С ростом масштаба бессерверных приложений ручное развёртывание Lambda-функций и других ресурсов может оказаться непомерно ресурсозатратной задачей. Платформа AWS CloudFormation позволяет разработчикам настраивать инфраструктуру AWS и сторонние ресурсы при помощи коллекций (так называемых стеков). Именно такой базовый механизм развёртывания используют фреймворки AWS Cloud Development Kit (CDK), AWS Serverless Application Model (SAM) и Serverless Framework.
Среди этих инструментов опенсорсный Serverless Framework на текущий момент наиболее популярен — его используют более 90% организаций, управляющих бессерверными ресурсами на платформе AWS CloudFormation. Помимо этого, 19% организаций пользуются собственным инструментарием CloudFormation, 18% — AWS CDK и 13% — AWS SAM. Следует отметить, что, поскольку каждая организация может применять несколько инструментов развёртывания, сумма этих чисел превышает 100%.
Среди всех стеков на платформе AWS CloudFormation, используемых в serverless-приложениях, 65% содержат всего одну Lambda-функцию. Но это ещё не всё: более половины функций — 57% — не развёртываются с использованием средств CloudFormation. Это говорит о том, что многие организации находятся пока ещё на ранних стадиях автоматизации и оптимизации бессерверных workflow-процессов на базе модели «инфраструктура как код». Однако точно так же, как и в случае с платформами-оркестровщиками, например Kubernetes и Amazon Elastic Container Service (ECS), которые стали незаменимыми средствами управления большими парками контейнеров, мы ожидаем, что инструменты модели «инфраструктура как код» будут играть всё более серьезную роль при масштабном развёртывании бессерверных приложений.
По мере того как разработчики и предприятия начинают создавать всё более продвинутые приложения на базе бессерверных технологий, им требуются всё более мощные средства для надёжного создания, тестирования, развёртывания своих сервисов и управления ими. Это служит катализатором появления опенсорсных проектов «инфраструктура как код», таких как Serverless Framework и AWS CDK. Только для Serverless Framework количество загрузок выросло с 12 млн в 2019 году до 25 млн в 2020 году. Мы ожидаем, что по мере создания разработчиками всё новых приложений на бессерверной инфраструктуре эти инструменты будут усиленно развиваться, а число их внедрений будет расти.
— Джереми Дали (Jeremy Daly), генеральный менеджер по направлению Serverless Cloud, Serverless Inc.
8. Python — самая популярная среда исполнения Lambda-функций, особенно для крупных внедрений
С 2018 года AWS Lambda поддерживает шесть программных сред исполнения: Node.js, Python, Java, Go, .NET Core и Ruby. При этом Python и Node.js сохраняют наибольшую популярность среди пользователей AWS Lambda — 90% функций приходится именно на них. 58% всех развёрнутых Lambda-функций используют Python (прирост 11 процентных пунктов по сравнению с тем, что было год назад), и ещё 31% используют Node.js (спад на 8 процентных пунктов по сравнению с прошлым годом).
Когда мы изучали, как среда исполнения зависит от масштабов внедрения, мы обнаружили интересный тренд: притом что Node.js вытесняет Python в небольших AWS-средах, Python становится всё более популярным с ростом масштабов операционных сред. Среди организаций, наиболее активно использующих AWS, Python применяется в четыре раза чаще, чем Node.js.
По состоянию на март 2021 года наиболее популярными версиями сред исполнения были:
Python 3.x
Node.js 12
Node.js 10
Python 2.7
Java 8
Go 1.x
.NET Core 2.1
.NET Core 3.1
Среди функций, написанных на Python, более 90% используют Python 3, при этом Python 3.8 — наиболее популярная его версия. Python 2.7 опустился на 25 процентных пунктов по сравнению с прошлым годом, поскольку пользователи всё чаще переходят на Python 3. AWS объявила о планируемом прекращении поддержки Node.js 10 в мае 2021 года, поэтому мы ожидаем прирост доли использования Node.js 12 и новой версии Node.js 14. Java 8 в пять раз более популярна среди пользователей Lambda, чем Java 11, хотя поддержка последней доступна с 2019 года.
Комментарии по Методологии
Выборка компаний
Для этого отчёта мы собрали данные об использовании информационных решений, полученные от нескольких тысяч компаний — клиентов Datadog. Несмотря на то что клиенты Datadog — это огромное разнообразие компаний, как по размерам, так и с точки зрения индустрий, в которых они работают, у этих компаний есть ряд схожих черт. Во-первых, эти компании серьёзно относятся к программной архитектуре и производительности своих приложений. Также они в большей мере склонны, по сравнению с генеральной совокупностью всех мировых компаний, к использованию облачных платформ и сервисов. Все результаты этой статьи оказываются статистически смещены из-за того, что они основаны на данных о нашей клиентской базе — а это крупная, но неидеальная выборка всего мирового рынка.
Использование модели FaaS (функция как услуга)
В рамках данного отчёта мы считаем, что компания использует AWS Lambda, Azure Functions или Google Cloud Functions, если она выполняла не менее чем пять разных функций в течение конкретного месяца. Функция Datadog Forwarder, которая передаёт данные логов S3 Logs и CloudWatch Logs в Datadog, не учитывалась при расчёте числа функций.
Использование услуг облачного провайдера
Мы считаем, что компания пользуется услугами облачного провайдера (то есть AWS, Google Cloud или Microsoft Azure), если она выполняла не менее пяти разных serverless-функций или пяти разных виртуальных машин в течение конкретного месяца. Таким образом, мы можем представить себе базу пользователей облачного провайдера как сочетание трёх типов компаний — тех, кто использует только виртуальные машины, тех, кто использует только serverless-функции, и, наконец, тех, кто использует и то и другое.
Масштаб операционных сред
Чтобы оценить относительный масштаб инфраструктурной среды компании, мы изучили уровень использования компанией serverless-функций, контейнеров, физических серверов, облачных виртуалок, а также прочих инфраструктурных сервисов. Хотя граница в данном случае неизбежно искусственная (какую архитектуру называть «средней», а какую «крупной» — вопрос условный), общий тренд по категориям представляется ясным.
К факту № 1
При анализе трендов долгосрочного использования AWS Lambda мы ограничили наше исследование организациями, которые применяют AWS Lambda начиная с 2019 года. Для этой когорты организаций мы провели случайную выборку данных об использовании ресурсов и рассчитали среднее число вызовов функции в день для каждого квартала, начиная с 2019 года и заканчивая началом 2021 года. Затем мы построили график индексов, указав первый квартал 2019 года как базовый и присвоив ему индекс 100, а затем нормализовали значения для каждого следующего квартала к этому базовому индексу.
К факту № 6
Для анализа недостаточного либо избыточного выделения ресурсов Provisioned Concurrency по каждой функции мы рассчитали средний уровень использования для случайно выбранных дней в 2020 году, а затем построили для них график распределения. Таким образом мы построили репрезентативную картину использования функций при различных уровнях нагрузки.
К факту № 7
Наше исследование основывалось исключительно на данных об использовании CloudFormation, то есть оно не включало Lambda-функции, развёрнутые вручную через консоль AWS или с использованием иных инструментов «инфраструктура как код» (например, Terraform).
П.С. От переводчика.
Если вам интересна экосистема Serverless-сервисов и все, что с этим связано, заходите в наше сообщество в Telegram, где можно обсудить serverless в целом.
