Всем привет! Меня зовут Александр Бардаш, я главный архитектор интеграционных платформ в МТС. Сейчас наша команда работает над интеграционной платформой в рамках The Platform, которая объединит все существующие типы интеграций экосистемы и позволит ими управлять.
Давайте договоримся, что интеграция — это любой тип взаимодействия систем друг с другом — REST, SOAP GraphQL и так далее. Интеграционная платформа — продукт не только для нашей экосистемы, но и для внешних клиентов. Чем он хорош и какой движок мы выбрали для реализации Workflow Engine, расскажу в посте.
Сегодня обсудим:
Что такое интеграционная платформа
Интеграционная платформа в объединит все интеграции экосистемы МТС, будет управлять ими и делать этот процесс максимально прозрачным. Мы планируем доставлять артефакты интеграции в разные тенанты и в разные индустрии, потому что делаем продукт не только для нашей экосистемы, но и для внешних клиентов — корпораций, банков и так далее. В целом, платформа — это решение для индустрии, которое востребовано на внешнем рынке.
При осуществлении интеграции главное, чтобы она была управляема и наблюдаема, чтобы соблюдался контракт и отслеживался весь трафик. Для чего это нужно? Приведу пример: интеграцию рано или поздно делают все. Представьте, приходит аналитик и говорит: «Ребята, мы хотим подписаться на опубликованную интеграцию». Ему отвечают: «Подписывайтесь, без проблем. Вот вам апишка». Подписались, сделали свой бэкенд, настроили endpoint, но через месяц бэкенда нет. Почему? Потому что версию поменяли или подняли, старая больше не поддерживается. Но контракта нет, а значит нет никаких гарантий, что через минуту ваша интеграция будет работать. Еще один сценарий: нашли описание на Confluence, сделали на своей стороне разработку, выкатили на тест. А потом оказывается, что документ на Confluence устарел, все нужно переделывать.
Платформа закрывает все эти проблемы: интеграция становится полностью управляемой, за выполнением контракта следят.
Возможности интеграционной платформы
Публикация интеграции на едином интеграционном ландшафте. Изначально, когда у нас появляется интеграция, мы должны ее опубликовать, чтобы она была доступна на едином интеграционном ландшафте. К примеру, я захожу в маркетплейс платформы и на едином интеграционном ландшафте могу найти нужную мне интеграцию — допустим, баланс. Дальше я могу ознакомиться с контрактом публикации, потребителями, ограничениями бэкенда, дашбордами доступности — и на основе этого принять решение, подходит мне эта интеграция или нет. Получается, мы даем интеллектуальный поиск, который будет позволять клиенту искать ту интеграцию, которая ему нужна, со всеми синонимами, функциями и предпочтениями.
После того как я ознакомился со всеми условиями интеграции и понял, что они меня устраивают, запускается процесс подключения.
Запрос подключения и подключение пользователя. Например, я хочу подключиться к опубликованной интеграции. Чтобы начать пользоваться ее бэкендом, я должен пройти технологический процесс: трафик согласовывается у ИБ, сетевые доступы запрашиваются у интеграционной платформы. Еще должен быть процесс, который позволяет пользователю авторизовываться, аутентифицироваться, доставлять секреты, управлять ролевой и другими моделями. Эти потребности платформа полностью закрывает.
Эксплуатация интеграции. После того как мы проходим процесс публикации и подписки, начинается процесс эксплуатации интеграции. Мы наблюдаем, мониторим, контролируем трафик и соблюдение контракта. Например, мы должны понимать, что на определенном этапе у нас превысили РПС. Допустим, я кидаю интеграцию, публикую и говорю: «Бэкенд дает только 1 000 РПС». Приходит потребитель и отвечает: «А я буду использовать весь ресурс бэкенда поставщика данных, больше никому ничего не достанется». Такой ситуации не может быть, потому что мы четко контролируем, чтобы пользователи не использовали больше, чем мы даем.
Все эти этапы нам нужно прозрачно показывать пользователю. Кто-то, к примеру, скажет: «А может, у нас процесс согласования с ИБ более сложный или вообще другой?». Значит, мы должны дать клиенту возможность формировать статусы и процессы на всех этапах интеграции, кастомной реализации. Мы говорим: «Ребята, вы можете использовать наш процесс. Но если он вас не устраивает, вы можете под него подстроиться». Как раз на этом этапе и родился Workflow Engine. О нем — дальше.
Зачем интеграционной платформе Workflow Engine
На схеме видно, что Workflow Engine цепляет все этапы работы платформы: от появления апишки на уровне инвентари (интеграции, опубликованной на едином интеграционном ландшафте без runtime) до ее появления в самом контуре, где осуществляется runtime.
Можно сказать, что Workflow Engine — это система, которая позволяет платформе формировать технологические процессы и сложные композитные сценарии интеграций. Еще Workflow Engine — это ядро системы для создания композитных интеграций.
Мы решили: раз нам нужен Workflow Engine, который должен динамически настраиваться, то нам подойдет какая-нибудь low-code-система. Такая, которую мы сможем использовать как ядро реализации Workflow Engine.
Какие low-code-системы исследовали
У нас было около 40 критериев для оценки систем, мы объединили их в пять основных:
лицензия;
масштабируемость;
визуальный редактор;
операционная сложность;
порог входа.
В финальную выборку вошли такие системы:
Дальше расскажу кратко, как мы оценивали все эти системы. Тут важно понимать, что наши выводы субъективны, они основаны на нашем собственном опыте. Тема спорная, и у вас, конечно же, свой опыт.
N8N
Тут много пресетов, хороший визуал в целом. Система была бы классной, если бы не лицензия.
Недостатки:
Лицензия нам не подошла. Систему нельзя поставлять как коммерческий продукт. Если ты уходишь на другой проект, N8N нельзя унести с собой.
Проблемы с масштабируемостью. Я не могу выделить свой Workflow в отдельный процесс. Например, я хочу, чтобы процесс выполнялся отдельно от ядра. Но ядро по-любому его исполняет, изолировать это никак нельзя. Отсюда операционная сложность, ведь мне нужно отслеживать процессы, которые есть внутри. А для меня важно, чтобы эти процессы были прозрачны для клиента, чтобы все понимали, что происходит.
Высокий порог входа. Шаг влево, шаг вправо — и это код на JavaScript. С чем это связано, понятно: решение общее, оно делалось под многие задачи. Из-за этого увеличивается порог входа в систему. Но давайте будем честны: среднестатистический аналитик, придя в N8N, не будет писать свои кубики на JavaScript.
Camel K
Главным преимуществом для нас была лицензия: продукт можно поставлять для коммерческого использования, применяя решения, которые есть.
Недостатки:
Проблемы с масштабируемостью. Camel K поставляется сборкой, функциональность расширяется при помощи Camel. Но как отдельный артефакт, исполняемый в k8s (к примеру, того же самого Workflow), я поставить не могу. Еще тут нет контроля за процессами, из-за этого повышается операционная сложность.
Нет визуального редактора. Вместо него — плагины. Но выглядят они, на мой вкус, не очень хорошо.
Высокий порог входа. Аналитик с этой системой точно ничего не сделает, но мидл-разработчик Java, скорее всего, разберется. В целом система не подойдет для этапа пользователя, когда нужно легко и быстро поправить свой процесс и запустить его в работу. Здесь нужен человек с опытом, который будет «пилить» Camel, рисовать Workflow и реализовывать решения.
Camunda
Рассматривали седьмую и восьмую версии. Восьмая сразу отвалилась, потому что некоторые функции стали платными — например, комбинированная история прохождения запуска процесса. Так что мы просто не смогли с ней работать.
Преимуществами для нас были лицензия и масштабируемость: каждый процесс мы можем поднимать одним инстансом в кубере. Ну и идеальный порог входа: это BPMN 2.0 нотация — самое популярное, что сейчас есть рынке.
Недостатки:
Неподходящий визуальный редактор. Он классный. Но встроить его в наше решение мы не можем, потому что кастомизировать достаточно сложно.
Высокая операционная сложность. История и управление процессами находятся в БД. Эксплуатировать систему сложно — например, без визуальных решений непонятно, на каком этапе находится процесс.
Какую систему выбрали и почему
Мы остановились на Temporal. В целом нам не подошел ни один визуальный редактор, а в Temporal его в принципе нет. Зато все остальное нам понравилось больше. Мы уходили в концепт представления наших примитивов, кубиков в виде подов k8s. Temporal — только исполнитель этого Workflow, так что эта концепция нам подошла.
Наша разработка отлично укладывалась в концепт, но дальше мы стали думать: как сделать так, чтобы не зависеть от ядра и при этом дать кастомизацию клиенту?
Получили два сервиса:
работа с пользователем и представление данных;
исполнитель пользовательских композитов.
Дальше — подробнее о них.
Работа с пользователем и представление данных. Пользователь через GUI или Workflow Language генерирует свое описание Workflow. По сути говорит: «Вот здесь у меня такой кубик, он запускает такой примитив с такими-то параметрами, такие-то параметры нужно передать дальше, обработать вот таким образом».
Workflow Language может быть миллион: 10, 15, 20, сколько фантазии хватит. Можно даже придумать свое описание, преобразовать в единый формат кода — и все будет работать. Здесь мы никак не ограничиваем клиента. Можно использовать PlantUML, поставляется «из коробки», а можно любую другую нотацию, которую использует для представления своего процесса индустрия. Все это разрабатывается легко: перегоняется в код, загоняется в ядро Temporal. Например, если вы не хотите писать на PlantUML, есть GUI, где можно красиво таскать кубики и все настраивать.
Пара слов о Workflow Language. Обычно это нотация PlantUML, где через комментарии на каждый из кубиков прикрепляются якори. К каждому якорю пишется нотация, которая сообщает, что мы вызываем кафку с такими-то аргументами и трансформингом. На выходе получаем историю, которую уже подсвечиваем: какие были шаги, по какому пути. Это просто Workflow Language. Здесь нет никакого GUI, но с GUI можно сделать все еще красивее.
Исполнитель пользовательских композитов. Здесь у нас находится Temporal, который состоит из трех сущностей:
примитив — те истории, которые используются в Workflow;
коннектор — к примеру, подключение к базе данных и выполнение функции;
воркер — обработка стрима данных.
Важный момент: у Temporal нет кастомизации. Если мы захотим заменить исполнитель пайплайнов в ядре, то легко можем вместо Temporal поставить любую другую систему. Все кубики, которые накидывает пользователь, формируются отдельными сущностями в виде подов в k8s.
Итог
В нашей интеграционной платформе мы сделали rest, примитив kafka, xslt-преобразователь, коннектор к базе данных и выполнение скриптов к базе данных, sap-коннектор. Сейчас доделываем rabbit-коннектор и примитив.
Пока у меня все, но я готов отвечать на ваши вопросы. Спасибо, что читали!