# O que é vendor lock-in em plataformas de IoT e como evitar?

> Vendor lock-in é o custo de sair de uma plataforma IoT. As quatro superfícies onde ele se acumula (dados, provisionamento e decodificação, lógica da aplicação, condições comerciais), o teste de saída para rodar antes de assinar e o que é portabilidade honesta.

![O que é vendor lock-in em plataformas de IoT e como evitar?](https://tago.io/og/pt-br/blog/vendor-lock-in-in-iot-platforms.png)

Ninguém escolhe uma plataforma IoT planejando sair dela. Você escolhe para colocar algo no ar e, quanto mais rápido ela deixa você construir, mais fundo ela se assenta na sua arquitetura: decodificadores de dispositivo, dashboards, scripts de automação, regras de alerta, gestão de usuários. Cada peça economiza semanas. Mas cada peça também é um fio de dependência, e os fios somam um número que ninguém cita na assinatura: o custo de sair.

Esse custo é o vendor lock-in, e ele fica invisível até um aumento de preço, uma aquisição ou um roadmap travado forçarem a pergunta sobre o que uma migração exigiria. A resposta vive em quatro superfícies específicas, e todas as quatro podem ser testadas antes de assinar qualquer coisa.

![As quatro superfícies onde o lock-in se acumula: dados e como eles saem, provisionamento e decodificação, lógica da aplicação e condições comerciais](https://tago.io/images/blog/vendor-lock-in-in-iot-platforms/vendor-lock-in-four-surfaces.svg)

## Superfície um: seus dados e como eles saem

Dados são a superfície óbvia e ainda a mais mal tratada, porque ela se divide em duas perguntas que as pessoas tratam como uma.

A primeira é de propriedade: o contrato declara com clareza que os dados são seus e que o fornecedor é um operador que os trata em seu nome? A segunda é de mecânica: você consegue exportar tudo, em formato documentado, por uma API que não estrangula leituras em massa até a inutilidade?

Um fornecedor pode conceder a propriedade no papel e ainda assim manter o seu histórico como refém na prática, porque cinco anos de séries temporais atrás de um endpoint com rate limit é um sequestro com passos extras. 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 leitura direta. Pergunte se a exportação cobre os payloads brutos dos dispositivos ou só os valores agregados que o dashboard mostra. Pergunte sobre limites de linhas, janelas de tempo e quanto custa puxar anos de dados de uma vez.

Cobrimos a metade contratual em [de quem são os seus dados de IoT](https://tago.io/blog/who-owns-your-iot-data-residency-gdpr). A metade mecânica é algo que você verifica em uma conta de teste, não em uma conversa de vendas. Essa é a superfície para brigar com mais afinco, porque é a única que piora quanto mais tempo você fica.

## Superfície dois: provisionamento de dispositivos e decodificação de payload

Seus dispositivos falam binário. Em algum lugar, um código transforma esses payloads em leituras de temperatura e estados de porta, e onde esse código mora define o quanto a sua frota é portátil.

Se os decodificadores são uma caixa preta dentro da plataforma, cada tipo de dispositivo que você integra aprofunda a dependência, porque migrar significa reescrever uma lógica de decodificação que você não consegue ver, um modelo de cada vez. O provisionamento funciona igual: se adicionar um dispositivo exige ferramenta proprietária sem equivalente por API, registrar de novo milhares de unidades em outra plataforma vira projeto manual em vez de script.

A camada de transporte importa tanto quanto. O MQTT é o protocolo aberto comum para telemetria: é publicado, largamente implementado, e o seu dispositivo o fala do mesmo jeito para qualquer broker. Para redes de sensores de longo alcance, o LoRaWAN faz o mesmo papel, com as camadas de network e application server definidas por uma especificação aberta e não por uma empresa. Um dispositivo que fala MQTT puro ou está em uma 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 pode, e regravar firmware em uma frota implantada não é migração, é recall.

Procure decodificadores que você consiga ler e copiar, escritos em linguagem padrão, e provisionamento que funcione de ponta a ponta por uma API documentada.

## Superfície três: lógica da aplicação amarrada a serviços proprietários

Esta é a superfície que a engenharia subestima. Dashboards se reconstroem em uma semana; a lógica por trás deles é o investimento de verdade.

Regras de alerta, tarefas agendadas, transformações de dados e integrações com terceiros se acumulam ao longo de anos e, se foram escritas contra abstrações proprietárias sem equivalente padrão, são a parte da migração que você reescreve do zero.

Você não elimina essa superfície, e não deveria tentar, porque uma plataforma que não oferece serviços nativos não está oferecendo muito. O que você pode fazer é preferir plataformas em que a camada de lógica é código comum, JavaScript ou Python que você copia para um repositório, em vez de comportamento preso dentro de um construtor visual que não exporta nada. A pergunta relacionada é a cobertura da API: se o único jeito de tirar ou colocar dados é pelas telas do fornecedor, todo fluxo de que você vier a precisar já tem de existir como funcionalidade, ou você espera pelo roadmap.

## Superfície quatro: condições comerciais que taxam a saída

As três primeiras superfícies são técnicas. A quarta está escrita no contrato, e costuma ser a mais afiada.

Taxas de egresso que cobram a exportação de dados por gigabyte transformam o seu próprio histórico em um pedido de resgate. Prazos de vários anos com renovação automática e janela de cancelamento de 90 dias significam que a porta de saída fica aberta algumas semanas por ano. Descontos condicionados a exclusividade elevam o custo de rodar uma segunda plataforma em paralelo, que é como migrações cuidadosas de fato acontecem. Preço por dispositivo que pune o crescimento também entra aqui.

Nada disso está escondido. Está no pedido e no contrato-mestre, e o erro é ler esses documentos como uma compra e nunca como uma saída. Pergunte qual é o prazo de aviso e se o seu acesso à exportação sobrevive ao fim do contrato. Uma exportação que você perde no dia em que a assinatura vence não é portabilidade. Se você revende a plataforma, a mesma disciplina vale uma camada abaixo, que é [o que um SLA de revenda precisa acertar](https://tago.io/blog/sla-reselling-iot-platform).

## Teste a saída antes de assinar

Toda demonstração de plataforma mostra o caminho de entrada. Seu trabalho durante a avaliação é percorrer o caminho de saída, enquanto a sua posição de negociação é a mais forte e o seu volume de dados é o menor.

Abra uma conta de teste, carregue algumas semanas de dados reais de dispositivo e então rode um exercício de saída de verdade: exporte todas as leituras pela API pública, puxe o decodificador de um tipo de dispositivo e recrie uma regra de alerta fora da plataforma. Cronometre cada passo e multiplique pelo tamanho da sua frota em produção. Se o fornecedor não conseguir apoiar esse exercício na escala de teste, você já tem a sua resposta pelo preço mais baixo possível.

E aproveite para pedir por escrito o preço de egresso e as condições de rescisão, porque um número dito em uma ligação não é cláusula de contrato.

## A troca honesta: código aberto que você mesmo hospeda

Se o lock-in é o inimigo, a opção de menor lock-in é software de código aberto que você roda por conta própria. O ThingsBoard é o mais conhecido, e o TagoCore é o nosso runtime de borda de código aberto. Você detém o código, o banco de dados e a implantação. Ninguém muda as suas condições, descontinua o seu plano ou retém os seus dados, porque tudo isso fica em infraestrutura que você controla.

Essa liberdade tem um preço, e ele não é em dinheiro. Quando você hospeda, você é dono da operação. Você aplica patches nos servidores, escala o banco quando a contagem de dispositivos sobe, resolve a queda das 3 da manhã, carrega a postura de segurança. O lock-in que você removeu é substituído por um peso operacional que agora é do seu time. Para algumas organizações com profundidade de engenharia e apetite, essa é a troca certa. Para a maioria, não é, e fingir o contrário não ajuda ninguém. Vale rodar a [comparação completa de custos](https://tago.io/blog/open-source-vs-managed-iot-platforms) antes de decidir.

Então a pergunta real não é "gerenciado ou código aberto". É "quais tipos de lock-in eu aceito em troca de outra pessoa operar a plataforma". Toda plataforma gerenciada carrega algum lock-in. O objetivo é minimizar os tipos caros, seus dados e seus dispositivos, e aceitar o resto como o custo de não operar infraestrutura.

## Como é a portabilidade honesta

Nenhuma plataforma consegue prometer uma saída gratuita, e todo fornecedor que alega custo zero de troca está vendendo algo. O que uma plataforma honesta consegue é manter o custo proporcional, e a forma dessa honestidade é reconhecível:

- APIs de cobertura total, ou seja, tudo o que a interface faz está disponível por programação, então uma saída pode ser roteirizada em vez de clicada.
- Protocolos padrão nas bordas, MQTT para o tráfego de dispositivos e LoRaWAN por network servers abertos, então os dispositivos são reapontados e não regravados.
- Decodificadores como código visível e exportável.
- Um compromisso escrito de que os dados são seus, com exportação sem cobrança punitiva.

Essas são as posições sobre as quais a TagoIO se constrói. A TagoIO é uma plataforma gerenciada, o que significa que ela não tem lock-in zero, e preferimos dizer isso claramente a enfeitar. O que fazemos é empurrar o lock-in para os tipos que doem menos: a plataforma é totalmente acessível por API, os dispositivos conectam por protocolos padrão incluindo MQTT e LoRaWAN, os payload parsers são JavaScript comum que você lê e copia, e a posição sobre propriedade dos dados é publicada em vez de negociada caso a caso. A plataforma é multi-tenant e roda o TagoRUN para implantações white-label, tem certificação ISO 27001 e alinhamento com o GDPR, e a mesma abordagem de protocolos abertos se estende à borda pelo TagoCore, que é de código aberto se você quiser rodar essa parte por conta própria.

Você continua em um 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 amarra de firmware que transforme a saída em uma reconstrução. Preferimos ser escolhidos de novo em cada renovação a segurar alguém no lugar.

## Próximos passos

Antes de se comprometer com qualquer plataforma IoT, rode as quatro superfícies contra ela: formato de exportação e rate limits, decodificadores e provisionamento, onde a lógica mora, condições de saída. Depois confira as respostas contra a própria plataforma.

- Veja como conectividade de dispositivos e dados funcionam na [TagoIO](https://tago.io)
- Leia os detalhes de API e integração na [documentação da TagoIO](https://docs.tago.io)
- Compare planos e custos por dispositivo nos [preços da TagoIO](https://tago.io/pricing)

Lock-in não é motivo para evitar plataformas. Construir tudo sozinho só move a dependência para o seu próprio backlog. É motivo para precificar a saída enquanto perguntar ainda é barato. [Agende uma demonstração](https://tago.io/request-demo) ou [comece grátis](https://admin.tago.io) e rode o teste de saída com a gente.

[llms.txt](https://tago.io/llms.txt)