На ранних этапах внедрение бессерверных вычислений (Serverless) шло очень быстрыми темпами, но затем предприятия столкнулись с функциональными ограничениями и вендорлоком, что подорвало их популярность. Устранить эти ограничения поможет событийно-ориентированная архитектура (event-driven architecture, EDA). Генеральный директор и соучредитель TriggerMesh Марк Хинкль рассказывает на портале The New Stack, почему она приходит на смену бессерверным технологиям.

По данным исследования «State of Cloud Native Development», которое провела аналитическая компания SlashData при поддержке CNCF, популярность нативных облачных технологий в период с I кв. 2020 г. по I кв. 2021 г. пошла на спад. Рискну предположить, что если она проведет аналогичный опрос в I кв. 2022 г., то в лучшем случае доля использующих Serverless разработчиков сохранится на прежнем уровне, но все же более вероятно, что она снизится. Это наводит меня на мысль, что шумиха вокруг этой технологии спала, тем не менее, в том или ином виде будет существовать еще долгое время.

По словам технического директора CNCF Криса Анишчика, возможно эта тенденция отражает растущую обеспокоенность тем, что бессерверным технологиям не хватает гибкости, необходимой для широкого распространения, а также нежелание организаций придерживаться конкретных технологий или поставщиков.

Это заставило меня задуматься о другой тенденции в развитии облачной модели, которая начала формироваться несколько лет назад, — платформе как услуге (PaaS). Некоторое время AWS Elastic Beanstalk, Heroku и Cloud Foundry считались будущим развертывания приложений, но они также страдали от шаблонного подхода, которому не хватало гибкости для удовлетворения более широких потребностей предприятий.

Это очень похоже на то, что происходит сегодня: Serverless может быть частью гораздо более широкой EDA-тенденции.

Serverless — это не провал, это этап реализации

На ранних этапах внедрение Serverless шло очень быстрыми темпами, и в наибольшей степени оно затронуло пользователей Node.js, которые хотели быстро развернуть свои приложения в облаке, в первую очередь на AWS Lambda. Вскоре после этого Lambda и другие провайдеры функций как услуги (function-as-a-service) предложили большее количество режимов выполнения, и практически любой современный код или даже унаследованный код мог быть выполнен в бессерверных фреймворках.

Бессерверные технологии действительно обладают многими полезными функциями: их легко масштабировать; они запускаются в ответ на события, а не через механизм опроса; функции потребляют ресурсы только в соответствии с потребностями задания, а затем выходят из него и высвобождают ресурсы для других рабочих нагрузок; разработчики выигрывают от абстракции инфраструктуры и могут легко развертывать код через свои конвейеры CI/CD, не задумываясь о том, как предоставлять ресурсы.

Однако Анищик указывает на то, что Serverless не предназначены для многих ситуаций, включая «долгоиграющие» приложения. Они могут быть более дорогими для конечного пользователя, чем запуск выделенного приложения в контейнерах, на виртуальной машине или на «голом» железе. Serverless — это «самоуверенное» (opinionated) решение, которое заставляет разработчиков придерживаться поведенческой модели, установленной поставщиком. Кроме того, у него нет простого способа обработки состояния.

И наконец, хотя Serverless в основном развертываются в облаке, их нелегко развернуть у разных облачных провайдеров. Инструменты и механизмы для управления ими в значительной степени специфичны для конкретного облака, хотя, возможно, после передачи Knative в CNCF может появиться бессерверная платформа, которая подобно Kubernetes будет разрабатываться и внедряться при поддержке отрасли.

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

EDA в нативных облачных вычислениях

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

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

Другой проблемой помимо переносимости оказалась проблема запуска бессерверных функций при помощи входных данных не из системы вашего провайдера Severless. Оказалось, что такие инструменты, как Google EventArc и AWS EventBridge, недостаточно гибкие для создания более широких событийно-ориентированных приложений. Поэтому мы разработали альтернативу EventBridge с открытым исходным кодом, которая может не только отправлять потоки данных на любую бессерверную платформу, но и использоваться для упрощенного построения конвейеров данных для наполнения озер данных и выполнения других типов синхронизации данных.

Событийно-ориентированная синхронизация данных и рабочих процессов

Мы движемся к будущему, управляемому событиями и данными, где способность действовать в реальном времени на основе данных становится обязательным условием ведения цифрового бизнеса. В первую очередь требуются технологии потоковой передачи данных, похожие на AWS Kinesis, но не привязанные к одному поставщику. Ими могут быть Apache Kafka и Apache Pulsar, поскольку они являются открытыми и облако-независимыми, что позволяет привести данные в движение. Следующим шагом будет переход на коммуникацию между микросервисами «издатель-подписчик», а не REST-вызовы к API.

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

Согласно исследованию Coleman «The Great EDA Migration-2021», большинство (85%) организаций хорошо понимают большую бизнес-ценность внедрения EDA, однако ее внедрение все еще находится на начальном этапе (13%). Три наиболее распространенные области применения данных в реальном времени: интеграция приложений — под это подпадает бессерверный вариант использования; обмен данными между приложениями; подключение IoT-устройств для получения данных и/или аналитики.

Есть немало причин, которые вынуждают задуматься о создании EDA. Она может помочь повысить актуальность ваших данных и улучшить цифровое взаимодействие, а инструментарий для этого сейчас лучше, чем когда-либо. Во-первых, растет число бесплатных Open Source-инструментов, которые позволяют предприятиям создавать потоки данных, и Apache Kafka/Apache Pulsar возглавляют этот список. Кроме того, нативно облачные приложения могут обеспечить переносимость данных из локальной среды практически в любое облако, предлагающее Kubernetes.

Наконец, существуют дополнительные инструменты, такие как нативная облачная платформа интеграции с открытым исходным кодом TriggerMesh, обеспечивающая мультиоблачные возможности для создания и управления конвейерами данных, которые могут быть использованы для копирования возможностей, которые предлагает AWS EventBridge.

По мере того, как предприятия все больше нуждаются в информации в реальном времени и растет число систем, которым необходимо потреблять эти данные, будет расти и миграция на EDA. К счастью, появляется все больше открытых альтернатив, которые лишены привязки к проприетарным облачным сервисам или поставщикам ПО.