Архитектура интеграций: iPaaS vs ESB vs кастом – как выбрать и не пожалеть

Дамир управляет торговой компанией в Алматы – 2 миллиарда тенге оборота, двадцать менеджеров, свой склад, интернет-магазин. Вроде бы всё круто, технологий полно: и CRM есть, и 1С внедрена, и сайт работает. Только вот все эти системы живут сами по себе, словно в параллельных вселенных.

Каждое утро бухгалтер Асель садится сверять остатки между складом и сайтом – два часа вручную. Менеджеры копируют заказы из CRM в 1С, потому что иначе бухгалтерия не видит продажи. А когда клиент звонит узнать, где его товар, приходится лихорадочно открывать три разные программы и пытаться сложить картину воедино.

«Чувствую себя как в каком-то музее технологий, – говорит Дамир с усмешкой. – Везде читаю про ИИ, автоматизацию, цифровизацию. А мы тут сидим и Ctrl+C, Ctrl+V между окнами делаем, как в девяностых».

Узнаёте себя? Это классика казахстанского бизнеса. Покупаем CRM, внедряем 1С, ставим телефонию, запускаем сайт – а потом удивляемся, почему они друг с другом не разговаривают. Информация ползёт между системами через людей, Excel-таблицы и переписки в WhatsApp. Пока компания маленькая – терпимо. Но когда заказов сотни в день, эта схема начинает разваливаться на глазах.

Понятно, что нужна интеграция. Вопрос – какая? Тут три совершенно разных пути, и это не просто технический выбор. Это стратегия на годы вперёд. Выберешь неправильно – потеряешь месяцы времени и кучу денег. Попадёшь в точку – получишь систему, которая растёт вместе с бизнесом и не сыплется каждую неделю.

Три пути: каждый со своими плюсами и минусами

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

Вроде бы всё просто, правда? На деле – совсем нет. Каждый подход работает отлично в своей ситуации. iPaaS великолепен для стандартных облачных сервисов, но начинает буксовать, когда речь заходит про казахстанские реалии – ту же 1С или Kaspi. ESB вытянет любую сложность, но вам понадобится отдельная команда из 3-5 человек просто на поддержку. А кастомная разработка даёт полную свободу, но запросто превращается в зоопарк из микросервисов, в котором через год никто не разбирается.

Давайте теперь разберём каждый вариант подробно. Посмотрим, как они устроены, когда работают как часы, а когда превращают вашу жизнь в ад.

iPaaS: когда интеграция собирается как конструктор

iPaaS (Integration Platform as a Service) – это облачные платформы, где вы связываете системы без программирования. Выбираете готовые коннекторы, настраиваете правила – и платформа сама занимается передачей данных между системами. Такой себе «конструктор интеграций».

На рынке куча игроков: Zapier, Make (раньше назывался Integromat), Workato, Tray.io, Microsoft Power Automate. Для СНГ есть Albato и ApiX-Drive. У каждого своя специализация: Zapier настолько простой, что разберётся даже ваша бабушка, Workato тянет сложные корпоративные сценарии, а Make хорош, когда нужно много чего делать с данными перед отправкой.

Как это выглядит в реальной жизни

Допустим, вам нужно, чтобы при создании сделки в CRM автоматом создавался контакт в системе email-рассылок, плюс документ в Google Docs, плюс задача в Trello. Если делать это классически, с программированием – это три отдельных интеграции. Каждая со своим кодом, тестами, поддержкой. Месяц работы минимум.

В iPaaS открываете визуальный конструктор, кликаете «новая сделка в CRM» как триггер, добавляете три действия (контакт, документ, задача), настраиваете, какие поля куда идут – и всё, за час готово. Ни одной строчки кода писать не надо.

Что хорошего в iPaaS? Во-первых, скорость. Утром сели, к обеду – работающая интеграция. Это не преувеличение, реально так бывает. Во-вторых, деньги считать легко: платишь фиксированную подписку или за количество операций, никаких сюрпризов в конце месяца. В-третьих, не нужен программист – толковый бизнес-аналитик сам накликает всё в визуальном редакторе. Ну и коннекторы к популярным сервисам уже готовы: Salesforce, HubSpot, Slack, Google Workspace – просто выбираешь из списка.

Теперь про грабли. Главная засада для казахстанского бизнеса – готовых коннекторов к нашим системам нет. Kaspi, местные банки, локальная 1С – всё придётся допиливать руками. Ещё нюанс: когда объёмы растут, ценник взлетает нелинейно. Тысяча операций в день – одна цена, десять тысяч – уже совсем другая песня. И да, ваши данные уходят в чужое облако. Для кого-то это ок, для кого-то – категорически нет.

Когда iPaaS – ваш лучший друг

iPaaS идеален, когда вы связываете популярные облачные сервисы друг с другом. CRM плюс email-маркетинг, плюс мессенджеры, плюс Google Workspace – вот классика жанра. Ещё отлично работает для проверки идей: быстро собрали MVP, посмотрели, как работает, а потом, если нужно, переписали на что-то более серьёзное.

Для Казахстана iPaaS хорош, если у вас в основном международные облачные сервисы. Но стоит в игру войти 1С, местной телефонии или интеграции с Kaspi – всё, приехали. Готовых коннекторов для этого нет, начинаете городить кастомные webhooks, и вся та простота, за которую платили, испаряется.

Во что это выльется по деньгам

Ценник на начало 2025 года примерно такой: Zapier – от $20 в месяц за базовый тариф до $500+ для серьёзных объёмов. Make – стартует от $9/мес, но если у вас больше 10 тысяч операций в месяц, будет уже $150-300. Workato для крупных компаний – от $10,000 в год. Наши решения типа Albato – где-то от $30/мес.

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

ESB: когда всё крутится вокруг одной шины

ESB (Enterprise Service Bus) – это совсем другая история. Тут вы не связываете системы напрямую друг с другом. Вместо этого создаёте центральный «хаб» – шину данных, через которую проходят все разговоры между системами. Подключил систему к шине один раз – и всё, она теперь может общаться с любой другой системой без дополнительных костылей.

Старая школа ESB – это MuleSoft, IBM Integration Bus, TIBCO, WSO2. Более свежие варианты с микросервисами – Apache Kafka, RabbitMQ, AWS EventBridge. Грань между «классической шиной» и «event-driven архитектурой» сейчас размыта, но суть одна: всё управление потоками данных в одном месте.

В чём фишка

Допустим, у вас 10 систем: CRM, 1С, склад, сайт, телефония, email, мессенджеры, BI-система, HR, документооборот. Если связывать их напрямую друг с другом (point-to-point), получается до 45 отдельных интеграций – каждая система со всеми остальными. С ESB нужно всего 10 подключений – по одному к шине от каждой системы.

Но главная сила ESB не в цифрах, а в том, что всё становится управляемым. У вас одна точка, где видны все потоки данных. Можете трансформировать сообщения на лету, маршрутизировать по правилам, ловить ошибки в одном месте. Если какая-то система легла – шина придержит сообщения в очереди и отдаст, когда система поднимется обратно.

Когда без ESB уже не обойтись

ESB имеет смысл внедрять в определённых ситуациях. Когда у вас больше пяти-семи систем и все они должны общаться друг с другом – это первый звоночек. Когда процессы критичны настолько, что потерянное сообщение равно потерянным деньгам – второй. Когда регуляторы или внутренний аудит требуют точно знать, какие данные когда и куда ушли – третий. Когда информацию нужно серьёзно преобразовывать между системами, а не просто копировать поля – четвёртый. И когда нагрузка измеряется тысячами сообщений в минуту, а надёжность – это не опция, а must have.

Сколько придётся выложить

ESB – удовольствие недешёвое. И дело даже не столько в лицензиях (хотя MuleSoft или TIBCO обойдутся от $50,000 в год), сколько в людях. Понадобится архитектор интеграций, пара разработчиков на поддержку, DevOps для инфраструктуры. Минимум 3-5 специалистов, а каждый в Казахстане стоит от 1.5 до 3 миллионов тенге в месяц.

Open-source варианты вроде Apache Kafka или RabbitMQ сэкономят на лицензиях, но потребуют ещё больше экспертизы. Это точно не «поставил и забыл». Это серьёзная инфраструктура, за которой нужно постоянно следить.

Кастомная разработка: делаем всё сами

Третий вариант – писать интеграции своими силами. Простой скрипт на Python, микросервис на Node.js или Go – что угодно, что умеет ваша команда. Полный контроль над кодом, логикой, инфраструктурой. Всё в ваших руках – и все проблемы тоже.

Почему компании идут по этому пути

Честно? Чаще всего потому что «так получилось». Был программист, написал скриптик. Скриптик постепенно превратился в сервис. Сервис оброс патчами и костылями. И вот это уже «наша фирменная система интеграций», к которой все боятся прикасаться.

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

Чем это может выстрелить в ногу

Главная засада – это «bus factor». Интеграцию написал один человек, он уволился – и вот у вас чёрный ящик, в котором никто не разбирается. Видел компанию, где критичная интеграция между CRM и 1С висела на скрипте программиста, ушедшего три года назад. Падала раз в неделю, каждый раз – паника, танцы с бубном и молитвы.

Когда кастом – это нормальный выбор

Решили идти путём кастомной разработки? Тогда делайте это с открытыми глазами. Сразу закладывайте бюджет на документацию – минимум 20% от времени программирования. Пишите тесты. Настраивайте мониторинг с самого начала. И самое важное: критичные интеграции не должны делаться руками одного человека. Никогда.

Идеальная ситуация для кастома: есть крепкая IT-команда (хотя бы 2-3 бэкенд-разработчика), налаженные процессы разработки, и бизнес действительно требует чего-то специфического. Например, синхронизация товаров и остатков между 1С и CRM – обычно кастомная задача, потому что у каждой компании свои правила учёта и структура номенклатуры.

Сравнение подходов: сводная таблица

Собрал всё в одну таблицу. Удобно для быстрой прикидки, что подходит в вашей ситуации.

Что важно знать про казахстанский рынок

Теория – это хорошо, но у нас в Казахстане своя специфика. И если её игнорировать, красивая архитектура на бумаге превратится в головную боль в реальности.

1С – это наше всё

Почти все компании в Казахстане сидят на 1С для бухгалтерии и учёта. И это не изменится в ближайшие годы, как бы кто ни мечтал. Значит, любая серьёзная интеграция должна уметь разговаривать с 1С. А вот засада: ни одна глобальная iPaaS-платформа не имеет готового коннектора для казахстанской 1С. Придётся либо городить промежуточный слой с webhook'ами, либо писать кастомную интеграцию.

Kaspi, Halyk, Jusan – живут по своим правилам

У казахстанских банков и платёжных систем свои API, которые не похожи на международные стандарты. Интеграция с Kaspi Pay, Kaspi Магазин, банковскими эквайрингами – это всегда кастомная разработка. Глобальные iPaaS тут бессильны, готовых коннекторов не будет.

Специалистов мало, и они дорогие

В Алматы и Астане есть хорошие IT-шники, но их не так много, и стоят они недёшево. Это серьёзно влияет на выбор: если для ESB нужна команда из 5 человек, а на рынке таких специалистов – наперечёт, может, проще взять iPaaS + кастом для местных систем, чем пытаться собрать полноценную ESB-команду?

Облака или свои серверы?

Крупные казахстанские компании – особенно в финансах и госсекторе – предпочитают держать данные у себя. Для них облачные iPaaS часто не вариант по соображениям безопасности. Это склоняет выбор к локальным ESB или кастомной разработке на своих серверах.

Технические паттерны, без которых всё развалится

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

Идемпотентность

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

Про идемпотентность и ретраи в webhook'ах мы написали отдельную статью – там всё разжевали с конкретными примерами.

Очереди сообщений

Синхронные вызовы, когда система A сидит и ждёт ответа от системы B – это хрупко. Легла B или притормозила – и A тоже встала. Асинхронная схема с очередями (RabbitMQ, Kafka, даже простой Redis) развязывает всё это: A кинула сообщение в очередь и пошла дальше работать, а B заберёт, когда будет готова.

Circuit Breaker

Внешняя система не отвечает? Не надо в неё бесконечно стучаться. Circuit Breaker («автоматический выключатель») размыкает цепь после N неудачных попыток и потом периодически пробует восстановить связь. Это спасает вашу систему от каскадных падений, когда один сбой тянет за собой всё остальное.

Единый формат сообщений

Когда систем десять, и каждая говорит на своём языке (тут даты в одном формате, там в другом, везде свои названия полей) – трансформация данных превращается в кошмар. Определите один общий формат для ваших сообщений и конвертируйте данные на входе/выходе каждой системы.

Грабли, на которые наступают все

За годы работы с казахстанскими компаниями я видел одни и те же ошибки снова и снова. Вот четыре классики жанра:

Как выбрать: простой алгоритм

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

Шаг 1: Инвентаризация систем

Составьте список всех систем, которым нужно обмениваться данными. По каждой зафиксируйте: какой у неё API (REST, SOAP, файлы, вообще нет API), какие данные надо передавать, как часто (раз в день, каждую минуту, в реальном времени), насколько критично, если что-то потеряется.

Шаг 2: Посчитайте объёмы

Сколько у вас транзакций в день или месяц? До 1000 в день – справится почти любой вариант. От 1000 до 10000 – уже надо думать про производительность. Больше 10000 – без серьёзной архитектуры не обойтись.

Шаг 3: Оцените команду

Честно ответьте: кто будет это поддерживать? Есть ли у вас люди с опытом интеграций? Готовы нанимать? Если команды нет и не будет – ESB точно не ваш вариант, остаётся iPaaS + аутсорс для кастомных кусков.

Шаг 4: Сделайте прототип

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

Шаг 5: Считайте на три года

Посчитайте полную стоимость владения (TCO): лицензии, серверы, зарплаты, обучение, поддержку. И не на год, а на три года вперёд. Дешёвый старт может стать золотым в эксплуатации, и наоборот.

Начните думать потоками данных, а не системами

Помните Дамира из начала статьи? После того как мы разобрались с его системами, предложили гибридный вариант: iPaaS (Make) для связки CRM с email-маркетингом и мессенджерами, кастомный микросервис для синхронизации с 1С, плюс простой webhook-сервис для обработки заказов с сайта.

Внедрение заняло шесть недель. Теперь Асель не тратит два часа на ручную сверку – остатки синхронизируются сами каждые 15 минут. Менеджеры видят статус оплаты прямо в CRM, не переключаясь между окнами. А когда клиент звонит, вся инфа по заказу сама выскакивает на экран.

«Знаете, это вообще не rocket science, – говорит Дамир. – Надо было просто перестать думать про отдельные программы и начать думать про то, как данные ходят между ними. Архитектурное мышление, да? Так вы это называете?»

Именно так. Неважно, что выберете – iPaaS, ESB или кастом. Важно перестать клеить костыли и начать думать системно. Планировать не на спринт, а на годы. И чтобы у каждой интеграции был владелец, документация и нормальный мониторинг.

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

Читайте также

• Idempotency и ретраи в webhooks: как сделать синхронизацию устойчивой
• Синхронизация товаров/цен/остатков: паттерны 1С ↔ CRM
• Единый case management: CRM + helpdesk + омниканал
• RPA vs CRM-автоматизация vs интеграции: что выбрать
• Интеграция CRM с 1С, SAP, складом и сайтом