Привет, Хабр! Меня зовут Виктор Овчинников, я руковожу продуктовым направлением «Интеграционная платформа» в «Диасофт». Той самой Digital Q.Integration, которую вы имеете полное право не покупать.
Под каждой моей статьей появляется один и тот же комментарий. Слова разные, смысл один: зачем вообще нужна интеграционная платформа, если есть Kafka, брокер сообщений? Один сервис положил сообщение, второй забрал. В чем, собственно, проблема?
Раньше я отвечал в комментариях каждому, потом понял, что проще ответить сразу всем. И заодно признать неприятное: в изрядной части случаев этот комментарий справедлив. Хорошая новость в том, что за годы разговоров с коллегами из других компаний у меня накопилась приличная коллекция возражений против меня самого. Это архитекторы, аналитики, руководители разработки — люди, которые платформу не продают. Часть этих разговоров я тут перескажу, кое‑где даже дословно.
Дальше будет про то, где проходит граница между брокером и платформой, почему ее так трудно нащупать, почему настоящая причина «самописа» вообще не техническая и что во всей этой истории изменил ИИ. По последнему пункту спойлер: ничего хорошего.
Пока оба конца провода ваши, вы правы
Начну с той части, где спорить не с чем.
Если вы пишете свои сервисы сами, держите оба конца контракта и сами решаете, когда его менять, брокера вам хватит с запасом. Продюсер кладет сообщение в формате, который сам же и придумал, консьюмер ждет ровно этот формат, оба лежат в соседних папках одного репозитория и «едут» одним пайплайном. Это работает. Никакого дополнительного слоя сюда добавлять не надо, и человек, который пишет мне про Kafka, обычно живет именно в такой реальности. Хорошая реальность, я за него рад.
Ломается она не тогда, когда систем становится много. Она ломается, когда в ландшафте заводится система, которой управляете не вы. Закупили вендорскую «коробку», и ее надо встроить в процесс. Соседнее подразделение выкатило свой сервис, у него свой релизный цикл и свой архитектор, и в его планах вас нет. Достался в наследство обмен, автор которого уволился позапрошлой весной, а в коде висит комментарий «временно, потом перепишем» и дата, на которую страшно смотреть. Ни одна из этих систем под ваш контракт не подстроится. Либо вы переделываете свое под чужое, либо где‑то посередине заводится трансформация, маппинг атрибутов и сведение справочников. Вот этого Kafka не делает и, если честно, не должна.
Так что точка невозврата — не в количестве систем. Она в том, какой долей контрактов вы на самом деле управляете.
Я как‑то спорил ровно об этом с Иваном Ивановым, он возглавляет компанию‑разработчика ПО «Апрель Инновации». Иван предложил мерить не связи, а возраст ИТ‑хозяйства: старое легаси обычно достается в нагрузку, и оставить его как есть выходит дороже, чем поменять. Порог он назвал привычный: до десятка систем адаптеры дают гибкость, и соединять их напрямую проще, а дальше уже приходится договариваться о контрактах основательно и поддерживать все централизованно.
С десятком я тогда не согласился и сейчас не соглашусь. Шесть систем, из которых четыре чужие и меняются без предупреждения, просят об интеграционном слое куда громче, чем полтора десятка сервисов одной команды, годами живущих на прямых вызовах и не знающих горя.
Более аргументированное возражение я услышал от Михаила Воронкова, он руководит разработкой 1С‑приложений в «Велес Рисерч». Мы разбирали, почему в 1С половина обменов живет вообще без внешней обвязки: там полно встроенных механизмов, придуманных еще разработчиками платформы, и если системы схожи, ничего выдумывать не надо. А потом Михаил добавил фразу, которую я с тех пор таскаю по всем встречам: «У нас всего три системы, а обмены между ними настолько сложные и форматы настолько разные, что простыми обработчиками это не реализовать».
Три системы, и уже больно. Вот вам вся многолетняя дискуссия про «сколько систем» в одном предложении.
Сам я давно считаю иначе. Беру список интерфейсов, вычеркиваю те, где могу поменять обе стороны, и смотрю на остаток. Если чужих контрактов два или три и трогают их раз в год, живите как жили, вы в выигрыше. Если их восемь и каждый месяц кто‑нибудь что‑нибудь двигает, интеграционный слой у вас уже есть. Просто он размазан по коду ваших сервисов, называется вроде «ну там утилитки», и владельца у него нет.
Kafka никому ничего не обещала
Отдельный сюжет, который я встречаю с завидным постоянством: брокер выбирают раньше, чем формулируют задачу. Сначала на схеме появляется Kafka, потому что с ней не стыдно прийти на архитектурный комитет, а потом под нее подгоняют обоснование. Разницу между Kafka и Rabbit объясняют уже постфактум, если вообще объясняют. У Воронкова, кстати, это выходит короче, чем в половине обзорных статей про брокеры сообщений: Kafka — про хранение потока, большой лог сообщений, где важны объем и возможность перечитать историю, а Rabbit — про сложную маршрутизацию, когда в каждую очередь надо положить что‑то конкретное под конкретного клиента, базу или субъекта.
А самое неприятное для меня сформулировал Андрей Кустов, ведущий архитектор BIV. Мы с ним спорили как раз о том, нужна ли поверх брокера отдельная сущность, и он закрыл вопрос быстрее, чем я успел выложить свои аргументы. Трансформация, роутинг, логирование действий, персистентность — это задачи ESB. Ни Kafka, ни Rabbit ничего такого не делают: нормального роутинга там нет, нормальной трансформации тоже. Значит, обвязку вы получите в любом случае, вопрос только в том, чьими руками она будет написана.
Обвязка. Запомните это слово.
Начинается все всегда одинаково и почти всегда весело. Сначала выясняется, что поставщик выкатил несовместимое изменение схемы в пятницу вечером. Почему в пятницу? Потому что в распределенных системах есть вещи фундаментальнее CAP‑теоремы: если релиз способен сломать интеграцию, он обязательно попадет в прод примерно в 18:47.
Значит, нужна политика совместимости и умение прожить с двумя версиями контракта одновременно. Гарантированная доставка сообщений на уровне брокера — это не то же самое, что гарантия на уровне бизнеса. Потом обнаруживается, что exactly‑once внутри брокера и exactly‑once в вашей предметной области — это два разных exactly‑once, и если сообщение приводит к списанию денег, то честный ретрай транспорта превращается в честную двойную проводку. Появляются ключ идемпотентности и табличка обработанных операций, которую вы будете чистить руками еще полгода.
Потом появляются ретраи с экспоненциальным бэкоффом, а вместе с ними — DLQ, куда после нескольких неудачных попыток падают сообщения и спокойно лежат до первой жалобы клиента, потому что регулярно проверять dead letter queue не любит никто, включая меня. Потом одно сообщение теряется где‑то между четырьмя системами, сквозного correlation ID нет, и distributed tracing внезапно превращается в distributed calling: расследование идет не по логам, а по телефону. Потом выясняется, что формально гарантированная доставка сообщений сработала, но две системы все равно живут в разных состояниях, и вы пишете сверку — обычно сразу после неприятного разговора с бизнесом. А под конец приходит безопасность и спрашивает, кто именно может видеть в этом топике поля с персональными данными. И тут выясняется, что ACL прекрасно знает, кому разрешено читать топик, но совершенно не понимает, кому из этих людей положено видеть конкретный паспортный номер.
Ничего невыполнимого тут нет. Беда в том, что список никогда не приходит целиком. Он приходит по одному пункту за инцидент, каждый раз за счет спринта продуктовой команды, и однажды вы обнаруживаете, что у вас есть собственная интеграционная платформа. Просто ее так никто не называет, у нее нет владельца, дорожной карты и документации, а поддерживают ее те же люди, которые вообще‑то должны делать бизнес‑функциональность.
Раз уж я обещал быть честным, скажу и обратное, чего вендоры вслух обычно не говорят. Внутри современной интеграционной платформы почти наверняка нет транспорта, написанного с нуля. Там — форк Kafka, Rabbit или Artemis, а сверху — набор имеющихся и допиленных инструментов, аккуратно связанных друг с другом. Никто в здравом уме не пишет брокер сообщений с нуля. Тот, кто пишет брокер сообщений с нуля, обычно вскоре пишет резюме.
Отсюда законный вопрос, который мне на Хабре задавали в разных формулировках: если вы берете тот же самый опенсорс, что и я, почему у меня это нестабильный «самопис», а у вас вдруг промышленная платформа? Я в свое время задал этот вопрос Илье Виссарионову, он у нас в «Диасофт» отвечает за аппаратно‑системную платформу и на такие вещи смотрит без малейшей романтики. И вот что получается.
Когда вы берете открытое решение, вы, по сути, сами занимаетесь конструированием. Сами отвечаете за контроль совместимости, сами тестируете, и то, что получилось, уникально для вас. Когда то же самое делает вендор, он выстраивает производственный процесс и отдает законченное решение. Оно может быть удобным для всех и не идеальным ни для кого, но это что‑то проверенное.
«Удобно для всех и не идеально ни для кого» — этот слоган можно вынести на футболку. Обратите внимание: тут нет ни слова про технологии, и это правильно, потому что разница — не в качестве кода. Разница в том, кто держит матрицу совместимости, кто гоняет регресс по связкам версий и кому звонить в 3:40 утра, когда рассыпалась сборка, которую вы делали полтора года назад и с тех пор не трогали. Если ваша команда готова держать это сама, держите. Ровно тот случай, когда автор комментария про Kafka прав.
Евророзетка есть. А вилки у всех свои
Второй по популярности вопрос: почему до сих пор нет стандарта? Есть же USB, есть вилка и розетка, воткнул — и работает. Почему в софте каждый раз с чистого листа?
Обычно я отвечаю коротко: евророзетка евророзеткой, но сходите к китайцам, у них свои вилки. А британскую вы вдобавок однажды найдете ночью босой ногой и запомните на всю жизнь.
Андрей Кустов здесь настроен куда менее лирично. Типовые практики бизнеса, по его мнению, давно описаны, а все остальное — от лукавого: программист хочет программировать вместо того, чтобы приспособить под себя готовое. Обертки над Kafka существуют, просто они либо не покрывают вашу специфику, либо вы их не искали.
Соглашусь и добавлю то, что считаю корнем всей истории. Стандарты закрывают транспорт и синтаксис: как передать, как описать интерфейс, как сериализовать объект через интерфейс. AsyncAPI, OpenAPI, Avro, Protobuf справляются отлично. Ни один из них не закрывает семантику вашей предметной области.
Возьмите слово «клиент». В CRM это карточка с историей звонков, где дубли обычное дело и вычищаются раз в квартал, когда у кого‑нибудь дойдут руки. В биллинге это плательщик, привязанный к договору, и один живой человек легко превращается в трех. В скоринге это субъект с идентификатором из внешнего источника и собственным расписанием актуализации. Спецификация опишет вам три схемы, все три будут валидными, и ни одна не подскажет, кто из них главный, что делать при расхождении и в какой момент клиент из CRM превращается в плательщика из биллинга. Этот вопрос решается не протоколом, а совещанием, на котором два владельца систем полтора часа выясняют, чей справочник считать источником истины.
Поэтому готовый коннектор всегда закрывает процентов семьдесят задачи и всегда упирается в оставшиеся тридцать. И поэтому «зоопарк» интеграционных решений на рынке — никакой не признак незрелости отрасли. Это ровно такой же «зоопарк», как «зоопарк» учетных политик, только его почему‑то принято стыдиться.
Шину рождает не архитектура, а оргструктура
Дальше начинается то, ради чего я, собственно, и сел писать эту статью. Технический спор про Kafka, по сути, — это разминка, решения принимаются не там. Иван Иванов, с которого начался этот разговор, описывает механику без всякой деликатности:
«Сидит директор департамента или ИТ‑директор, у него условно сто землекопов, которые все это пилят. Он возьмет вендорскую платформу, и что, должен будет их уволить? А потом ему скажут: у тебя было много народу, ты был директором, а станешь начальником отдела. Ему это зачем?»
Формулировка жесткая, но механику я узнаю. Есть версия помягче, и встречается она гораздо чаще, потому что никто ничего не защищает специально. Команда, которая контролирует свои сервисы и свои контракты, однажды натыкается на чужую систему и пишет к ней отдельный коннектор. Потом второй. Потом третий. На пятом начинают унифицировать: общий формат конверта, общий модуль ретраев, общая библиотека логирования, у нее даже появляется имя и внутренний фанат. Через два года у команды есть собственная шина, которую она обязана поддерживать вместо того, чтобы развивать свои продукты. Никто такого решения не принимал, оно сложилось само, как складывается гараж, где сначала стояла одна коробка.
Вот и ответ на вопрос, почему на рынке столько интеграционных решений. Потому что все сидят и пишут свои.
А самый неудобный вопрос мне задала Яна Доленко, ведущий аналитик Outlines Tech. Мы разбирали, почему компании раз за разом выбирают «самопис», и она разложила экономику так, что было сложно возразить:
«Любой стандартный продукт всегда требует доработки под конкретный бизнес, идеально он не подойдет никогда. А доработка требует хорошей методологической основы: бизнес должен понимать свои процессы, чтобы поставить задачу. Сам продукт может стоить недорого, и кажется, что окупает ценность, но доработка растягивается на годы, и на эти процессы уйдет больше, чем ценность, которую мы в результате получим».
Крыть нечем, но можно уточнить. Требование понимать свои процессы работает в обе стороны. Собственная разработка предъявляет его ничуть не мягче, просто счет за непонимание приходит не контрактом на доработку, а тремя переписанными сервисами и одним уволившимся тимлидом.
У меня есть история, которую я рассказываю, когда спрашивают, почему сделка не состоялась. Приходит заказчик: шина старая, еле дышит, практически не работает, надо менять, сделайте предложение. Сделали. Смотрят и говорят: по ценнику выходит в пять раз больше, чем мы платим в год за нашу нерабочую шину. Платить так много мы не готовы и не уверены, что оно окупится. Да, у нас не работает. Но где гарантия, что ваше заработает?
Гарантии у меня нет. Есть внедрения, есть референсы, есть SLA, а гарантии нет. Заказчик ушел жить и дальше со своей нерабочей шиной. Так ведет себя человек, которому предлагают заплатить дороже за снятие неопределенности, которую он и без того научился терпеть.
Воронков ту же логику объясняет как привычку: свой процесс знаком, свои разработчики под рукой, и проще допилить что‑нибудь в собственном болоте, чем взять современное, которое даст выхлоп когда‑нибудь потом. Он же приводил пример. Есть компании, работающие на конфигурациях, которые не обновлялись лет пятнадцать. Законы выходят, данные подавать надо, все как‑то дорабатывают свое, документацию не ведут, и все у них хорошо. Способ так прожить, кстати, ровно один: очень аккуратно ничего не трогать и очень громко объяснять, почему трогать нельзя.
А дальше начинается самое интересное: спор о том, кто именно тормозит. Андрей Кустов, когда я при нем свалил вину на ИТ, довольно резко возразил: консерватизм живет в бизнесе, который пользуется ИТ‑продуктом, а разработчик пошел бы куда угодно, ему просто не дают. И привел историю крупного госфонда, где стояла WebSphere, и в какой‑то момент выяснилось, что имплементация не собирает бизнес‑процесс целиком. Куски есть в разных системах, а сквозного понимания, как идет оформление, нет ни у кого. Деньги в итоге нашлись не на переделку и оптимизацию, а на отдельную систему мониторинга, которая собирает события отовсюду и восстанавливает процесс задним числом. Вот вам антипаттерн, как подытожил Андрей: никто не взял на себя ответственность наложить эту задачу на всю систему. Спорить я не стал, потому что видел такое не раз.
Иван Иванов смотрит на ту же проблему с противоположной стороны. По его словам, бизнесу обычно безразлично, что происходит под «капотом»: ему нужна конкретная функция, желательно вчера. А главным тормозом нередко становится само ИТ, которому проще развивать привычную систему, чем впускать в контур что‑то новое. Бизнес приходит с идеей, а в ответ слышит: хорошо, доработаем — условно, научим еще один Excel перекладывать данные в еще одно место. До предложения взять готовое решение дело порой даже не доходит: бизнес заранее понимает, что упрется во внутреннее ИТ со своей архитектурой, своим бэклогом и твердым намерением еще немного допилить то, что уже есть.
Забавно, что правы оба, просто описывают разные ситуации. Там, где ИТ живет центром затрат и меряется закрытыми тикетами, тормозит ИТ. Там, где ИТ отчитывается за сроки, а бизнес не может внятно описать собственный процесс, тормозит бизнес. Общее в этих случаях одно, и оно печально: в компании нет человека, у которого в KPI записан ландшафт целиком. У владельца системы — своя система. У руководителя разработки — свой релизный план. У закупки — экономия на цене контракта. Интеграционный слой лежит ровно между всеми и не принадлежит никому, как коробка в общем коридоре.
Иван Иванов тогда добил меня цифрой: срок жизни ИТ‑директора в компании сейчас — около года, а согласование закупки идет год или полтора. Читайте это так: платформу выбирает один человек, внедряет второй, а проклинает третий. И встретиться им не суждено.
Замок с двух сторон, и ключа нет ни у кого
Стандартный контраргумент против вендорской платформы называется vendor lock. Он честный, и делать вид, что его не существует, я не буду. Яна Доленко формулирует его спокойно и справедливо: если однажды перестанет устраивать ценовая политика или изменения, которые приходят вместе со сменой команды платформы, переезжать обратно на свой функционал будет так же больно и дорого, как переезжать сюда.
Отвечу как есть. Порядочность вендора решается договором, а не обещаниями в блоге: мы, например, при прекращении оплаты рубильник не дергаем, поддержка снимается, а решение продолжает работать так же, как работало вчера. Только понимать это надо правильно. Вы остаетесь не с продуктом, а с его замороженной версией. А потом в Kafka находят критическую уязвимость, и чинить ее будет некому. Красиво тут не выходит ни при каком раскладе.
Симметричная история называется тимлок, и про нее говорят гораздо реже. Илья Виссарионов, когда мы это обсуждали, сравнил риски так: уволится конкретный человек, который единственный был в курсе, или перестанет существовать организация, которая зарабатывает на разработке и ведет ее как процесс, — это все‑таки разные по вероятности события. И напомнил про сюжет, о котором в спорах о локе обычно забывают: огромное количество компаний прямо сейчас меняет софт не по собственному желанию, а по требованиям регуляторов, причем иногда переезжает не на свое решение, а на решение другого вендора. Правильного, «золотого» пути тут просто нет, есть набор переменных, которые каждый считает под свои ресурсы. Перевожу на человеческий: вопрос не в том, попадете вы в зависимость или нет. Попадете в любом случае. Вопрос в том, от кого и насколько дорого будет из нее выбираться.
Довольно практичное наблюдение по теме лока я услышал от Андрея Кустова. Если вы взяли опенсорс и ведете свою ветку, у вас всегда остается путь назад: потеряете свои схемы и часть возможностей, но нативную Kafka использовать сможете. В остальных случаях дороги назад нет вообще, придется менять решение целиком.
Отсюда единственный совет, который я считаю универсальным. Считайте не цену входа, а стоимость выхода. Возьмите три сценария, свой код поверх брокера, форк опенсорса и вендорскую платформу, и по каждому честно ответьте, сколько человеко‑месяцев займет уход, что вы потеряете безвозвратно, сколько будете платить за старое параллельно с миграцией и кто внутри компании физически способен эту миграцию довести до конца. Цифры получатся неприятными во всех трех колонках, зато это будет сравнение сравнимого, а не сравнение цены лицензии с зарплатой двух джунов.
И раз уж речь про зависимость от людей, нужно вспомнить самый живучий пример в отрасли. Андрей Кустов уложил его в одну строчку: «Любой программист всегда переписывает чужой сервис». Лекарство известно ровно одно, и оно настолько горькое, что его никто не принимает. Это про документацию, по которой даже пришедшие на пепелище незнакомые люди в состоянии разобраться, будь там хоть трижды неоптимальный код.
Аргумент «мы перепишем лучше» почти всегда верен технически и почти всегда проигрывает экономически. Разработчик, который приходит с этим предложением, обычно прав, он действительно сделает чище. Но его спросят, сколько это займет, и добавят к смете поддержку старого решения на все три года, пока он пишет новое, потому что старое нельзя выключить рубильником. Рабочее и неидеальное против идеального за сто миллионов. В таких координатах выбор известен заранее, а разработчик идет писать в блог, что менеджмент ничего не понимает.
ИИ не спасет интеграцию. Он приведет вам худшего потребителя в вашей жизни
Теперь про то, ради чего многие открыли эту статью. Тезис звучит примерно так: скоро все станет неважно, модели сами свяжут системы между собой, коннекторы будут генерироваться на лету, а спецификации станут общим языком машин.
Начну с той части, где я согласен. Демо действительно красивые. По долгу службы я смотрю, что делают другие платформы, и картинка впечатляет: там, где раньше руками собирали цепочку интеграционного потока, теперь просто говоришь словами: возьми заказы из такого‑то сервиса, сделай с ними то‑то, положи туда‑то. И получаешь готовую цепочку, ровно такую, как описал. Выглядит это, как реклама средства для мытья посуды, где жир исчезает сам.
Но что именно модель написала под «капотом», чтобы эта цепочка выполнялась, вопрос открытый. Причем волнует меня не вопрос, работает ли сейчас, сейчас‑то работает. Волнует, как это сопровождать через полтора года, когда поставщик поменяет формат, а человека, писавшего промпт, в компании давно не будет. Мы поменяли одну непрозрачную «коробку», самописный коннектор без документации, на другую непрозрачную «коробку», сгенерированный код, который никто не читал. Прогресс, прямо скажем, спорный.
Андрей Кустов проводит границу применимости там же, где и я, только технически точнее. Путь выбирает архитектор, а модель помогает этот путь пройти: возьмете вы Kafka Connect, Camel или стриминговый процессор вроде Flink, она в любом случае настроит и роутинг, и трансформации. Правда, ведут себя модели по‑разному. Вроде соглашается, составляет план, а на какой‑то десятой итерации сообщает, что придумала иначе, и идет своей дорогой. Лечится это фиксаторами плана и паттернами работы с ИИ, но иметь это в виду стоит. А потом Андрей сказал то, чего я не слышал ни в одной презентации:
«Модель не способна обрабатывать поток, который течет через ваш брокер. Если вы выбрали Kafka, у вас там, скорее всего, не меньше миллиона операций в сутки, иначе смысла в выборе нет. Задайте любой модели простое арифметическое выражение, она потратит секунды».
Вот эту границу и стоит держать в голове. Модели не место на «горячем» пути. Ей отлично живется там, где цена задержки измеряется минутами: разобрать спецификацию чужого API и предложить маппинг, набросать черновик трансформации, объяснить, что делает легаси‑коннектор, найти в реестре сообщений закономерность в падениях, которую человек ищет два дня. И ей нечего делать там, где на сообщение выделено сорок миллисекунд и требуется, чтобы одинаковый вход давал одинаковый выход.
Яна Доленко описывала ту же роль через свою практику, и я под каждым словом подпишусь. Модели, особенно локальные, — сейчас неплохая поддержка для анализа: помогают разобраться в уже реализованной архитектуре, подсвечивают риски, показывают чуть больше вариантов реализации, дают материал для решения и позволяют двигаться быстрее. А вот принимать решения без человека они пока не умеют, и примеров обратного она не видела. Отлично, если младший аналитик, который прочитал всю вашу документацию за ночь, ни разу не пожаловался. Решения по‑прежнему за вами.
Есть и более циничный взгляд на происходящее, и Иван Иванов излагает его с явным удовольствием. Топы, по его мнению, поверили в «волшебный ключик» элементарной автоматизации, и сегодня ИИ — прежде всего отличный инструмент продаж: заходишь в большой неповоротливый корп, говоришь, что делаешь это на базе ИИ, и продается заметно проще. Феномен, по его прогнозу, продлится недолго. Андрей Кустов накрыл эту мысль вопросом, на котором обычно заканчивается веселье: приходил ли к кому‑нибудь заказчик с просьбой оценить эффект от ИИ в юнит‑экономике конкретного бизнес‑процесса. Ответить, по его наблюдению, не может практически никто. Иван Иванов уверен, что при внедрении обычной информационной системы, написанной живыми людьми, на этот вопрос тоже никто толком никогда не отвечал.
Что называется, за что боролись.
Теперь моя позиция, она сложилась не из демо, а из того, как выглядят запросы последнего года. Появление MCP и агентных протоколов интеграционную задачу не отменило, оно сделало модель еще одним участником обмена. С точки зрения интеграционного слоя, агент — это очередная система, контракт которой вы не контролируете, только хуже. Обычная чужая система хотя бы детерминирована: вызывает один и тот же метод одинаково и ломается предсказуемо, за что мы ее и любим. Агент может решить, что в этой ситуации логичнее вызвать другой метод. Может повторить запрос, потому что не понял ответ. Может пойти по цепочке, которую вы не проектировали, просто потому что она формально доступна.
Требования отсюда следуют самые обычные, ни одного нового. Просто раньше их можно было не выполнять, а теперь нельзя. Идемпотентность из желательной становится обязательной: любая операция записи, до которой дотягивается агент, должна переживать повтор, и не потому, что агент сломается, а потому что он ретраит по своей логике, о которой вам никто не рассказывал. Права придется резать не по системам, а по операциям, потому что фраза «агент имеет доступ к CRM» — это не политика безопасности, а заявка на инцидент. Аудит и сквозная трассировка перестают быть средствами гигиены и становятся условием эксплуатации, потому что после спорного решения автономного процесса вам придется восстановить всю цепочку данных, которыми его кормили, а без единого реестра сообщений такое расследование просто не проводится. И данные агенту надо отдавать нормализованными: если вы дали модели три разные версии клиента, галлюцинация случится не потому, что модель глупая, а потому что вы дали ей три разные версии клиента.
Отдельно про то, чего лишается автономный процесс. В обычном обмене недоставленное сообщение рано или поздно заметит человек, у которого не сходится отчет, и позвонит с претензией. Механизм компенсации — некрасивый, медленный, но рабочий. Когда человека в контуре нет, цепочка рвется молча, и вы узнаете об этом от клиента дня через три, в лучшем случае.
Так что ИИ интеграцию не спасет. Он не договорится за вас о том, что считать клиентом, не заставит соседнее подразделение соблюдать контракт, не найдет в компании владельца сквозного процесса и не посчитает TCO. Зато приведет в ландшафт потребителя, который не читает документацию, не соблюдает контракты, работает без присмотра и требует данных немедленно. Если ваш интеграционный слой держался на устных договоренностях между людьми, вы узнаете об этом быстро.
Когда я сам говорю: не берите
Как и обещал, теперь — обратная сторона. Без нее статья превратилась бы в буклет.
Платформа не нужна, если ландшафт маленький и однородный. Три‑пять систем с нормальными API, все свои, все под одной командой. Прямые вызовы и API Gateway тут дешевле и в разработке, и в поддержке, а платформа будет чувствовать себя экскаватором на грядке.
Она не нужна, если ключевые системы уже живут в одной экосистеме и внутри нее есть свои обмены. Ставить слой поверх — значит, платить дважды за одну и ту же работу, а потом объяснять это на защите бюджета.
Она не нужна на новом продукте, созданном с чистого листа. Возьмите брокер и API Gateway, а к интеграционному слою приходите тогда, когда появится второй или третий контрагент, чей контракт вы не контролируете. Раньше — это преждевременная оптимизация, за которую платят техдолгом, причем платят не те, кто ее затеял.
И самое неприятное. Она не нужна, если у вас нет ни людей, ни бюджета на эксплуатацию. Интеграционный слой — это отдельная инженерная дисциплина со своим мониторингом и своим набором характерных отказов, которые надо уметь разбирать. Без таких людей вы получите не решение проблемы, а еще одну легаси‑систему, только с контрактом на поддержку и строкой в бюджете.
Мой рабочий критерий я уже приводил, но повторю, потому что это единственное, что я прошу отсюда вынести. Считайте не системы, а чужие контракты. Меньше трех и меняются редко, живите как живете. Больше пяти, трогают их несколько раз в квартал, а в планах — сценарии, где данные из разных систем нужны одновременно и сразу, значит, интеграционный слой у вас уже есть. Вопрос только в том, признаете вы это или он продолжит жить размазанным по коду, без владельца и без документации.
Если хочется потрогать руками, а не посмотреть презентацию, у нас есть бесплатный дистрибутив с ограничением по числу потоков. Ставится на собственную виртуалку за пару часов, и обычно этого хватает, чтобы понять, ваш это подход или нет.
Сухой остаток
Спор «Kafka против платформы» » ложный, потому что это спор про разные «этажи». Kafka — транспорт, и транспорт отличный. Платформа — это ответственность за семантику, доставку и трассировку, и ее можно взять на себя, а можно передать. Оба варианта рабочие, и выбирают между ними не по архитектуре, а по тому, есть ли у вас люди, которые будут это держать ближайшие пять лет.
Настоящая причина, по которой «самопис» побеждает, — не техническая. Интеграционный слой не принадлежит никому, лежит между всеми владельцами систем и не попадает ни в один KPI. Пока так, каждая компания будет заново писать свою шину, а рынок будет выглядеть «зоопарком». Изменить это одной статьей я не рассчитываю, но хотя бы назову вещи своими именами.
ИИ картину не меняет. Он только сокращает время, за которое накопленный беспорядок становится заметен.
И да, если после всего прочитанного вы решили, что платформа вам не нужна, вполне возможно, что вы правы. Мне интереснее другое. Напишите в комментариях цифрами: сколько у вас интерфейсов, которые вы не контролируете, сколько раз в год их меняют без предупреждения и сколько человеко‑дней в квартал уходит на разбор падений в обменах. Подозреваю, что ответ на вопрос из заголовка лежит ровно в этих трех цифрах, и у каждого он свой.
