Привет, Хабр!
На связи команда «Диасофт». У нас в линейке есть оба слоя, о которых пойдет речь в названии: брокер сообщений Digital Q.MessageBroker на базе Kafka и интеграционная платформа Digital Q.Integration, внутри которой этот брокер работает. Так что в этой теме мы не сторонние наблюдатели – и нам одинаково хорошо знакомы обе стороны спора. Текст мы готовили вместе с руководителями продуктов: Ильей Виссарионовым и Виктором Овчинниковым. Кстати, оба продукта имеют бесплатные дистрибутивы, которые можно скачать на нашем портале (здесь и здесь).
Рано или поздно любому вендору такой платформы задают вполне резонный вопрос: если у компании уже есть Kafka, API gateway, мониторинг и сильная команда разработки, зачем ей вообще отдельная интеграционная платформа? Ведь почти все можно сделать обычным кодом. Наш ответ здесь простой: да, можно. Более того, под этим тезисом мы готовы подписаться.
Чтобы дальше не спорить о терминах, сначала разделим две вещи. Брокер сообщений - это Kafka, RabbitMQ или Artemis: транспорт, который принимает данные от одной системы и передает другой. Kafka ближе к распределенному журналу, RabbitMQ - к очередям с маршрутизацией, но в обоих случаях брокеру безразлично, что именно лежит внутри сообщения.
Вся содержательная работа происходит вокруг него: XML из старой учетной системы нужно превратить в JSON для нового сервиса, поля с разными именами сопоставить, справочники свести, сообщение повторно отправить после сбоя, а затем еще проверить, что заказ действительно появился на складе, а не просто успешно покинул топик. Этот слой можно написать самостоятельно - тогда получится собственное решение. Можно взять готовым - тогда это интеграционная платформа. Лет пятнадцать назад такой класс систем чаще называли ESB, или интеграционной шиной.
Поэтому спор на самом деле идет не о Kafka и не о брокерах в целом. Он идет о слое вокруг них: писать его самим или покупать готовый. И в формулировке «у нас есть сильная команда, мы все сделаем сами» обычно скрываются три важных условия: команда действительно есть, она компетентна и у нее есть опыт не только разработки интеграций, но и их многолетней эксплуатации.
Если выполняются все три условия, готовая платформа действительно может оказаться лишней. Если нет хотя бы одного, собственный интеграционный слой довольно быстро начинает обходиться дороже, чем казалось в начале. Именно об этом и пойдет речь - в том числе о случаях, когда вендорская платформа честно проигрывает самописному решению.
Где вы правы
С сильной командой спор действительно можно закончить довольно быстро: интеграционный слой она соберет сама. Kafka бесплатна, Apache Camel бесплатен, Spring Integration тоже никто не прячет за лицензией. Документация открыта, готовых библиотек хватает, а примеров на GitHub столько, что изучить их все получится разве что к следующей смене технологического стека.
Никакой тайной технологии внутри интеграционной платформы нет. Ее основные механизмы можно написать самостоятельно, и говорим это без вендорской скромности: сами разрабатываем и брокер, и платформу, поэтому хорошо знаем, как такие системы устроены изнутри. Более того, путь от идеи связать две системы до собственной внутренней платформы настолько типичен, что его можно почти раскладывать по этапам.
Сначала все выглядит предельно просто. Один сервис пишет сообщение в Kafka, второй его читает, формат обсудили в рабочем чате, топик назвали достаточно понятно, на тестовом стенде сообщение доехало. Задачу закрыли и пошли дальше. Проблема в том, что дальше почти всегда появляется третья система, потом четвертая, а вместе с ними выясняется, что сообщения иногда не доезжают, иногда приезжают дважды, иногда приходят в неправильном порядке, а иногда технически все работает идеально, только данные на другой стороне уже никому не нужны.
Тогда появляются retry, dead letter queue, логирование, трассировка, метрики, контроль схем и нормальный мониторинг. Еще недавно интеграция состояла из нескольких обработчиков, а теперь, чтобы разобраться куда делось сообщение, уже нужен отдельный дашборд. Это не признак плохой архитектуры, а естественная цена роста: чем больше систем связано между собой, тем больше инфраструктуры требуется вокруг самой передачи данных.
Где-то к десятой интеграции команда обычно начинает унифицировать накопившееся “хозяйство”. Появляется общий формат сообщения, правила именования топиков, единый подход к обработке ошибок, библиотека для логирования и повторных попыток. Через год внутри обнаруживаются сериализация, авторизация, работа со справочниками, несколько адаптеров, куски бизнес-логики и пара методов, которые никто не решается переписывать, потому что последний человек, понимавший их назначение, сменил работу еще прошлой весной.
В этот момент компания может по-прежнему считать, что никакой собственной интеграционной платформы у нее нет. Формально так и есть: отдельного продукта никто не запускал, презентацию с архитектурой не делал и красивого названия не придумал. На практике основные функции платформы уже существуют, просто исторически выросли из набора общих библиотек, соглашений и сервисов.
И в этом нет ничего неправильного. Хорошая инженерная команда вполне способна построить сильное внутреннее решение, причем в одном важном отношении оно почти неизбежно окажется лучше готового продукта: его делают под конкретную компанию, ее системы, архитектуру, справочники, процессы и накопленные за годы особенности. Включая те решения, происхождение которых уже никто не помнит, но на архитектурных встречах их принято дипломатично описывать словами «так исторически сложилось».
Вендорский продукт находится в другой позиции. Его приходится проектировать так, чтобы он работал не в одной организации, а в десятках или сотнях разных инфраструктур. Поэтому собственное решение действительно можно точнее подогнать под конкретный ландшафт: учесть внутренние форматы, особенности безопасности, существующий мониторинг, привычные инструменты разработки и даже организационную структуру команды. Для крупной компании с сильной инженерной культурой это серьезный аргумент в пользу собственной разработки, и отмахиваться от него было бы нечестно.
Есть и другой аргумент: платформа не отменяет саму работу по интеграции. Кто-то все равно должен понять, какие данные передавать, спроектировать маршрут, описать преобразования и сопоставить справочники двух систем. Причем настоящая сложность часто прячется не в Kafka, HTTP или очередях, а в выяснении того, почему в одной системе страна хранится по ISO-коду, в другой по внутреннему идентификатору, а в третьей Беларусь записана как Белоруссия.
Платформа может забрать на себя транспорт, мониторинг, повторные попытки, обработку ошибок, версионирование и другие типовые механизмы. Но она не знает бизнес-контекст и не угадает сама, что customer_id из одной системы соответствует clientCode из другой, а status=3 на самом деле означает «договор закрыт», потому что так договорились разработчики системы пятнадцать лет назад. Для этого по-прежнему нужны люди, которые понимают обе стороны интеграции и могут отличить техническое соответствие полей от смыслового.
Поэтому обещание «мы поставим платформу и больше не будем заниматься интеграциями» примерно так же реалистично, как надежда купить Kubernetes и перестать заниматься эксплуатацией. Инструмент может убрать значительную часть рутины, стандартизировать повторяющиеся операции и сделать происходящее наблюдаемым, но думать за команду он не начнет.
Наконец, есть компании, которым действительно рациональнее строить такой слой самим. Если в IT работают сотни специалистов, существует отдельная архитектурная функция, есть сильная платформенная команда и бюджет не только на разработку, но и на последующее сопровождение внутренней инфраструктуры, собственная интеграционная платформа может быть вполне оправданным решением. В таких организациях обычно находятся и люди, которые помнят, почему определенный топик называется именно так, а особенно ценные специалисты еще и знают, что произойдет, если попытаться его переименовать.
Если ваша компания именно такая и у вас выполняются все три условия из вступления, значительная часть дальнейшего текста действительно будет посвящена проблемам, которых у вас может не быть. Отдельно разберем, когда покупать интеграционную платформу действительно нет особого смысла.
Тот же open source, другая ответственность
Отсюда возникает следующий вопрос. Многие коммерческие платформы сами собраны на open source. Почему, когда компания берет Kafka, Camel и другие открытые компоненты, это называют самописом, а когда вендор собирает из них продукт, получается промышленная платформа?
Ответ довольно простой: внутри действительно во многом тот же open source. Писать собственный брокер сообщений сегодня мало кому придет в голову. Мы и сами пошли этим путем: Digital Q.MessageBroker построен на базе Kafka, а не написан с нуля. Берут Kafka, RabbitMQ или Artemis, библиотеки для маршрутизации и преобразований, что-то дорабатывают, что-то форкают, а затем связывают все в единое решение. Разрабатывать собственный брокер ради передачи заказов на склад - примерно как выплавлять сталь, чтобы собрать велосипед.
Разница не столько в компонентах, сколько в ответственности за всю конструкцию. Если вы собираете решение сами, то сами отвечаете за сборку, совместимость версий, обновления, тестирование и поведение десятков библиотек в вашей инфраструктуре. С вашей Java, вашими сертификатами, сетевыми политиками и внутренними сервисами,. Сильная команда с этим справится, но с этого момента это ее постоянная работа.
Особенно хорошо это видно на обновлениях. Kafka 4.0 окончательно отказалась от ZooKeeper, поэтому старый кластер сначала нужно перевести на KRaft и только потом двигаться дальше. Camel 4 перешел с javax на jakarta и потребовал более новую Java, из-за чего часть старых компонентов пришлось дорабатывать. Каждое изменение само по себе нормально и описано в документации. Проблема в том, что такие изменения происходят постоянно и сразу в нескольких частях стека. Кто-то должен следить за ними, проверять совместимость и выбирать момент обновления так, чтобы не положить обмен с бухгалтерией в последний день квартала.
Есть и другая часть работы, которую архитектурные схемы обычно скрывают. Брокер умеет доставлять сообщения, но не понимает их смысла. Сообщение может успешно попасть в топик, быть прочитано адаптером и все равно не дойти до целевой системы: API отказал из-за пустого поля, ошибка ушла в лог, offset закоммичен, lag нулевой. Для Kafka все прекрасно. Для бизнеса заказ потерян.
Поэтому вокруг брокера неизбежно появляется еще один слой: валидация, преобразования, повторы, dead letter queue, обработка ошибок и мониторинг уже не сообщений, а бизнес-событий. Ничего принципиально сложного в этом нет, но это много кода, который придется сопровождать годами.
Когда ту же работу делает вендор, он превращает ее в отдельное производство: собирает компоненты, проверяет сочетания версий, тестирует типовые сценарии и выпускает более или менее законченное решение. Полностью закрытой коробки в интеграции все равно не бывает - маршруты, преобразования и справочники придется настраивать под конкретную компанию. Но базовая связка уже проверена до того, как попала в ваш продакшен.
Отсюда и главное различие. Готовая платформа рассчитана на многих, поэтому в ней неизбежно будут лишние для вас функции и ограничения, которых не было бы в собственном решении. Самопис можно подогнать под компанию почти идеально. Но проверять, обновлять и сопровождать его придется только вам. Платформа устроена наоборот: она менее индивидуальна, зато часть этой ответственности вы покупаете вместе с продуктом.
Когда команды нет
Выше сформулировали три условия, при которых собственный интеграционный слой действительно имеет смысл: команда есть, она достаточно сильная и уже знает, что такое эксплуатация интеграций в продакшене. Проблема в том, что в реальности эти три условия совпадают далеко не всегда.
Спор о платформах обычно ведут люди из компаний, где первое условие уже выполнено. Это естественно: именно они пишут технические статьи, выступают на конференциях и спорят в комментариях. Но рынок не состоит только из корпораций с сотнями специалистов в IT. Есть огромное количество организаций, где вся IT-служба - это несколько десятков человек, которые одновременно поддерживают рабочие места, почту, учетную систему, сеть в филиалах и тот самый принтер, который бухгалтерия просит починить еще с утра.
В такой компании собственные адаптеры никто не будет писать не потому, что разработчики «не доросли» до Kafka. У компании просто нет задачи содержать отдельную инженерную команду ради интеграционного слоя. Ей нужно решение, которое дешевле купить и сопровождать, чем сначала разработать, а потом годами поддерживать своими силами. Совет собрать все самим из бесплатных компонентов здесь звучит примерно как предложение самостоятельно собрать служебный автомобиль, потому что двигатель, коробку передач и колеса можно купить отдельно. Формально все верно. Не хватает только людей, времени и того, кто будет отвечать, если утром машина не заведется.
Со вторым условием, компетентностью, ситуация сложнее. Даже в компаниях, где активно пишут код, инженерная культура бывает очень разной. Мы как вендор регулярно видим, как вокруг вполне промышленных систем со временем нарастает слой собственных доработок: обработчики, скрипты выгрузки, временные обходные решения, написанные когда-то под срочную задачу. Иногда через несколько лет выясняется, что исходников у части этого кода уже нет, автор давно ушел, а о системе версий вспоминают только теоретически. Версия при этом, конечно, существует - одна, и она работает в продакшене.
История вполне понятная: задача горела, решение написали, бизнес заработал, потом появились другие приоритеты. Код продолжает выполнять свою функцию, а трогать его никто не хочет, потому что никто уже точно не знает, что сломается следом. Но в этом случае выбор стоит вовсе не между прекрасным внутренним фреймворком и готовой платформой. Он стоит между платформой и кодом, который компания постепенно перестала контролировать.
Третье условие - опыт эксплуатации - еще коварнее, потому что его может не хватать даже сильной команде. Хороший разработчик без особых проблем напишет адаптер. Но знать, что произойдет с консьюмерами при ребалансировке группы, как поведет себя обмен после шестичасовой недоступности получателя и какой retention потребуется, чтобы через неделю после инцидента восстановить цепочку событий, - это уже другой тип знания. Его обычно получают не из документации, а из нескольких ночных работ с продакшеном.
Именно поэтому опыт эксплуатации так трудно заменить наймом просто хороших разработчиков. Его набирают на реальных отказах, потерянных сообщениях, неудачных обновлениях и ситуациях, когда технически все отмечено зеленым, а бизнес уже звонит и спрашивает, куда пропали заказы. Платит за это обучение та компания, на инфраструктуре которой все происходит.
Наконец, есть организации, которые сознательно не хотят заниматься собственной разработкой интеграций. У кого-то так исторически устроено IT, кто-то не хочет создавать еще одну внутреннюю платформенную команду, а кто-то посчитал, что покупать и сопровождать готовое решение дешевле, чем держать специалистов нужного профиля в штате. С этим расчетом можно спорить в конкретном проекте, но сам по себе он ничем не хуже решения другой компании написать все самостоятельно.
Такие организации, конечно, не составляют весь рынок. Но их достаточно много, и именно они часто выпадают из дискуссии в духе «зачем вам платформа, если есть Kafka». Kafka у них вполне может быть. А вот людей, которые следующие пять лет будут строить вокруг нее собственную платформу и отвечать за ее эксплуатацию, - уже нет.
Сообщество, SLA и кто исчезнет первым
Даже если команда есть, компетенций хватает, а эксплуатационный опыт уже набран, остается еще один вопрос: кто отвечает, когда что-то сломалось.
Самый частый контраргумент здесь звучит так: open source бесплатен, а на любой вопрос есть сообщество. С первой частью спорить бессмысленно - лицензия Kafka действительно ничего не стоит. Но цена лицензии и стоимость владения в интеграции связаны слабо, и особенно хорошо это видно именно в момент сбоя.
В open source-сообществе можно получить полезные ответы. Вопрос только в том, когда они появятся и можно ли будет на них опереться. Спросите, например, про exactly-once между Kafka и внешней базой, и вполне можете получить несколько обстоятельных решений, часть из которых противоречат друг другу, а одно заканчивается бессмертным инженерным аргументом: «у нас работает». Это не недостаток сообщества. Оно просто ничего вам не должно.
А бизнесу иногда нужен не самый красивый ответ, а гарантированный ответ к определенному времени. Если в последний день месяца перестал работать обмен с банком, ценность экспертизы быстро начинает измеряться часами. В этот момент важно, чтобы кто-то был обязан подключиться к решению проблемы в срок, прописанный в SLA, и нес ответственность за нарушение этого срока.
Для части организаций это не вопрос предпочтений. Внутренние правила требуют, чтобы критичный стек был закрыт поддержкой. Ее может обеспечивать собственная команда, системный интегратор или вендор, но опора в данном случае на open source просто не проходит требования эксплуатации. Бесплатная лицензия здесь мало что меняет.
После этого обычно возникает зеркальный вопрос: а что, если исчезнет сам вендор? Такой риск есть, и отрицать его было бы странно. Но у собственного решения риск тоже существует, просто выглядит иначе. Вместо зависимости от компании появляется зависимость от людей, которые знают, почему обмен с бухгалтерией устроен именно так и что сломается, если поменять вот этот конфиг. Ключевой специалист может уйти, знания могут не попасть в документацию, а код останется.
Это не означает, что вендор надежнее по определению. Это означает, что риски разные. В одном случае вы зависите от поставщика и его продукта, в другом - от способности своей команды сохранять знания и сопровождать систему годами.
Есть и еще одна важная деталь. Если поддержка платформы заканчивается, сама платформа обычно не исчезает. Она продолжает работать в том состоянии, в котором осталась, только без обновлений и гарантированной помощи. Через несколько лет это тоже может превратиться в легаси, просто с несколько более понятной родословной.
Где зависимость от вендора действительно критична
Выбирая платформу, вы действительно становитесь зависимы от ее поставщика. Если через несколько лет перестанет устраивать цена, политика лицензирования или направление развития продукта, выход может оказаться долгим и дорогим. Десятки или сотни интеграций, описанных в терминах конкретной платформы, придется переносить, а иногда и переписывать.
Эту проблему нельзя убрать обещаниями отсутствия vendor lock-in. Стоимость выхода можно снизить хорошей архитектурой, открытыми форматами и стандартными компонентами, но обнулить ее нельзя. Если вендор утверждает обратное, к такому обещанию стоит относиться осторожно.
Поэтому до покупки стоит выяснить, в каком виде хранятся описания интеграций, можно ли выгрузить их в читаемом формате и насколько они привязаны к конкретному продукту. Важно понять, используется ли внутри стандартный брокер, к которому при необходимости можно подключиться напрямую, и что произойдет с работающими интеграциями после прекращения поддержки или лицензирования. Если на такие вопросы отвечают уклончиво, это важный сигнал.
Последние годы дали особенно наглядный пример того, насколько эта зависимость может быть шире самой технологии. Многие российские организации были вынуждены менять зарубежное ПО из-за регуляторных требований, санкционных ограничений, прекращения поставок и поддержки. При этом старый продукт мог полностью устраивать компанию технически. Переезжать все равно приходилось, причем часто не на собственную разработку, а к другому поставщику.
Для любого вендора это неудобный пример. Он показывает, что зависимость от поставщика включает обстоятельства, которые не контролирует ни заказчик, ни сам поставщик. Хороший продукт сам по себе от такого риска не защищает. Стоит честно признать и обратное: часть рынка российские разработчики получили не потому, что сделали продукт лучше зарубежного аналога, а потому, что прежний поставщик стал недоступен.
Отсюда следует не самый приятный для вендора вывод: отказ от платформы иногда совершенно рационален, и дело не обязательно в цене. Если у компании сильная команда, большая часть интеграций связывает собственные системы, а недавний вынужденный переезд научил ее не завязывать критичные процессы на одного поставщика, решение оставить интеграционный слой внутри компании выглядит вполне разумно.
В такой ситуации платформа может решить проблему, которой у компании уже нет, и одновременно создать зависимость, от которой она только что избавилась.
Когда «коробка» действительно лишняя
Если резюмировать все сказанное выше, ответ получается довольно конкретным. Платформа поверх брокера не нужна компании, у которой выполняются те самые условия из вступления, причем проверить их можно достаточно просто.
Команда есть, если интеграциями занимаются отдельные специалисты, а не люди, которые между двумя релизами успевают еще починить почту и сеть в филиале. Компетентность тоже видна довольно быстро: исходники адаптеров лежат в репозитории, изменения фиксируются, сборка и выкладка автоматизированы, а устройство обмена может объяснить не только его автор.
С опытом эксплуатации все еще проще. Если команда уже разбирала ребалансировки, восстанавливала обмен после многочасовой недоступности получателя, искала потерянные сообщения и знает, сколько стоит ошибка в retention, такой опыт у нее есть. Если все это пока встречалось только в документации и на конференционных слайдах, его еще предстоит получить на собственном продакшене.
Есть и более простой случай - интеграции между системами, которые компания разрабатывает сама. Когда обе стороны обмена находятся под вашим контролем, можно договориться о формате, правилах версионирования и поведении при ошибках. Тогда сообщение действительно часто достаточно положить в топик и забрать на другой стороне. Настоящая сложность начинается там, где появляются чужие продукты, внешние сервисы и старые системы, которые живут по своим правилам. Пока таких систем немного, отдельный адаптер для каждой вполне может оказаться дешевле любой платформы.
Платформа вряд ли нужна и крупной компании, у которой собственный интеграционный слой уже вырос и исправно работает. Выбрасывать решение, годами подогнанное под конкретную инфраструктуру, ради более универсальной “коробки” чаще всего бессмысленно. У такой компании другая проблема - сохранить знания о собственной платформе, когда меняются люди. Это уже вопрос документации, процессов и архитектурной дисциплины, а не выбора вендора.
Наконец, есть организации, которые сознательно полагаются на собственную команду и open source-сообщество и не требуют закрывать каждый компонент стека договором поддержки. Это тоже нормальная инженерная стратегия. Она требует высокой квалификации и дисциплины, но позволяет не платить за лицензии и внешнюю поддержку.
Во всех остальных случаях имеет смысл хотя бы просчитать оба варианта. Причем сравнивать нужно не стоимость лицензии с нулем, а полную стоимость владения на несколько лет вперед. У собственного решения это зарплаты разработчиков и эксплуатации, дежурства, обновления, разбор инцидентов и риск потери знаний. У платформы - лицензия, поддержка, обучение и стоимость будущего выхода. Иногда после такого расчета платформа действительно оказывается дороже. Тогда ее и не нужно покупать. Главное, чтобы это выяснилось из расчета, а не из привычного «мы всегда писали сами».
Все решает слово «если»
Мы по-прежнему готовы подписаться под тезисом, с которого начали: если у компании есть Kafka, API gateway, мониторинг и сильная команда, отдельная интеграционная платформа ей не нужна. Просто теперь видно, что самое важное слово здесь - «если».
Команда должна не просто существовать, а уметь сопровождать интеграции годами. У нее должен быть опыт не только написания кода, но и эксплуатации, инцидентов и обновлений. И есть еще одно условие, которое обычно вообще не проговаривают: у этой команды должно быть время заниматься интеграционным слоем вместо задач, которые напрямую относятся к продукту компании.
Отказываться от сказанного выше тоже нет смысла. Готовая платформа удобна для многих и не идеальна почти ни для кого. Вендор, который обещает обратное, скорее продает презентацию, чем технологию. Но реальный выбор обычно не стоит между идеальным своим решением и несовершенным чужим. Он стоит между готовым продуктом со своими ограничениями и собственной системой, которую придется развивать, тестировать и сопровождать самостоятельно.
И здесь появляется, пожалуй, главное различие. Брокер отвечает за доставку сообщения. Платформа в значительной степени покупается ради того, чтобы вместе с технологией появилась формальная ответственность: если обмен сломался, есть тот, кто обязан разобраться, и есть срок, за который он должен это сделать.
Если все это уже есть внутри компании, отдельная платформа действительно может быть лишней. Если нет, то платите вы не столько за код, сколько за возможность не строить еще одну платформенную компетенцию своими силами.
Предлагаем сравнить наши выводы с реальностью. Сколько интеграций в вашей компании сегодня понимает ровно один человек? И у скольких из них исходники действительно лежат в репозитории, а не где-то в его личной папке с названием final_v2_working?
