Что такое Integration Development в общем и Mulesoft в частности

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

День добрый. Я разработчик интеграций в компании Customertimes и с данной технологией работаю ужу почти два года. Эта статья будет посвящена тому, что такое Integration Development в целом и как сюда вписывается Mulesoft.

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

Что такое Integration Development

Начнём, пожалуй, с того, почему вообще появилась такая вещь, как Integration Development, и какую проблему он должен решать. Дело в том, что комплексная ИТ-инфраструктура в нынешние времена стала необходимостью для большинства бизнеса, даже если этот бизнес ничего общего с ИТ не имеет. Сложно представить даже маленькую контору, которая бы обходилась без софта, скажем, для бухгалтерии. И обычно при росте компании растут и объемы необходимой ИТ-инфраструктуры.

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

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

Есть несколько вариантов решения этой проблемы:

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

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

2) Решать каждую проблему взаимосвязи систем индивидуально.

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

3) Integration Developers и интеграционные платформы.

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

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

Платформа Mulesoft

Давайте рассмотрим интеграционные платформы на примере одной из них — Mulesoft.

Как работать с Mulesoft и чем он удобен для разработчиков? Давайте по порядку. Прошу также учесть, что я опираюсь в основном на несколько лет персонального опыта работы по разработке Mule приложений.

Прежде всего советую ознакомиться немного с тем, что такое Anypoint Platform и как выглядит экосистема Mule. Подробно описывать платформу на буду, поскольку на эту тему уже была статья. Остановлюсь на нескольких моментах — вся прелесть Mule состоит в Anypoint Platform. Это инструмент, который позволяет крайне просто и эффективно контролировать все АПИ, которые есть в вашей оркестрации. При этом всё максимально интуитивно понятно и удобно — от изначального дизайна будущего АПИ до контролирования доступов, логирования и серверной статистики. На мой взгляд, исходя из того, что я видел и слышал от других специалистов, Mulesoft и Anypoint Platform, с точки зрения менеджмента, — это лучше решение из присутствующих на рынке (но это только моё мнение).

Создание же самого АПИ происходит в фреймворке под названием Anypoint Studio. И тут ситуация, к сожалению, менее радужная. Студия построена на основе Eclipse, и, я думаю, все, кому приходилось работать с Eclipse либо с другими продуктами на базе Eclipse, понимают её проблемы и неудобства. Сама студия также добавляет большое количество своих проблем. С разработкой небольших АПИ (а это то, чем в основном занимается Integration Developer) проблем почти никогда не возникает. Однако, когда имеете дело с разработкой серьезного Process API с большим количеством функционала, студия может тормозить. Но ребята в Mulesoft явно стараются, и баги чинятся относительно быстро.

Ещё одна проблема, с которой вы столкнётесь как Mulesoft Developer — отсутствие большого и развитого комьюнити. Поскольку в наших широтах продукт еще относительно свежий, да и в целом глобальную известность и популярность получил очень недавно — есть вероятность, что проблему, с которой вы столкнулись, быстро нагуглить не получится. В своё время я переходил в Mulesoft разработку из Java, и именно недостаток информации меня поначалу напрягал больше всего. Однако в этом есть и плюс — вместо бездумного поиска первого попавшегося решения на Stack Overfllow приходилось думать и искать решения самостоятельно, что пошло на пользу в дальнейшем.

Кейсы

Хотелось бы остановиться на конкретных примерах работы с Mulesoft из моего опыта. Я расскажу о двух разных по типу, размеру и составу проектах. Как и в ситуации с любой разработкой — каждый проект по-своему интересен и уникален.

Проект № 1. Нужно было разработать интеграции для очень большой компании. Количество разных систем было огромным, причем мы были подключены к проекту на стадии слияния этой компании с ещё одной. А это означало, что нам предстояло объединить две ИТ-инфраструктуры в одну.

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

Моя часть разработки интеграции состояла из двух разных задач — создание одного сложного Process API и создание нескольких типичных небольших System и Experience API. Сложность Process API была обусловлена такими моментами:

• Большое количество вовлеченных систем. Тут был и SAP, и Salesforce и Oracle и т.д.;
• Необходимость создания максимально продуманного error handling;
• API должен отрабатывать максимально эффективно, т. к. это напрямую влияет на клиента;
• API скорее всего будет регулярно меняться, то есть код должен быть максимально понятным и быстро масштабируемым;
• Несмотря на то, что это интеграционное АПИ, сюда была вынесена некоторая часть бизнес-логики.

Сразу уточню по поводу последнего момента. Одна из сложностей, с которой сталкивается практически каждый разработчик интеграций — далеко не все до конца понимают, чем именно должны заниматься интеграции. Это приводит к ситуациям, когда бизнес-логику, которая должна реализовываться в рамках самой системы (будь то Salesforce или SAP, например) решают вынести на интеграционную платформу. Это чревато последствиями, так как интеграционные системы должны заниматься только связкой систем и минимально содержать в себе бизнес-логику, однако такова реальность — очень часто ее просят выносить. Особенно в больших компаниях, где заставить несколько разных департаментов что-то допилить у себя в системах сложнее, чем всю эту логику передать команде интеграции. Если кто хочет более детально изучить вопрос, почему так делать не очень хорошо, рекомендую посмотреть статьи на тему Business Logic vs Integration Logic, которых написано немало.

Наличие большого количество систем выглядит довольно угрожающе поначалу, однако ни разу не попадалась такая система, к которой не было бы готового коннектора. Единственная сложность в том, что необходимо иметь хотя бы общее понимание, как эти системы коммуницируют с внешними системами. Например, если необходимо что-то получать от SAP, то нужно хоть немного понимать, что такое BAPI. Однако тут практически всегда помогает сам Mulesoft, подгружая нужные метаданные и прочее необходимое для разработки. Не могу сказать, что все коннекторы идеальны — баги встречал довольно часто — но ничего такого, что бы полностью блокировало разработку.

Error handling — всегда достаточно болезненная тема. Когда API зависит от тонны других и в себе содержит более ста разных трансформации данных — делать его резистентным к ошибкам непросто. В Mulesoft это сделать возможно и относительно понятно как, однако всё же есть свои минусы. Первый минус — АПИ становится достаточно громоздким, что порой серьёзно тормозит разработку. Второй минус — сам error handling не сразу интуитивно понятен. Однако если есть понимание того, как error handling работает в Java, то проблем здесь возникнуть не должно. Хотелось бы еще посоветовать — когда АПИ зависит от множества других систем — создавайте себе план обработки ошибок заранее. Допиливать это по ходу (как в моём случае) — дело неблагодарное.

Что касается эффективности работы — тут проблем не было замечено. Но самое приятное — это скорость трансформации данных. Именно скрипты трансформации данных (написанные на внутреннем функциональном языке DataWeave), будут зачастую составлять большую часть вашего API. У меня нет под рукой эмпиричных замеров, однако обработка действительно больших документов занимала считаные минуты, именно за счёт функциональной природы языка. В основном все проблемы с работоспособностью всегда были связаны с проблемами во внешних системах. Также есть поддержка асинхрона, параллельной обработки и т.д.

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

Когда же Mulesoft используется полностью по назначению (то есть для создания небольших API, цель которых — исключительно коммуникация систем) — имплементация даже сложной оркестрации занимает небольшое количество времени. От создания дизайна до заливания готового кода в битбакет занимало обычно меньше одного рабочего дня 😊

Проект № 2. Второй проект абсолютно не похож на предыдущий. В этот раз интеграция выполнялась для небольшой компании, которая занималась онлайн-торговлей лекарствами в Польше. Суть системы была в том, что документы с заказами в формате CSV выгружались из базы данных раз в определенное время, после чего в каждом файле необходимо было посчитать количество заказов, добавить определенную метадату типа таймстампа обработки и потом по FTP залить файл на удаленный сервер в папку.

Большая часть процесса состояла как раз в обработке файлов и тут был случай, когда достаточного количества нативных инструментов не было (это были еще времена Mule 3 — предыдущей версии). То есть мы могли загрузить файл, могли сделать общие манипуляции, но выполнить все тонкие операции над контентом файла возможности не было.

Тут помогло то, что в Mulesoft вы не ограничены только теми инструментами, которые вам предоставлены в платформе. Ничего не мешает просто создать свой Spring Bean и вызывать его. Процесс этот несложный и гарантирует, что с небольшими знаниями Java в Mulesoft действительно можно делать что душе угодно (не даром же это в конце концов абстракция над Spring?)

Обучение

Как начать обучение? На самом деле материалов не так уж и много. Прежде всего, я бы рекомендовал курс Anypoint Platform Development: Fundamentals Mule 4 (ну либо Mule 3, если вы любитель ретро) на официальном портале training.mulesoft.com. Информация там подана очень подробно — покрываются все основные моменты. Курс полностью готовит к сдаче экзамена на сертификацию, если у вас возникнет такое желание.

Выводы

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