Обзор iPaaS платформы MuleSoft Anypoint
Всем привет! Меня зовут Иван, я System Integration Architect в SoftServe, и в этой статье я хочу сделать обзор iPaaS (Integration Platforms as a Service) решения от MuleSoft: AnyPoint Platform. Это одна из нескольких платформ, которые мы внедряем для заказчиков, а также используем для собственных нужд компании для интеграции десятков внутренних учетных систем.
Исторически ESB-like-продукты появились раньше iPaaS, и основной их задачей была интеграция систем и сервисов в рамках одной организации.
ESB, полностью находясь во внутренней инфраструктуре компании, становится очень важной ее частью в аспектах надежности, масштабируемости и гибкости. Если большое число коммуникаций между системами обрабатывается шиной, появляется сильная завязка на нее и внесение изменений становится довольно трудной задачей.
Со временем, благодаря развитию облачных технологий и всевозможных решений (IaaS, PaaS, SaaS, DaaS и др.), появились организации, которые используют облака для хранения и обработки своей информации. Многие системы мигрируют в облака или имеют исключительно облачную версию. Нередки случаи, когда компании вообще не имеют своей домашней (on-premises) инфраструктуры, а используют только cloud-решения.
Если, например, у вас есть системы E-commerce и Product intelligence, которые выполняются в облаке, то нет никакого резона создавать on-premises-решение, требующее дополнительные ресурсы (серверы, администраторы и т. д.)
Систем становится все больше и больше, а задача обеспечения обмена данными между ними — все актуальнее. Количество возможных комбинаций растет с огромной скоростью. Многие системы, например SAP, уже «из коробки» предлагают всевозможные инструменты для интеграции в виде интерфейсов или даже узкоспециализированных коннекторов, но очень часто этих возможностей хватает только для типовых задач или же все равно предполагается, что интеграция будет выполнена за рамками системы.
Еще один частый вопрос — Build vs Buy. Зачем покупать то, что можно разработать самому? В случае с iPaaS и изначальной ориентацией на облачные среды выполнения и контейнеризацию, вопрос масштабирования (и, следовательно, цены) решается намного легче, и построить свою инфраструктуру с iPaaS можно намного быстрее и качественнее, чем начинать все с нуля.
В этой статье я опишу те инструменты, которые входят в состав платформы MuleSoft AnyPoint Platform, используются для реализации задач интеграции и позволяют сократить трудозатраты на выполнение работ.
Подход к разработке
Любой продукт при создании несет определенную идею и конкретный подход к тому, как его правильно использовать.
Компания MuleSoft предлагает так называемый API-led Connectivity approach. API-led (он же Interface First) — это методология, описывающая способ передачи данных к приложениям через повторно используемые и специализированные API. Эти API разрабатываются для того, чтобы играть определенную роль: агрегация данных из разных систем, объединение данных в процессы или предоставление конечного сервиса.
Функционально все API на платформе можно организовать в 3 слоя. Такая декомпозиция (System, Process, Experience API) дает гибкость в построении новых интерфейсов из того набора, что уже есть в портфолио, и за счет нескольких уровней абстракции для конечного интерфейса (Experience API) не столь важно, какая система предоставляет эти данные.
Для примера:
- System API — интерфейс получения данных из системы управления базами данных, файлов, каких-либо учетных систем. Реализовав его, мы предоставляем потребителям этого интерфейса данные и освобождаем пользователя сервиса от необходимости решать инфраструктурные задачи или глубоко разбираться в специфике конкретного источника данных.
- Process API — интерфейс для выполнения какой-либо бизнес-значимой операции: обработки заказа, регистрации пользователя, выполнения распределенной транзакции, которая затрагивает несколько систем или их функций.
- Experience API — интерфейс, удобный для потребителя. Одну и ту же бизнес-функцию может понадобиться предоставить различным системам, клиентам из мобильных или веб-приложений, в B2B-сценарии и т. д.
Например, у нас есть база данных с таблицами, которые мы хотим обрабатывать.
Тогда интерфейс с CRUD-операциями будет из слоя System API. Далее из этих и других интерфейсов мы разрабатываем более сложную логику в виде функции из Process API: например, получить данные из очереди, загрузить список записей в базу и ответить о выполнении. На уровне Experience API эту операцию по загрузке данных мы можем предоставить в JSON-виде через HTTP POST метод или
Для крупных организаций с большим IT-отделом и различными бизнес-подразделениями/командами данный подход позволит уменьшить зависимость друг от друга. Предлагается следующий сценарий разделения ролей: Central IT — подразделение, которое создает фундамент, — API к конечным системам. Это позволяет пользователям платформы использовать функции System API для построения более сложных операций. Line of Business (LoB) может использовать их для описания своих процессов или функций. В данном случае мы говорим не о бизнес-пользователях, а о разработчиках, которые реализуют проект для конкретного бизнес-проекта. И на уровне Experience API эти процессы/бизнес-функции предоставляются клиентским приложениям в том виде, в котором они того требуют.
Для небольших проектов или организаций это может быть избыточным, но сама возможность реализовать такой системный подход при помощи платформы показывает ее применимость для любого уровня проектов.
При таком подходе возникает большое количество различных типов API и зон ответственности, и без соответствующего инструментария их организации не обойтись. Далее мы рассмотрим, что же есть в MuleSoft Anypoint.
Что входит в платформу
При разработке интеграционных приложений, как и других приложений, возникают задачи управления их жизненным циклом (дизайн, разработка, тестирование, установка, мониторинг, анализ проблем), а также организационные аспекты (совместная разработка, документирование, безопасность, разделение прав).
В MuleSoft Anypoint Platform имеется готовый набор инструментов, которые помогают решать все эти задачи.
Условно все составляющие платформы можно разделить на 4 основных блока:
- репозитарий артефактов;
- среда разработки;
- среда выполнения;
- инструментарий для управления платформой и ее функциями.
Репозитарий — Anypoint Exchange
Anypoint Exchange предназначен для того, чтобы вести каталог, искать и делиться различными артефактами — API, фрагментами кода, шаблонами, примерами, коннекторами и т. д.
Все эти артефакты могут быть предоставлены публично или в рамках вашей организации. Таким образом, для начала работы может быть очень полезно исследовать публичный Exchange и найти много заготовок в открытом доступе, если вы находитесь на начальном этапе внедрения платформы в своих проектах. Посмотреть, что сейчас доступно в публичном доступе, можно на странице Anypoint Exchange.
Если вы разработали спецификацию интерфейса, ее можно опубликовать в Exchange и сделать доступной для других. Тогда эта спецификация получит свой собственный portal — страницу с описанием сервиса и возможностью получить и вызвать его mock-endpoint. Реальная реализация интерфейса не обязательна. Очень часто в задачах интеграции мы работаем с другими командами, и API-спецификация — это наш с ними «контракт» взаимодействия. И чем раньше он будет доступен, тем меньше времени будет потрачено на согласование, документирование и постановку задач.
Что удобно при работе с другими командами: нет необходимости ждать готовой реализации API и можно начать работу по интеграции сервиса со своей стороны независимо от других. Главное — наличие контракта, по которому будет выполняться интеграция.
В своей практике я сталкивался с организациями, которые пытались вести эти спецификации в виде обычных документов, но зачастую это выливалось в то, что документ становился неактуальным. Простые Word-документы пересылались по почте, и легко можно было получить устаревшую или неполную версию. Exchange же облегчает работу по документированию, версионированию и публикации спецификаций.
Среда разработки
Design Center
Design Center — браузерная среда разработки. При ее помощи можно:
- разрабатывать спецификацию API на языке RAML (RESTful API Modeling Language);
- разрабатывать Mule-приложения для CloudHub.
RAML для платформы AnyPoint принят как основной способ по документированию и разработке интерфейсов.
IDE
Anypoint Studio — основной инструмент по разработке Mule-приложений, построен на основе Eclipse со своим набором для визуального моделирования и создания трансформаций, каталогом готовых компонент и доступом к Anypoint Exchange. Для тех, кто знаком с разработкой на Java, все очень похоже. Основа приложения — Flow — описание того, как события, которые поступают в приложение, им обрабатываются.
Для этого строится цепочка из обработчиков, каждый из которых отвечает за свою функцию: трансформацию, сериализацию, логирование, доступ к БД и т. д. Палитра содержит набор готовых обработчиков, которые можно встроить в поток и настроить соответственно задаче.
Очень частой задачей бывает трансформация данных. Одна система может передать в виде запроса массив в формате XML, в то время как другая ожидает JSON совсем в другой структуре. Для облегчения процесса написания этой трансформации в Anypoint Studio есть визуальные средства по разработке.
Для тестирования приложений имеется MUnit фреймворк, в котором теми же инструментами, что и при разработке, можно писать юнит-тесты и получать результаты по покрытию потоков тестами. А поддержка Maven дает возможность построить CI/CD-процессы как для обычных Java-приложений.
На самом деле тема разработки приложений довольно обширная и заслуживает отдельной статьи.
Инструменты управления
API Manager
API Manager — компонент платформы, который отвечает за управление теми API, которые уже развернуты и используются. Тут мы можем применять политики и ограничивать частоту использования или накладывать ограничения по безопасности. Политики могут быть применены к различным средам выполнения, и разработчики освобождаются от этих вопросов.
Runtime Manager
Runtime Manager — это компонент для управления средами выполнения и приложениями, которые на этих средах установлены. Среды выполнения могут находится в облаке, on-premise или в private cloud. Тут можно следить за состоянием, запускать/останавливать серверы и приложения, отслеживать активность выполняющихся приложений.
Anypoint Visualizer
Anypoint Visualizer помогает отобразить информацию о ваших API и Mule-приложениях, которые выполняются. Visualizer собирает данные от приложений, прокси-приложений, которые выполняются на CloudHub или в других средах через встроенный компонент мониторинга среды. Visualizer дает понять, как ваше приложение зависит от других сервисов, и проводит анализ проблем, связанных с ошибками или производительностью.
Anypoint Monitoring
Тут мы сможем наблюдать статистику выполнения. Из метрик, которые платформа собирает, есть возможность настроить собственные dashboards с теми показателями, которые наиболее актуальны для вас.
Access Management
Access Management — это консоль по управлению доступом и правами в рамках вашей организации. Как администратор организации или одной из бизнес-групп, вы можете работать с учетными записями пользователей и их привилегиями.
Secret Manager
Предоставляет доступ к хранилищу паролей, ключей, сертификатов. Для обеспечения безопасности эта функция может быть полностью передана выделенной роли, и разработчики будут освобождены от необходимости хранить, передавать и настраивать эти аспекты на различных средах.
А как на практике
Исходя из личного опыта, могу сказать, что платформа довольно дружелюбна для новичков. В одном из последних проектов команда из
При разработке есть своя специфика, к которой нужно привыкнуть. Например, совместная работа и merge кода. Так как вся реализация хранится в виде
Как начать
Регистрируйтесь и получайте бесплатный триал на 30 дней с доступом к CloudHub.
Что почитать
Если вы интересуетесь направлением системных интеграций, то начать ознакомление с iPaaS-приложениями, как и с профессией System Integration Engineer в целом, стоит c обзорного материала по интеграционным платформам, опубликованного ранее моим коллегой.
