Альтернатива Kannel с GUI, биллингом и white-label

Kannel уже больше двадцати лет незаметно передаёт SMS по всему миру, и если вы эксплуатируете серьёзный шлюз на собственном сервере, велика вероятность, что прямо сейчас в вашем стеке работает Kannel или Jasmin: держит SMPP-подключения (bind) и никогда не жалуется. Поэтому, когда оператор ищет альтернативу Kannel, он редко хочет заменить транспортный уровень (bearer). Он имеет в виду, что перерос всё, чем транспортный уровень намеренно никогда не должен был быть: графическую панель администратора, клиентские аккаунты, биллинг, white-label-порталы, человека, которому можно позвонить в 2 часа ночи. Это руководство посвящено этому разрыву и честным способам закрыть его, не выбрасывая движок, который уже работает.

Что Kannel и Jasmin делают блестяще

Отдадим должное транспортным решениям с открытым кодом: если делать вид, что они слабы, легко потратить деньги на их замену. BearerBox в Kannel терминирует SMPP с тех времён, когда большинства стартапов в сфере сообщений ещё не существовало. Он держит постоянные подключения к вашим SMSC, поддерживает их активными, переподключается, когда оператор разрывает сессию, распределяет трафик между подключениями и пропускает огромные объёмы на скромном оборудовании. Он написан на C и стабилен до скуки, а именно такая скучная стабильность и нужна уровню, который работает с операторами.

Jasmin появился позже и написан на Python. У него более понятная модель конфигурации, CLI для управления и более удобный API, в котором многим командам проще разобраться. Для терминации SMPP как таковой оба являются легитимным профессиональным выбором, и ни один из них не станет причиной падения вашего шлюза.

Объединяет их философия проектирования: это транспортный уровень, а не продукт. Они соединяют вашу платформу с операторами и делают эту одну работу исключительно хорошо. Всё, за что реселлерский бизнес на самом деле берёт деньги с клиентов, находится над этой работой, и именно там по-настоящему начинается поиск альтернативы.

Шесть вещей, которые транспортный уровень никогда за вас не сделает

Сразу после установки чистый Kannel или Jasmin оставляет шесть пробелов. Ни один из них не является недостатком ПО. Это просто части, которые никогда не входили в задачу, и именно их продаёт бизнес.

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

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

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

White-label-порталы для клиентов. Вашим клиентам некуда войти. Нет панели под брендом, где можно создать рассылку, загрузить список контактов, проверить баланс или получить отчёт. Для реселлера портал и есть продукт, который клиент видит каждый день, а у транспортного уровня портала нет.

Отчёты, понятные клиенту. Kannel пишет логи. Логи не заменяют отчёт о доставке, который клиент может открыть, отфильтровать и понять, не звоня вам. Чтобы превратить сырые журналы доступа и события DLR в дашборды по клиентам, выгружаемую историю и понятные показатели доставки, нужен уровень отчётности, которого нет, пока вы его не разработаете.

Тот, кто ответит в полночь. У открытого ПО есть сообщество, щедрое и часто прекрасное, но это не SLA. Когда подключение падает во время ночной рассылки выписок у клиента, нет линии поддержки, которая отвечает за проблему. Для хобби это нормально. Для бизнеса с платящими клиентами отсутствие ответственной поддержки означает реальные издержки.

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

Миграция, при которой подключения к SMSC сохраняются

Вот обнадёживающая часть, и причина, по которой слово «альтернатива» здесь неточно. Чтобы получить всё перечисленное, не нужно удалять Kannel. Менее рискованный и обычно более разумный путь: поставить платформу управления поверх транспортного уровня, которому вы уже доверяете.

Это работает, потому что Kannel спроектирован так, чтобы им управляли извне. Он предоставляет интерфейс sendsms для отправки сообщений и интерфейс администрирования для статуса и управления, и именно к этому стыку подключается платформа. Платформа вроде Smppcube располагается над транспортным уровнем: она отвечает за графический интерфейс, мультитенантные аккаунты, биллинг и порталы и передаёт сообщения вниз, в Kannel, который продолжает делать то, что умеет лучше всего, то есть держать подключения к операторам. Подключения, которые вы долго настраивали с каждым SMSC, остаются на месте.

Разумная миграция выглядит так. Во-первых, разверните платформу рядом с работающим Kannel и направьте её на тот же BearerBox, чтобы в продакшене пока ничего не менялось. Во-вторых, воссоздайте в платформе маршруты и тарифы так, чтобы они совпадали с теми, которые уже использует Kannel. В-третьих, создайте клиентские аккаунты с тарифами для каждого клиента и импортируйте балансы, которые вы вели в таблицах. В-четвёртых, переведите одного лояльного клиента на новый портал и проследите, как реальная рассылка проходит весь путь: из панели через биллинг платформы, вниз через Kannel, к SMSC и обратно в виде отчёта о доставке, который клиент может прочитать. В-пятых, переведите остальных, когда цифры совпадут, и откажитесь от таблиц.

Ни на одном этапе этой последовательности вы не заменяете транспортный уровень и не разрываете подключения. Вы добавляете бизнес-уровень, которого всегда не хватало, поверх телеком-уровня, с которым всегда всё было в порядке. Поскольку Smppcube продаётся как разовая лицензия, которой вы владеете полностью, а не как арендованная панель, платформа, на которую вы переходите, тоже остаётся на вашем собственном сервере. Так сохраняется изоляция от интернета (air-gap) или размещение в DMZ, ради которых вы и выбрали self-hosted.

Оставайтесь на Kannel (или Jasmin), если…

Уважительный вывод, без попытки что-то продать: иногда чистый транспортный уровень подходит идеально, а платформа будет лишней нагрузкой, без которой стоит обойтись.

Оставайтесь на чистом Kannel или Jasmin, если у вас одна организация (single tenant) и нет клиентов, которым нужно выставлять счета. Если вы подключаете одну из своих систем к одному оператору и у вас нет дерева реселлеров, изоляции по клиентам и счетов, то транспортный уровень и несколько скриптов будут правильным и дешёвым решением, а полноценная платформа окажется ненужным грузом. Оставайтесь на нём, если разработка и сопровождение такого ПО действительно и есть ваш бизнес, а не отвлечение от него: некоторые команды хотят владеть каждым уровнем и располагают временем разработчиков, чтобы его поддерживать. И оставайтесь на нём, пока вы ещё проверяете, есть ли спрос вообще: шлюз на конфигурационных файлах вполне подходит для первого пилота, прежде чем вкладываться в инструменты.

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