Alternativa ao Kannel com GUI, faturamento e white-label

O Kannel transporta discretamente o SMS do mundo há mais de vinte anos e, se você opera um gateway self-hosted sério, é bem provável que o Kannel ou o Jasmin esteja na sua stack agora mesmo, mantendo binds SMPP sem apresentar problemas. Por isso, quando um operador procura uma alternativa ao Kannel, raramente quer substituir o bearer. O que ele quer dizer é que ultrapassou tudo aquilo que um bearer, por decisão de projeto, nunca foi feito para ser: uma administração gráfica, contas de clientes, faturamento, portais white-label, alguém a quem ligar às 2 da manhã. Este guia trata dessa lacuna e das formas honestas de fechá-la sem descartar o motor que já funciona.

O que o Kannel e o Jasmin fazem muito bem

É justo reconhecer o mérito dos bearers de código aberto, porque subestimá-los é o caminho para gastar dinheiro substituindo-os. O BearerBox do Kannel faz terminação SMPP desde antes da existência da maioria das startups de mensageria. Ele mantém binds persistentes com os seus SMSCs, conserva essas sessões ativas, reconecta quando uma operadora derruba a sessão, distribui o tráfego entre as conexões e processa volumes enormes em hardware modesto. É escrito em C, é estável a ponto de ser totalmente previsível, e previsibilidade é exatamente o que você quer da camada que se comunica com as operadoras.

O Jasmin é o irmão mais novo, escrito em Python, com um modelo de configuração mais limpo, uma CLI de gerenciamento e uma API mais amigável, que muitas equipes consideram mais fácil de entender. Para a terminação SMPP pura, qualquer um dos dois é uma escolha legítima e profissional, e nenhum deles será o motivo de o seu gateway cair.

O que os dois têm em comum é uma filosofia de projeto: são um bearer, não um produto. Conectam a sua plataforma às operadoras e fazem essa única tarefa extremamente bem. Tudo aquilo que um negócio de revenda de fato cobra dos clientes fica acima dessa tarefa, e é aí que a busca por uma alternativa realmente começa.

As seis coisas que um bearer nunca fará por você

Na instalação padrão, uma implantação pura de Kannel ou Jasmin deixa seis lacunas. Nenhuma delas é um defeito do software. São simplesmente as partes que nunca estiveram no escopo, e são justamente as partes que um negócio vende.

Uma administração gráfica. Não há GUI alguma. Cada rota, cada tarifa, cada conexão SMSC e cada usuário é uma linha em um arquivo de configuração editado via SSH. Isso funciona para um único engenheiro que conhece a stack a fundo, e se torna um obstáculo no momento em que você quer uma equipe, operadores sem perfil técnico ou uma trilha de auditoria de quem alterou o quê.

Contas de clientes multi-tenant. Um bearer não tem o conceito de cliente. Ele transporta mensagens; não sabe, nem precisa saber, que estas dez mil pertencem a um banco e aquelas a uma floricultura. Não há isolamento por cliente, nem saldos separados, nem tarifas por cliente, nem como suspender uma conta sem afetar outra. A arquitetura multi-tenant é a diferença entre um simples canal de transporte e um negócio, e você a desenvolve ou a compra.

Faturamento e controle de crédito. Nada debita uma mensagem do saldo de um cliente antes do envio, precifica essa mensagem pela rota utilizada, faz o estorno correto em caso de falha definitiva ou a inclui em uma fatura. Um bearer puro enviará sem restrição mensagens que você nunca conseguirá faturar. Controle de crédito, carteiras pré-pagas, faturamento pós-pago e preços em várias moedas ficam todos por sua conta.

Portais white-label para clientes. Seus clientes não têm onde fazer login. Nenhum painel com a sua marca para criar uma campanha, carregar uma lista de contatos, consultar o saldo ou extrair um relatório. Para um revendedor, o portal é o produto que o cliente vê todos os dias, e um bearer não tem um.

Relatórios que um cliente consiga ler. O Kannel grava logs. Logs não são um relatório de entrega que um cliente possa abrir, filtrar e entender sem ligar para você. Transformar logs de acesso brutos e eventos de DLR em painéis por cliente, históricos exportáveis e taxas de entrega legíveis é uma camada de relatórios que não existe até que você a desenvolva.

Alguém para atender à meia-noite. O código aberto vem com uma comunidade, generosa e muitas vezes excelente, mas uma comunidade não é um SLA. Quando um bind cai durante o processamento noturno de extratos de um cliente, não há uma linha de suporte responsável pelo problema. Para um projeto pessoal, isso é aceitável. Para um negócio com clientes pagantes, a ausência de um suporte responsável é um custo real.

O resumo honesto: transformar um bearer em um negócio é um projeto de software, e de grande porte. O custo real desse software gratuito são os meses de engenharia dedicados a faturamento, multi-tenant, portais e relatórios, somados à manutenção de tudo isso para sempre. Calcule o custo desse projeto com honestidade antes de decidir executá-lo por conta própria.

A migração que preserva seus binds com o SMSC

Esta é a parte tranquilizadora, e o motivo pelo qual “alternativa” é a palavra errada. Você não precisa remover o Kannel para obter tudo o que foi descrito acima. O caminho de menor risco, e geralmente o mais inteligente, é colocar uma plataforma de gestão sobre o bearer em que você já confia.

Isso funciona porque o Kannel foi projetado para ser controlado por outro sistema. Ele expõe uma interface sendsms para o envio de mensagens e uma interface de administração para status e controle, que é exatamente o ponto de integração que uma plataforma utiliza. Uma plataforma como o Smppcube fica acima do bearer: ela assume a GUI, as contas multi-tenant, o faturamento e os portais e repassa as mensagens ao Kannel, que continua fazendo aquilo em que é melhor: manter seus binds com as operadoras. As conexões que você levou tempo ajustando com cada SMSC não mudam.

Uma migração sensata funciona assim. Primeiro, coloque a plataforma em funcionamento ao lado do Kannel em execução, apontada para o mesmo BearerBox, para que nada mude em produção por enquanto. Segundo, recrie suas rotas e tarifas dentro da plataforma, de acordo com o que o Kannel já usa. Terceiro, crie as contas de clientes e as tarifas de cada cliente, importando os saldos que você vinha controlando em planilhas. Quarto, transfira um cliente de confiança para o novo portal e acompanhe uma campanha real de ponta a ponta: do painel, passando pelo faturamento da plataforma, descendo pelo Kannel, até o SMSC, e de volta como uma confirmação de entrega que o cliente consiga ler. Quinto, migre os demais quando os números coincidirem, e aposente as planilhas.

Em nenhum momento dessa sequência você substitui o bearer ou derruba um bind. Você está adicionando a camada de negócio que sempre faltou, sobre a camada de telecom que sempre funcionou bem. Como o Smppcube é uma licença de pagamento único, integralmente sua, e não um painel alugado, a plataforma para a qual você migra também permanece no seu próprio servidor, o que preserva o isolamento air-gap ou em DMZ que levou você a escolher uma solução self-hosted em primeiro lugar.

Continue com o Kannel (ou com o Jasmin) se…

A conclusão justa, sem argumento de venda: às vezes um bearer puro é exatamente o certo, e adicionar uma plataforma é apenas uma sobrecarga que você deveria evitar.

Continue apenas com o Kannel ou o Jasmin se você opera como tenant único, sem clientes para faturar. Se você está conectando um dos seus próprios sistemas a uma única operadora e não há hierarquia de revendedores, nem isolamento por cliente, nem fatura a emitir, um bearer com alguns scripts é a resposta correta e econômica, e uma plataforma completa é um peso de que você não precisa. Continue com ele se desenvolver e manter esse software é de fato o seu negócio, e não uma distração dele, porque algumas equipes realmente querem controlar cada camada e têm tempo de engenharia para mantê-las. E continue com ele enquanto ainda está comprovando que existe demanda, já que um gateway baseado em arquivos de configuração é uma boa forma de conduzir um primeiro piloto antes de investir em ferramentas.

O critério é o mesmo que orienta toda decisão honesta entre desenvolver ou comprar em mensageria: construir a camada de faturamento, multi-tenant e portais é o seu produto, ou são de seis a doze meses de trabalho entre você e a venda para clientes? Responda isso primeiro. Se a resposta é que você quer vender mensageria, e não escrever software de gateway, a alternativa que você procura não é um substituto para o Kannel. É uma plataforma que trabalha com ele.