Todo projeto de IoT começa com uma decisão de plataforma que parece reversível. Você escolhe um fornecedor, conecta alguns dispositivos, monta um dashboard e coloca no ar. Dois anos depois você tem dez mil dispositivos reportando, um build de firmware customizado preso a uma única cloud e três anos de dados históricos que não consegue tirar de lá em nenhum formato aproveitável. A decisão nunca foi reversível. Ela só parecia, lá no começo, e essa distância entre como parecia e como realmente era é exatamente onde mora o vendor lock-in.
Lock-in não é uma armadilha única. São quatro armadilhas separadas, e a maioria dos compradores verifica só uma delas antes de assinar. Este artigo destrincha cada tipo, te dá a pergunta concreta para fazer ao fornecedor e testar cada uma, e é honesto sobre o fato de que o único jeito de chegar perto de zero lock-in é assumir um trabalho que talvez você não queira.
Lock-in de dados é o caro
Seus dados históricos são o ativo que cresce todo dia e a coisa mais difícil de mover. Se uma plataforma guarda sua telemetria em um formato proprietário e só te deixa ler de volta pelo próprio dashboard, você não é dono desses dados em nenhum sentido prático. Você consegue ver. Não consegue ir embora com eles.
A pergunta de teste: “Posso exportar todos os meus dados históricos brutos, e em qual formato?” Vá além da resposta de marketing. Um “sim, você pode exportar seus dados” vago não é a mesma coisa que uma exportação em massa documentada para CSV, JSON ou uma leitura direta do banco de dados. Pergunte se a exportação cobre os payloads brutos dos dispositivos ou só os valores agregados que o dashboard por acaso mostra. Pergunte se há limite de linhas ou janela de tempo. Pergunte quanto custa puxar anos de dados de uma vez, porque para grandes volumes a transferência e o tempo de engenharia para reformatar tudo podem virar a conta de verdade.
Lock-in de dados é o que você deve combater com mais força, porque é o único tipo que piora quanto mais tempo você fica.
Lock-in de dispositivo e protocolo decide se o seu hardware é portátil
Se uma plataforma exige o próprio firmware, o próprio SDK ou um protocolo de transporte fechado para colocar um dispositivo online, o seu hardware fica casado com aquela plataforma. Troque de cloud e você reflasha cada unidade em campo, o que numa frota implantada não é uma migração, é um recall.
A pergunta de teste: “Meu dispositivo conecta por padrões abertos, ou eu preciso do firmware de vocês?” Protocolos abertos são o que mantém os dispositivos portáteis. MQTT é o mais comum para telemetria: é publicado, amplamente implementado e o seu dispositivo fala da mesma forma com qualquer broker. Para redes de sensores de longo alcance, o LoRaWAN faz o mesmo papel, com as camadas de network server e application server definidas por uma especificação aberta, e não por uma única empresa. Um dispositivo que fala MQTT puro ou está numa rede LoRaWAN padrão pode ser apontado para um novo endpoint com uma mudança de configuração em vez de uma visita a campo. Um dispositivo que só fala o protocolo proprietário de um fornecedor, não.
Lock-in de integração é sobre conseguir construir em volta da plataforma
Uma plataforma que você não consegue programar é uma plataforma da qual você não consegue crescer além. Se o único jeito de entrar ou tirar dados é pelas telas do próprio fornecedor, todo fluxo de trabalho que você um dia precisar já tem que existir como recurso, ou você fica refém de um roadmap.
A pergunta de teste: “Existe uma API REST documentada que cobre tudo que o dashboard faz, ou só parte?” A versão honesta dessa pergunta importa. Muitas plataformas têm uma API que lê dados mas não consegue provisionar um dispositivo, ou uma que cuida de dispositivos mas não de gestão de usuários. Você quer cobertura completa: criar dispositivos, enviar e puxar dados, gerenciar usuários, configurar as coisas que de outra forma você clicaria. Se a API é um subconjunto do produto, o resto do produto é um muro.
Lock-in contratual é o que está escrito em bom português
O último tipo não tem nada de técnico. É o prazo de vigência, a cláusula de renovação automática, o preço por dispositivo que pune o crescimento e o tier de suporte que você precisa comprar para manter as luzes acesas. Nada disso fica escondido. Está no contrato, e é por isso que é o mais fácil de checar e o mais frequentemente ignorado.
A pergunta de teste: “Qual é o prazo de aviso prévio para sair, e o meu acesso à exportação sobrevive ao fim do contrato?” Um recurso de exportação que você perde no dia em que a assinatura vence não é portabilidade. Leia os termos de saída antes dos termos de entrada.
A troca honesta: open source que você mesmo hospeda
Se lock-in é o inimigo, a opção de menor lock-in é software open source que você roda por conta própria. O ThingsBoard é o mais conhecido, e o TagoCore é o nosso próprio runtime de edge open source. Você é dono do código, do banco de dados e do deployment. Ninguém pode mudar seus termos, descontinuar seu plano ou reter seus dados, porque tudo isso fica numa infraestrutura que você controla.
Essa liberdade tem um preço, e ele não está em dólares. Quando você mesmo hospeda, você é dono da operação. Você aplica os patches nos servidores, você escala o banco de dados quando a contagem de dispositivos sobe, você lida com a queda às 3 da manhã, você carrega a postura de segurança. O lock-in que você removeu é substituído por um peso operacional que agora pertence à sua equipe. Para algumas organizações com profundidade de engenharia e apetite para isso, essa é a troca certa. Para a maioria, não é, e fingir o contrário não ajuda ninguém.
Então a pergunta de verdade não é “gerenciada ou open source”. É “quais tipos de lock-in eu estou disposto a aceitar em troca de outra pessoa rodar a plataforma”. Toda plataforma gerenciada carrega algum lock-in. Essa é a natureza de um serviço gerenciado. O objetivo é minimizar os tipos caros, os seus dados e os seus dispositivos, e aceitar o resto como o custo de não rodar infraestrutura.
Onde a TagoIO se encaixa
A TagoIO é uma plataforma gerenciada. Isso significa que não é zero lock-in, e preferimos dizer isso com todas as letras a maquiar a coisa. O que fazemos é empurrar o lock-in para os tipos que doem menos.
Nos dados, a TagoIO permite exportar suas informações, então seu histórico não fica numa caixa de mão única. Nos dispositivos, ela fala MQTT e funciona com dados de dispositivos LoRaWAN padrão, então o seu hardware não fica preso a um build de firmware proprietário para conversar com a gente. Na integração, há uma API REST completa que cobre o que a plataforma faz, então você pode construir, provisionar e automatizar em volta dela em vez de esperar por uma solicitação de recurso. A plataforma é multi-tenant e roda o TagoRUN para deployments white-label, é certificada ISO 27001 e alinhada ao GDPR, e a mesma abordagem de protocolo aberto se estende até o edge através do TagoCore, que é open source caso você queira rodar essa parte por conta própria.
Você ainda está num serviço gerenciado, e ainda existe um custo de troca se você sair. O que não existe é um formato de dados fechado ou uma trava de firmware que transforma a saída numa reconstrução.
Próximos passos
Antes de se comprometer com qualquer plataforma de IoT, rode as quatro perguntas de teste contra ela: formato de exportação, protocolos abertos, API completa, termos de saída. Depois confira as respostas contra a própria plataforma.
- Veja como a conectividade de dispositivos e os dados funcionam na TagoIO
- Leia os detalhes de API e integração na documentação da TagoIO
- Compare planos e custos por dispositivo na página de preços da TagoIO
Uma plataforma que dá respostas claras às quatro perguntas é uma plataforma que você pode deixar. E é exatamente por isso que você deve se sentir seguro para ficar.
