A maioria dos orçamentos de IoT é montada da mesma forma. Alguém conta os dispositivos, cota um sensor, soma um plano de SIM, multiplica pelo tamanho da frota e ainda acrescenta vinte por cento de folga por segurança. A diretoria vê um número limpo. O projeto é aprovado. Todo mundo fica satisfeito.
Esse número está quase sempre errado. Não porque o preço do sensor esteja errado, mas porque o sensor é uma das partes mais baratas de tudo isso.
Se você é um gerente de projeto responsável por um resultado de IoT, os custos que estouram seu orçamento não estão na nota fiscal do hardware. São os custos que ninguém te cota de antemão, porque eles vivem em horas de engenharia, em taxas de plataforma que crescem com o uso e no gotejamento lento da manutenção depois do lançamento. Este artigo é um mapa completo do custo total de propriedade. Quero que você consiga defender seu orçamento linha a linha e saiba exatamente onde uma plataforma gerenciada elimina custo e onde ela não elimina.
A parte que todo mundo coloca no orçamento
Vamos começar pelo dinheiro fácil, a parte que você já tem sob controle.
Hardware é real e é visível. Um projeto mid-market pode ter de algumas centenas a alguns milhares de dispositivos. Você vai cotar o sensor ou gateway, vai cotar o SIM ou o módulo de conectividade, e vai conseguir orçamentos razoavelmente precisos dos fornecedores. Pode haver um acréscimo por carcaças reforçadas ou certificações específicas, mas hardware é uma quantidade conhecida. Você consegue três orçamentos e escolhe um.
A conectividade por dispositivo parece pequena no nível unitário. Alguns dólares por mês por SIM, ou uma tarifa fixa para um plano LoRaWAN ou NB-IoT. Os PMs orçam isso corretamente por dispositivo.
Essas duas linhas são onde a maioria dos orçamentos deixa de ser precisa. Elas são a ponta visível. É abaixo da linha d’água que os projetos afundam.
Os custos sobre os quais ninguém te avisa
Aqui está a lista incômoda. Cada um destes itens é real, recorrente ou pontual, e costuma ser deixado de fora do primeiro orçamento.
Taxas de plataforma e de ingestão
Seus dispositivos enviam dados para algum lugar. Esse algum lugar custa dinheiro, e geralmente o custo cresce com o número de mensagens, não com o número de dispositivos. Um dispositivo que reporta a cada quinze minutos envia cerca de 2.880 mensagens por dia. Em mil dispositivos, isso dá quase três milhões de mensagens por dia. Um preço que cresce por mensagem ou por ponto de dado pode subir mais rápido que sua contagem de dispositivos, porque no momento em que alguém pede “leituras mais frequentes”, seu volume de ingestão dispara sem que um único dispositivo novo seja instalado.
Esse é um custo recorrente. Coloque-o no orçamento mensal, e orce contra seu intervalo real de reporte, não contra o intervalo da demonstração.
Parsing de payload e engenharia de integração
Esta é a linha que mais surpreende as pessoas. Seu dispositivo não envia dados limpos e rotulados. Ele envia um payload binário compacto, muitas vezes em hex, projetado para manter a transmissão de rádio curta e a vida da bateria longa. Alguém precisa escrever um código que transforme esse payload em “temperatura: 4,2 graus, bateria: 87 por cento, porta: aberta”.
Esse alguém é um engenheiro, e cada modelo de dispositivo tem uma estrutura de payload diferente. Troque de fornecedor, adicione um novo tipo de sensor ou receba uma atualização de firmware que muda a ordem dos bytes, e você vai pagar por esse trabalho de novo. Depois há a integração na outra direção, empurrando seus dados para os sistemas em que sua empresa de fato opera, o ERP, o CMMS, o sistema de chamados, a plataforma de cobrança. Cada integração é engenharia sob medida, e o trabalho de integração é onde os cronogramas escorregam silenciosamente por semanas.
Esse é, em sua maior parte, um custo pontual por tipo de dispositivo e por integração, com uma cauda recorrente de manutenção.
Construção de dashboards e aplicações
Os dados precisam se tornar algo que um ser humano olha e sobre o qual age. Um dashboard, uma regra de alerta, um relatório, uma visão mobile para o técnico em campo. Isso é trabalho de produto de verdade. É design, é frontend, é o vai e vem do “será que dá pra mostrar também a tendência da semana passada”. Subestimar o orçamento aqui é comum porque parece a parte fácil. Não é. A aplicação é a parte que seus usuários de fato tocam, e é a parte que eles vão pedir para você mudar todo mês.
Conectividade em escala
A conectividade é barata por dispositivo e cara no agregado. Além do custo por SIM, há a questão do que acontece quando mil dispositivos tentam se reconectar todos ao mesmo tempo depois de uma queda de rede, ou quando seu volume de dados cruza um patamar e sua tarifa muda. Provedores de conectividade têm degraus e cobranças por excedente. Em pequena escala, você nunca os vê. Em escala mid-market, você vai ver.
Egress de dados
Este se esconde bem. Mover dados para fora de uma cloud, entre regiões ou para um sistema de terceiros muitas vezes carrega uma cobrança de egress por gigabyte. É invisível durante um piloto com dez dispositivos. Com uma frota completa enviando continuamente, o egress vira uma linha que você de fato percebe na fatura mensal.
Manutenção e suporte contínuos
Software nunca está pronto. Patches de segurança, atualizações de bibliotecas, mudanças de API do seu provedor de conectividade, um novo modelo de dispositivo que precisa de onboarding, uma regra de alerta que precisa de ajuste. Se você mesmo construiu a stack, isso é o tempo da sua equipe de engenharia, para sempre. Se algo quebra às 2 da manhã, alguém está de plantão. A manutenção é o custo recorrente mais subestimado em IoT, porque na hora do orçamento o sistema ainda não existe e ninguém está pensando no segundo ano.
Tempo da equipe
Cada hora que sua equipe gasta na stack de IoT é uma hora que não foi gasta no produto que sua empresa de fato vende. Um PM coordenando, um engenheiro fazendo parsing de payloads, uma pessoa de ops observando dashboards. Isso é um custo real mesmo quando não aparece como uma nota fiscal, e é o custo que seu time de finanças vai questionar quando vir o headcount.
Degraus de escala
Os custos em IoT não são suaves. Eles dão saltos. Você adiciona o centésimo dispositivo e nada muda. Você adiciona o milésimo e de repente precisa de um tier de banco de dados maior, um load balancer, uma segunda região, um contrato de suporte dedicado. Esses degraus chegam sem aviso e geralmente na pior hora, justo quando o projeto está dando certo e a liderança quer expandir.
Pontual versus recorrente, em termos simples
Separe os custos em dois baldes e o quadro fica mais claro.
Custos pontuais: hardware, parsing inicial de payload por tipo de dispositivo, primeira construção de cada integração, a construção inicial do dashboard e da aplicação, e a configuração e o setup da plataforma.
Custos recorrentes: conectividade por dispositivo, taxas de plataforma e de ingestão, egress de dados, manutenção e suporte contínuos, tempo da equipe e os degraus de escala que viram novos tiers recorrentes.
O erro que mata orçamentos é tratar custos recorrentes como se fossem pontuais. A construção é um momento. A operação é para sempre. Um projeto que parece acessível como uma construção pontual pode virar um problema quando o segundo e o terceiro ano chegam com todo o seu peso recorrente e nenhum valor novo para mostrar à diretoria.
O custo de errar
Há mais um custo, e ele é o maior de todos. É o custo de um projeto que fracassa ou empaca.
Um projeto que atrasa seis meses porque a engenharia de integração foi subestimada não custa só a engenharia extra. Custa o valor adiado que o projeto deveria entregar, a credibilidade da equipe que o prometeu e, às vezes, o apetite da empresa de tentar IoT de novo. O projeto de IoT mais caro é aquele que você precisa reconstruir porque a primeira versão não conseguiu escalar nem ser mantida.
Essa é a verdadeira razão para mapear os custos com honestidade. Não para deixar o número menor, mas para deixá-lo verdadeiro, de modo que o projeto sobreviva ao contato com o segundo ano.
Plataforma gerenciada versus DIY na AWS
Aqui está a comparação que de fato decide o orçamento.
Se você constrói diretamente sobre infraestrutura de cloud crua, você monta as peças sozinho. Um message broker, um banco de dados, um motor de regras, dashboards, gestão de usuários e o código de cola entre tudo isso. Você é dono de cada linha. Você também é dono de cada patch, cada degrau de escala e cada chamado às 2 da manhã. A conta de infraestrutura pode parecer baixa, mas a folha de pagamento da engenharia é o custo real, e ele nunca para.
Uma plataforma de IoT gerenciada como a TagoIO elimina a maior parte do custo oculto de engenharia. A ingestão, o armazenamento, a gestão de dispositivos, a gestão de usuários e tenants, os dashboards e os alertas já estão construídos e já são mantidos. O parsing de payload é resolvido com uma camada configurável em vez de um serviço sob medida que você mantém para sempre. Você pode ver como o parsing e a estrutura de dados funcionam na documentação da TagoIO. O preço é previsível e atrelado a um uso que você consegue modelar com antecedência, que você pode conferir na página de preços da TagoIO.
A troca é direta. Com uma plataforma gerenciada você paga uma taxa recorrente mais clara e deixa de pagar pela equipe de engenharia que de outra forma construiria e manteria o encanamento. Para um projeto mid-market, em que você tem de algumas centenas a alguns milhares de dispositivos e uma equipe pequena, essa troca quase sempre favorece a plataforma gerenciada. O custo oculto de engenharia é a coisa que ia quebrar seu orçamento, e é exatamente esse custo que uma plataforma gerenciada tira do seu colo.
Quando a TagoIO é a escolha errada
Não vou fingir que a plataforma gerenciada vence sempre, porque não vence.
Se você já opera uma grande equipe interna de engenharia de cloud, precisa de controle total da infraestrutura e está rodando com contagens de dispositivos muito altas, construir diretamente sobre o AWS IoT Core pode sair mais barato em escala. Em um volume alto o suficiente, a economia por mensagem da infraestrutura crua supera o preço de uma plataforma gerenciada, e se você já emprega os engenheiros que a manteriam, você não está adicionando esse custo, você já o carrega. Nessa situação, o AWS IoT Core é a escolha racional, e você deve escolhê-lo com o mesmo orçamento de olhos abertos que este artigo defende.
A linha divisória é honesta e simples. Se sua escala é mid-market e sua equipe é pequena, o custo oculto de engenharia é seu inimigo e uma plataforma gerenciada o elimina. Se sua escala é muito grande e você já tem uma equipe de engenharia de cloud, a infraestrutura crua pode vencer na economia unitária. A maioria dos projetos mid-market está firmemente no primeiro grupo, e é por isso que as plataformas gerenciadas existem.
O que fazer com isso
Monte seu orçamento em duas colunas, pontual e recorrente, e coloque cada linha deste artigo em uma delas. Use seu intervalo real de reporte, não o intervalo da demonstração. Orce a manutenção para o segundo e o terceiro ano, não só para a construção. Depois rode a comparação entre gerenciada e DIY contra sua contagem real de dispositivos e o tamanho real da sua equipe.
Se você fizer isso, vai entrar na reunião de orçamento com um número que consegue defender linha a linha. E quando o segundo ano chegar, o projeto ainda vai estar de pé.
