Привет, Хабр!

Знаете, что объединяет разработчика из стартапа, архитектора банковской системы и техлида платежного сервиса? Все они хотя бы раз материлась над интеграцией, которая должна была занять день, а растянулась на месяц. Легаси не подружилось с новой системой, протоколы оказались несовместимы, а документация — устаревшей на три года.

Мы в Dev Q&A собрали экспертов, которые живут этой болью каждый день: Тимур Васильев (Paybis LTD), Антон Новожилов (mrnet), Роман Кучерский (Rapporto), Дмитрий Гаврин (Диасофт), Евгений Шишкин (Ardecs), Юрий Иванов («Севен Груп»), Павел Лобанов (Comindware). Задали им простой вопрос: почему в 2025 году мы всё ещё соединяем системы костылями, а единого стандарта как не было, так и нет?

Больше часа разговора превратились в откровенный разбор полётов: почему легаси — это не проблема, а фундамент бизнеса, чем Kafka отличается от RabbitMQ на самом деле, и стоит ли доверять open source в критичных интеграциях. Никакой воды — только практический опыт и реальные кейсы.

Я собрал ключевые мысли в эту статью. Кому удобнее слушать — полная версия дискуссии на Rutube. Вопросы и свой опыт пишите в комментариях или в нашем телеграм-канале Dev Q&A — там регулярно проходят такие обсуждения, и сообщество растёт - подпишитесь.

Почему условный USB-C для интеграций — утопия

Пример из жизни: USB-C стал стандартом для зарядки всех устройств в Европе благодаря директиве ЕС. Одно решение — и проблема с десятками разных кабелей исчезла. Почему такая же история не работает с интеграцией систем?

«Если сравнивать со стандартом USB-C, о котором была речь, то в случае Евросоюза главная причина возникновения такого стандарта — это борьба за окружающую среду. Разное количество стандартов приводит к тому, что люди покупают большое количество проводов и так далее, и это косвенно приводит к тому, что мы портим природу. В случае интеграции с этим сложно — если у тебя разные компании делают разные подходы, ты таким образом окружающей среде не навредишь, и поэтому такие органы не влезают в подобного рода вещи. Сложно техническую интеграцию сравнить с USB-C», — отмечает Тимур Васильев, Tech Lead компании Paybis LTD.

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

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

Мем про одиннадцать стандартов — это не шутка, а диагноз

«Есть давний мем, где есть 10 конкурирующих стандартов, приходит один человек и говорит: «Почему нельзя сделать еще один общий стандарт?» — и в итоге получается 11 конкурирующих стандартов. Это стандартная, мне кажется, история. Каждый пытается сделать лучше. Это ровно такой же вопрос, почему нельзя программировать на одном языке», — объясняет руководитель цифровой интеграции и автоматизации процессов в компании mrnet.

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

Легаси — гиря на шее или почему история против стандартов

Даже если представить, что завтра появится волшебный единый стандарт интеграции, поддержанный всеми крупными игроками — что делать с системами, написанными в 1970-х? А их полно, особенно в банковской сфере и на производстве.

Евгений Шишкин, Team Lead компании Ardecs, напоминает о масштабе проблемы:

«Смотрите, у нас ведь есть не только новые системы, а огромное количество легаси-систем, которые разрабатывались в Америке в 60-е, 70-е, 80-е годы. Даже если мы сделаем единый стандарт, кто-то же должен все это мигрировать, а это определенные деньги, причем очень большие деньги. Понятно, что российский рынок более молодой в этом плане, и там можно разрабатывать сразу хорошие интерфейсы и продумывать интеграции заранее, но есть огромный рынок, который к этому пока не готов», — поясняет Шишкин.

Павел Лобанов из Comindware добавляет важный экономический аспект к техническим причинам:

«Сейчас говорить про конкретный золотой стандарт сложно, потому что системы действительно очень разные. При проведении работ — в зависимости от каждой системы, от каждого клиента, который использует то или иное ПО — прийти к единому стандарту сложно. Но при этом зачастую можно использовать микросервисные архитектуры», — начинает Лобанов.

Но главная проблема не техническая, а финансовая:

«Сложности со стандартизацией есть, потому что системы очень разнообразные. Какие-то моменты, связанные с приведением к единому стандарту, возможны, но — говорю больше с точки зрения бизнеса — приходится переписывать код, и часто мы упираемся именно в бюджеты. Происходит цикличный характер обновлений: постоянно появляются новые технологии, которые нам приходится применять для интеграции, для увеличения производительности системы, для расширения количества интеграций", — объясняет эксперт.

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

Легаси — это не проблема?

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

Роман Кучерский, директор департамента информационных технологий компании Rapporto, объясняет суровую правду корпоративного мира:

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

«Стандартизацию тоже можно понимать по-разному. Это же не обязательно какое-то техническое решение. Это может быть и на уровне архитектурных паттернов, которым стремится все IT-сообщество или ваша компания в целом. То есть, говоря про те же интеграции, в свое время особую популярность имели корпоративные шины, сейчас больше стремления в сторону service mesh или, в принципе, разделения на доменные области и прямой коммуникации между сервисами друг с другом", — продолжает эксперт.

Стандарты там, где их не ждали: безопасность решает

«Стандартизация как таковая есть также на уровне протоколов, потому что их ограниченное количество — это HTTP в первую очередь, это какие-то SIP-протоколы для тех, кто в телекоме работает. И вот, оперируя этим количеством протоколов, важно, наверное, думать не только о том, насколько просто совершить интеграцию, важно думать о том, насколько это безопасно. То есть если мы делаем распределенную систему, стандартизируем способы интеграции, то как минимум рано или поздно — но обычно рано — встает вопрос информационной безопасности. И вот как раз стандартизация приходит на уровне обеспечения информационной безопасности: это различные API-gateway, различные SSO, в принципе, которые позволяют так или иначе унифицировать формат взаимодействия систем друг с другом», — объясняет Кучерский логику появления реальных стандартов.

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

Инструменты выживания: как управлять интеграционным хаосом

Дмитрий Гаврин, заместитель директора департамента цифровых решений компании "Диасофт", формулирует ключевую мысль из опыта трех десятилетий работы с интеграциями:

«Зачастую, входя в проекты, просто нет никакой технической возможности переписать легаси. В нашей практике мы занимаемся интеграцией больше 30 лет. Я отношусь к легаси-системам как к солнцу, которое утром встает, вечером садится. Мы можем долго дискутировать, что легаси надо переписать, что разработчики хотят это сделать, а бизнес — нет. Но факт остается фактом: легаси есть и будет. В интеграционных проектах от этого не уйти", — объясняет Гаврин.

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

Подходы к интеграции эволюционировали вместе с ростом сложности систем. Дмитрий Гаврин описывает этот путь: "Вначале были интеграции «точка-точка» — прямые связи между системами. Минус в том, что когда систем становится, например, 10, дальнейшее развитие становится тяжелым — связей слишком много, управлять ими сложно", — начинает Гаврин.

"Следующий этап — решения ESB, когда ставится централизованная проприетарная шина, и все правила взаимодействия между системами настраиваются в едином инструменте. Но и здесь есть недостатки. Во-первых, со временем эта конструкция тоже становится чрезвычайно сложной — когда интеграций больше 100 или 200, это уже невозможно удержать в голове. Во-вторых, проблемы с масштабируемостью: горизонтальное масштабирование зачастую невозможно, потому что это монолитное решение. И, соответственно, появляется централизованная точка отказа", — перечисляет проблемы эксперт.

Современные шины: не хороните их раньше времени

Юрий Иванов, ведущий разработчик «Севен Груп», возражает против упрощенного взгляда на корпоративные шины как на устаревшую технологию:

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

Но дальше он описывает современный подход: «Но есть современные шины, которые используют подход, навеянный GitLab CI/CD: есть специальные машины-воркеры, выполняющие определенные задачи. Многие шины сейчас используют такой же подход. По кластеру разворачиваются слушатели, которые выполняют поставленную интеграцию. Они могут слушать любой триггер: почту, брокер, HTTP-запрос — всё, что обычно нужно для интеграции. Это может быть запущено на любой машине кластера, выполниться и завершить работу. Важно, что простой слушатель потребляет мало ресурсов, и горизонтальное масштабирование происходит без проблем", — объясняет он.

«Второй момент: если используется Service Mesh с огромным количеством микросервисов, построенных для интеграции систем А и Б, возникает проблема — при большом количестве интеграций (более ста) становится сложно их документировать и вести каталог. В случае с шиной есть возможность просматривать все интеграции обзорно, сверху. Плюс обычно в шинах есть полнотекстовый поиск по всем интеграциям, система тегов — найти информацию намного проще, чем если это был бы код где-то в Git, к которому, возможно, нет доступа или сотрудник, который его писал, уже уволился. Теряем сотрудников — информация исчезает из голов, максимум остается где-то в Confluence», — предупреждает Иванов о реальной проблеме.

У всех есть шина, просто она называется Kafka

Роман Кучерский вносит важное уточнение о том, что происходит в реальных проектах:

«Если мы говорим про ESB в каноническом понимании — это конкретный набор решений, будь то продукты Oracle или Apache. Но если говорить о современной реальности, не будем лукавить: так или иначе у каждого есть самописная корпоративная шина, просто обычно она строится поверх какой-нибудь Kafka. По сути, Kafka в этом случае выполняет роль шины — многие так её используют», — раскрывает карты эксперт.

«Здесь мы возвращаемся к вопросу внутренних и внешних интеграций. Если мы говорим про подконтрольные системы, про свои внутренние сервисы — это уже больше про Service Mesh, про культуру разработки, документацию, стандартизацию на уровне кода. Это шаблоны проектов, шаблоны поставки, вплоть до организации репозиториев в системе контроля версий, которые упрощают поиск нужных проектов. Это стандарты логирования, трейсинг ID и всякие инструменты, которые в децентрализованной системе помогают выполнять функции централизованного поиска проблем. По сути, решения другие, архитектурный подход другой, но так или иначе ищутся способы достичь централизации даже в децентрализованной системе», — детализирует Кучерский.

Микросервисы дают свободу экспериментов

Антон Новожилов подчеркивает еще одно преимущество распределенных архитектур — возможность безопасно тестировать новые подходы:

«Если мы говорим про микросервисную архитектуру — она дает определенную свободу. Вы можете улучшить один сервис, посмотреть, как сработало улучшение, какие показатели увеличились, провести нагрузочное тестирование. Увидите, что решение, примененное в этом микросервисе, сработало — и дальше уже идете внедрять его в другие микросервисы вашего Service Mesh", — объясняет эксперт.

Дмитрий Гаврин рассказывает, как они выбирали инструменты для интеграционной платформы:

«В целом это разные инструменты по своей сути. Когда мы для своей интеграционной платформы выбирали те или иные инструменты, по сути, Kafka и NiFi делают одно и то же — есть две системы, и нужно перенести данные между ними. И мы даже долго думали, в чем разница», — признается Гаврин.

«Оказалось, разница именно в задачах, которые решает тот или иной инструмент. Когда мы начали нагружать Kafka и NiFi — это было несколько лет назад, современные данные могут отличаться — у нас получилось, что Kafka идеальна для большого количества небольших сообщений: выдерживает миллионы в минуту. NiFi, наоборот, на таких объемах начинает подтормаживать. Зато NiFi очень крут, если нужно перекачать, условно, терабайт данных из одной системы в другую — единомоментно «ливануть»", — детализирует эксперт.

Kafka — это не брокер, это стример

Гаврин указывает на важное различие: «Обратите внимание: сам вопрос про брокер сообщений. Я Kafka больше предпочитаю называть даже стримером, потому что там без дополнительной настройки нет гарантии доставки. В целом Kafka — это стример сообщений, который может передать множество небольших сообщений в единицу времени, причем даже без гарантии доставки, зато быстро. NiFi может перелить много данных одномоментно», — уточняет специалист.

Чтобы объяснить разницу между стримером и настоящим брокером, Гаврин использует яркую метафору: "Могу еще рассказать про привычные брокеры сообщений, если брать RabbitMQ. По сути, чем он от Kafka отличается? Kafka — это стример, широковещательная рассылка, как смотреть сериал на Netflix: кадры получаются, если один кадр где-то потерялся — не страшно, сериал смотрим дальше. Но если, например, в банке проходит операция по погашению кредита, и она где-то потерялась в недрах Kafka, потому что нет подтверждения, нет гарантии доставки — это проблема. Поэтому мы используем в нашей практике переработанный Apache Artemis, который взяли под контроль. Гарантия доставки нужна в части интеграции», — объясняет Гаврин.

Юрий Иванов не согласен с утверждением, что у Kafka нет гарантии доставки. 

«Единственное, я бы очень сильно не согласился, что у Kafka нет гарантии доставки, потому что есть manual commit, который позволяет только в нужный момент времени перенести счетчик оффсета на следующее место. Поэтому очень бы не согласился. Если у Kafka нет гарантии доставки, то можно говорить про любого другого брокера — в случае с RabbitMQ, с Artemis, с их durable topics и так далее, — что у них тоже не может быть гарантии доставки. Поэтому я хотел просто не согласиться с этим и поставить это под вопрос», — возражает Иванов.

Open source vs проприетарка: что надежнее для интеграций

Последний вопрос, который неизбежно возникает при выборе инструментов для интеграции: стоит ли доверять open source решениям или лучше заплатить за коммерческий продукт? 

Юрий Иванов начинает с очевидного плюса open source проектов: «Что касается open source — он довольно развит в том плане, что большое количество людей просмотрело этот код, туда довольно сложно внести коммиты и так далее. Это лучше, чем самопис, который будет сделан за пару дней. Это будет явно лучше», — признает Иванов.

Но дальше идут нюансы: «В случае с open source редкие ситуации, когда он хорошо протестирован именно для определенного кейса. В случае с проприетарным мы, во-первых, больше уделяем внимание разработке, потому что это уже разработка за деньги», — уточняет эксперт.

Иванов приводит показательный пример проблемы со стабильностью даже в популярных библиотеках: «Есть пример с некоторыми Apache-библиотеками open source, которые позволяют в целом всё делать, но у них есть огромное количество проблем со стабильностью. Даже если мы будем говорить про Quartz Timers — самый простой пример. То, что Quartz-таймер должен всегда работать, к сожалению, такое не случается. Даже если мы скажем, что он должен контролироваться, что он должен перезапускаться, — бывает такое, что он не запускается и может отключиться», — делится болью Иванов.

«Поэтому проприетарные решения позволяют, в частности, иногда закрывать эти проблемы с помощью других подходов — дополнительного контроля, что всё запущено, лишний раз промониторить, пингануть этот сервис. Это что касается таймера — простейший кейс, который, мне кажется, уже лет 50 актуален, а open source Quartz до сих пор не является идеальным таймером, который будет 100% работать и никогда не завершится», — резюмирует специалист.

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

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

Деньги решают: когда можно купить решение проблемы

Евгений Шишкин озвучивает главное преимущество коммерческих продуктов — возможность влиять на разработку:

«У проприетарных решений очень хорошая поддержка, по идее, должна быть, потому что они за это деньги получают. И если нам чего-то не хватает, мы можем пойти к ним, сказать: «Вот вам feature request, пожалуйста, сделайте, мы готовы дать столько-то денег», — и вам это сделают. В случае с open source, если что-то не работает, идешь на GitHub, качаешь, пушишь, его принимают в пулл-реквест, либо выкачиваешь к себе и локально поднимаешь. То есть тут определенные проблемы есть. Поэтому если есть деньги на проприетарное решение и вы готовы с этим жить — почему бы нет?»  — рассуждает Шишкин.

Составьте таблицу требований — и всё станет ясно

Дмитрий Гаврин подводит итог обсуждения прагматичным советом: «Нужно просто при выборе open source или проприетарного сервиса составить таблицу с функциональными и нефункциональными требованиями. То есть что, собственно, нужно? Нужна ли возможность доработки собственными силами или, наоборот, нужна вендорская поддержка? Исходя из этого, принимать решение, потому что всё зависит от задач", — говорит он.

Эксперт приводит пример, когда выбор был предопределен задачей, а не идеологией:

«Тот же самый Netflix, который построил систему на Kafka, — я уверен, что он бы построил на каком-нибудь Oracle или IBM, но тогда не было решений, которые могли бы решить их задачу физически. Поэтому построили на Kafka. То есть иногда open source может быть надежнее для решения интеграционных задач, так же как и проприетарный сервис — если нужна вендорская поддержка либо стабильная работа», — заключает эксперт.

А как вы управляете интеграциями в своих проектах? С какими проблемами сталкиваетесь чаще всего? Делитесь опытом в комментариях — будет интересно обсудить.

Что почитать по теме:

«Enterprise Integration Patterns» (Шаблоны интеграции корпоративных приложений)

Авторы: Грегор Хоп (Gregor Hohpe) и Бобби Вулф (Bobby Woolf)

«Designing Data-Intensive Applications» (Высоконагруженные приложения. Программирование, масштабирование, поддержка)

Автор: Мартин Клеппман (Martin Kleppmann)

«Working Effectively with Legacy Code» (Эффективная работа с унаследованным кодом)

Автор: Майкл Физерс (Michael Feathers)

«Building Microservices» (Создание микросервисов)

Автор: Сэм Ньюман (Sam Newman)

«Software Architecture: The Hard Parts» (Современный подход к программной архитектуре: сложные компромиссы)

Авторы: Нил Форд (Neal Ford), Марк Ричардс (Mark Richards) и др.