Как делать интеграции правильно и быстро

Интеграция – это очень важная и обманчиво простая тема. Я уже 26 лет в ИТ и замечаю, что в огромном количестве команд на сегодняшний момент интеграции делаются неправильно.

Что такое идеальная интеграция

Давайте разберем, что такое идеальная интеграция. Даже скорее, что такое идеальная архитектура в целом.

Отказ одного потока не приводит к каскаду отказов
В идеальной интеграции все ошибки инкапсулированы. Если у вас сломался какой-то поток, то перестал работать только он. Все остальное продолжит работать без проблем.

Надежность и высокая скорость

Интеграция должна быть надежной и быстрой. Эта скорость должна выражаться в каких-то цифрах – например, рассчитываться по метрикам DORA (DevOps Research and Assessment). Или по методике от команды исследователей QSM (Quantitative Software Management).

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

Рассмотрим пример интеграции

Рассмотрим простой пример интеграции между CRM-системой и интернет-магазином (eShop). Здесь всего два потока – по нынешним временам это вроде и не система вовсе.

Можно ли в этом случае использовать интеграцию «точка-точка»? Или нужен какой-то промежуточный слой?

Давайте разберем проблему контекстов, возникающую в монолитной архитектуре.

Проблема контекстов

С точки зрения CRM-системы “покупатель” – это один набор атрибутов. С точки зрения eShop “покупатель” – это совершенно другой набор атрибутов.

В идеальной архитектуре эти наборы атрибутов должны существовать независимо друг от друга, потому что это разные контексты.

Интеграция «точка-точка» здесь приведет к тому, что:

• Одна система будет знать контекст другой системы. Т.е. CRM-система будет знать о том, что для eShop нужно фамилию и имя выкинуть, email как-то преобразовать и так далее. Но с точки зрения ЦКП (ценного конечного продукта) CRM-системе это знание не нужно.

• Если мы захотим обновить CRM-систему или eShop, что-то в ней добавить, мы должны будем дорабатывать интеграцию. С точки зрения идеальной архитектуры это нонсенс, такого быть не должно.

Техподдержка и прямые интеграции

Интеграции “точка-точка” в итоге превращают IT-контур в паутину сервисов.

В таком контуре, если с какой-то сущностью возникает проблема (заказ потерялся или цена неактуальная) только разработчик в состоянии понять, в какой цепочке возникла ошибка.

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

Можно ли здесь в этом случае внедрить техподдержку? Я напомню, что техподдержка – это низкоквалифицированные специалисты, которые отвечают на вопросы пользователей и могут идентифицировать проблемы.

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

Проблема монолитов

Ключевое свойство монолита – то, что каждая следующая фича в вашем программном комплексе обходится для вас дороже и дольше.

И ваша задача – как управленцев, так и разработчиков – не подойти к этой черте, после которой любая фича теряет разумные сроки и стоимость. Потому что после этой черты для вас начнется ад – будут прилетать все новые фичи, но вы не будете успевать их делать.

Пример интеграций через шину

Давайте смоделируем ситуацию, что мы – интернет-магазин, и у нас есть некоторое количество поставщиков, от которых мы получаем товары, остатки, цены.

Как реализовать такую интеграцию? Если говорить абстрактно, для такой интеграции нам нужно:

• Некое хранилище. Обратите внимание, я не говорю, что нужен брокер, потому что неважно, как устроено хранилище. Не нужно говорить технарям, как именно реализовывать хранилище. Они сами разберутся – это их зона ответственности.

• Кроме хранилища нам нужно будет еще какое-то логирование.

• И еще нужен какой-то способ создания интеграций. Не сами интеграции, интеграции не в нашей зоне ответственности.

То, что выделено на слайде зеленым – это зона ответственности шины.

Для каждого поставщика у нас используется свой интерфейс к хранилищу:

• Например, 10 поставщиков хотят к нам обратиться через API – это один интерфейс.

• А какой-то отдельный поставщик, очень привилегированный, хочет слать свои Excel файлы по почте – это другой интерфейс.

• А кто-то хочет делать это через личный кабинет – это третий интерфейс.

И интернет-магазин эту информацию забирает.

Теперь давайте подумаем, что произойдет, если мы добавим сюда какую-нибудь еще систему – например, PIM-систему для управления данными о товарах.

Например, от одного поставщика у нас приходит «Ручка синяя», а от другого – «Ручка синяя » (с пробелом в конце). По факту, и то и то – «Ручка синяя». Чтобы из двух товаров от разных поставщиков сделать один мастер-товар, используется PIM-система.

Обратите внимание, что в правильной интеграции при внедрении PIM-системы никакая другая система не поменяется. PIM-система использует то же самое хранилище. Неважно, как оно устроено. Забирает товары и обратно возвращает группу товаров.

Когда Product Owner интернет-магазина сочтет нужным, он положит к себе в бэклог фичу интеграции с PIM-системой и возьмет в работу. В результате изменится поток, но только на уровне интеграции. А интеграция здесь – это очень изолированный и очень компактный кусочек кода.

Сам интернет-магазин у нас может быть абсолютно любым – облачный интернет-магазин, маркетплейс – все что угодно. У нас может быть два интернет-магазина или три. У нас может быть две PIM-системы, или при желании мы можем заменить PIM-систему. В данном случае PIM-система находится полностью в ведении Product Owner – только он решает, из чего это программное решение состоит.

Мы можем добавить «Сервис ценообразования» – то же самое. Один поставщик нам присылает синюю ручку по 10 рублей, второй – по 11 рублей, а мы считаем, что правильная цена должна быть средняя – 10,5.

Мы просто добавляем новую сущность в хранилище. И когда интернет-магазин захочет, или когда это будет определено общими политиками компании, они добавят себе в бэклог задачу интеграции с сервисом ценообразования. При этом никакие другие системы не изменятся.

Шина позволяет разделить ответственность. Потому что за интерфейс к интернет-магазину отвечают только те ребята, которые занимаются интернет-магазином – не те, кто занимается шиной.

Шина и подключение техподдержки

Допустим, интернет-магазин написан на Java, PIM-система – на Python, а сервис ценообразования – на Golang. С точки зрения техподдержки концепция шины позволяет подчинить все это единым правилам логирования.

Потому что где-то в идеальной картине мира должна быть техподдержка, которая сигнализирует о проблемах. А разработчики при этом могут спокойно спать – тогда, когда нужно, а не тогда, когда удается.

Техподдержка всегда работает с отклонениями, поэтому нам важно их определить.. Сегодня у меня 20 тысяч чего-то прошло через интерфейс, а завтра 10 тысяч. Это нормальное отклонение или нет? Смотрим и настраиваем правила. Например, если прошло меньше половины – ненормально. Т.е. 9 тысяч уже ненормально.

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

Обязательно прочтите Эрика Эванса «Предметно-ориентированное проектирование (Domain Driven Design, DDD). Структуризация сложных программных систем». Без этого, в принципе, разрабатывать нельзя – без этого невозможно понять смысл и принципы объектно-ориентированного программирования.

Эрик Эванс говорит: «Если у вас предметная область расходится с технической реализацией, и разработчики не мыслят теми же терминами, какими мыслит бизнес – архитектура будет плохой».

Поэтому держите схемы простыми и понятными – по принципу KISS (Keep it simple, stupid).

Шина, SOA и слабая связанность

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

Я в очень крупных организациях встречаю такое состояние, когда в компании нет ответственного за начисление бонусов. Правила начисления настраиваются в одной системе, в POS-системах данные как-то преобразуются, потом отправляются в CRM-систему, и там начисляются бонусы. Ответственного нет.

Если ответственного нет, сделать потоки понятными нельзя – это будет лапша, как я вам чуть ранее показывал. Сделать правильную архитектуру, не расшивая зоны ответственности, не избавляясь от связанности, невозможно.

Первым кирпичиком для построения нормальных интеграций является сервисная карта (Service maps), где мы определяем зоны ответственности каждой системы. Например, указываем, что:

• CRM-система отвечает за хранение информации по клиентам и всю историю взаимодействия с ними.

• Интернет-магазин отвечает за онлайн-заказы.

• PIM-система – это мастер-система по товарам, и так далее.

Слабая связанность, loosely coupled – ключевой принцип инженерии, который слишком часто нарушается.

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

Но если у вас сложные интеграции, появление любого нового решения в контуре – это будет проект длиной в год. На который, конечно, не найдется бюджета.

Итого про мифы

• Шины – это не брокеры. Если вы думаете иначе – это заблуждение.

• Если вы думаете, что паутина сервисов – это микросервисная архитектура, вам надо перечитать Томаса Эрла. Микросервисная архитектура – это архитектура только одного контекста, bounded context, архитектура одного приложения. CRM-система может быть микросервисной. eShop может быть микросервисным. Но обмен между ними никогда не микросервисный. Понятно, что для интеграции, как правило, используется микросервисный подход. Но с точки зрения организационной структуры это разные сервисы.

• Не стоит отказываться от low-code в пользу собственного решения. Я несколько раз в крупных компаниях с тысячами собственных разработчиков слышал примерно следующее: «Шины плохие, мы напишем собственную». Отлично. 20 лет какой-нибудь Talend оттачивает свои коннекторы и следит за их непротиворечивостью. Но мы тут суперумные, мы и сами напишем. Как мне один питонист сказал: «Я чихнул, у меня 25 строк кода».

Шина и качество архитектуры

• Если у вас плохая архитектура, вы не сможете внедрить шину.

• Если у вас перемешанный контекст, вы не сможете применять Middleware в том или ином виде.

• Перемешанные контексты – это 100% плохая архитектура контура. Это значит, что на кривой монолита вы находитесь высоко – внедрение новых фич вам обходится дорого.

Я думаю, вы и так понимаете, почему плохую архитектуру с перемешанным контекстом нужно избегать.

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

Code first, no-code, low-code

В жизни любого нормального предприятия топ-менеджер или бухгалтер может захотеть интегрировать 1С с Google Form или с Notion – инструменты no-code позволят вам это сделать. А подходу Code First вы никакого бухгалтера не научите – он вам сам никакой коннектор не напишет.

Поэтому развитие точек инновации – это очень важная часть управленцев и ИТ-директоров, которые хотят ускорять свои компании.

Теперь по поводу Code first vs no-code.

Ваше право, как строить интеграцию. Даже если у вас будет Code first-решение – это лучше, чем ничего.

Но все современные шины так или иначе тяготеют в сторону подхода no-code. И если вы посмотрите на развитие облачных решений iPaaS – Integration Platform as a Service – это тоже в основном решения, построенные по философии no-code. Даже если они low-code.

Как сказали в Google в 2021-м году: «No-code is a new low-code» – потому что Google сталкивается ровно с теми же проблемами, которые есть у любой организации. Там тоже непонятно – кому делать архконтроль.

Ссылки и рекомендации

В заключение советую вам почитать State of DevOps report от компании DORA, за который Джез Хамбл в 2019 году получил премию Шинго (например, его вариант, переведенный на русский язык, от Николая Воробьева-Сарматова). В этом отчете проведено исследование большого количества разных предприятий – и маленьких, и крупных, и очень крупных компаний с тысячами серверов. Они вывели несколько показателей продуктивности программного обеспечения: частота развертывания; срок реализации изменений; время восстановления сервиса; доля неудачных изменений. Я вам рекомендую внедрить эти метрики, чтобы понимать, насколько вы быстрые. Чтобы внедрять любое изменение и видеть, насколько вы ближе к хорошей культуре инноваций.

Еще хочу вам предложить посмотреть видео «Почему в Google нет тестировщиков». Эта тема важна, потому что в ИТ-отрасли многие не понимают, зачем нужны тестировщики, что такое Software Engineer, что такое Software Engineer in Test и т.д.

Я предлагаю рассмотреть опыт Google, который очень много вкладывается в развитие инженерных практик, и делает огромное количество отчетов – почти все отчеты QSM проинвестированы Google, и та же DORA с 2015 года финансируется Google.

Опыт Google доказывает, что тестировщики применимы только в линейных – простых и сложных средах, в которых ключ успеха – исполнение регламентов. А в запутанной среде, в программном обеспечении, которое развивается по принципам Agile, наличие промежуточного звена при доставке ценности от разработчика к Product Owner’у снижает ответственность и создает основу для масштабных ошибок.

Вопросы

Вот этот список шин, который у вас был на слайде – это ваши личные предпочтения или вы просто по порядку любые выбрали?

Да, это наиболее употребимые на российском рынке шины. Например, Mule ESB очень популярный.

Я опирался на то, что может быть в России, поэтому, например, Workato я здесь не привел, хотя по Гартнеру он гораздо выше.

Посоветовать топ-5 не можете?

Сейчас практически все шины – тот же Mule ESB – переходят в состояние iPaaS. А в iPaaS очень просто выбрать. Берете любую задачу, сажаете ответственного разработчика и просите сконфигурировать задачу там.

Сразу выяснится, что для каких-то потоков подойдет что-то очень простое, типа Zapier – бухгалтеру очень легко передавать Zapier: «Вот здесь кликаешь, и тут твоя табличка. А тут кликаешь, и тут твой Notion».

Для более сложных кейсов мы используем Workato. Можете использовать Mule ESB – это шина от Salesforce, я их тоже очень рекомендую. Или 1С:Шину – я не знаю этот продукт, но говорят, очень хороший.

Среди iPaaS систем я еще могу посоветовать Choreo. Это достаточно неплохой продукт от разработчиков, которые делали шину WSO2, и язык программирования для интеграции Balerina. Попробуйте.

Я представитель Enterprise с очень крупным ИТ-ландшафтом, где для решения задачи выбираются лучшие продукты в своем классе, посередине стоит шина, управляет интеграциями, и так далее. Я для себя не раскрыл историю того, как максимально качественно документировать все эти интеграции, чтобы можно было бизнесу предоставить. Есть ли какие-то лучшие паттерны, практики, может софт какой-то есть упрощающий эту задачу. Как это все документировать?

Документация с точки зрения организационного контура – это выход каждой из систем.

Вообще документация немножко противоречит DevOps практикам.

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

Никакой особой документации по потокам мы не пишем.

А дальше каждый разработчик своей системы может использовать, например, Postman.

Описывайте интерфейсы, как хотите. Но это уже техническое описание.

Если вы Enterprise, значит, у вас есть команды, и надо командам делегировать ответственность полностью. Потому что в треугольнике «знания, ответственность, контроль», у них должны быть и знания, и ответственность, и контроль по поводу всего. Поэтому тут мы не видим смысла в документации потоков.

А зачем она вам нужна?

Мой кейс заключается в том, что приходит какой-нибудь представитель бизнеса, который хочет видеть, как у него ходят те или иные пакеты данных – как они маршрутизируются, что является первоисточником данных, кто является потребителем этих данных, и так далее.

Мы используем Service maps, сервисные карты, где указана зона области действия каждого сервиса.

• PIM-система – это мастер-система по продуктам.

• Клиенты у нас в CRM-системе

• Цены, Остатки, Склады – в ERP.

Даже топ-менеджеры, когда смотрят на эту схему, очень быстро понимают: «Мы тогда возьмем отсюда, потому что новое подразделение будет работать вот так».

Или, если нужно исходить из процессного подхода, мы берем описание орг. структур – т.е. сама орг. структура может содержать информацию о том, где у процессов есть вход и выход.

Если вы описываете все верхнеуровневые процессы на исполнительном уровне, у вас каждый уровень будет разбит на:

• вход – то, что он получает. В данном случае интернет-магазин получает из основной системы товары, остатки, цены;

• а выход его – продажи.

Это тоже очень простая визуализация.

Service maps – это какой-то сервис?

Это графы сервисов.

Что за шаблон взят в основу? Хотелось бы посмотреть на примеры таких карт. На чем они построены? Как они рисуются?

Мы их рисуем в mindmaps. У нас сервисная карта – это стикеры с понятным для бизнеса описанием, за какие сущности эта система отвечает.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.