Plataformas IoT Industriales
Compose on AWS (Managed Services) vs ThingsBoard
Alejandro Alija
Socio fundador y director de GALEO
Febrero 2026 — v4.1
1. Contexto
Este documento analiza dos enfoques para construir una plataforma IoT industrial: componer sobre servicios gestionados de AWS («Compose on AWS») frente a adoptar ThingsBoard (TB) como plataforma integral. El análisis incorpora experiencia real operando ThingsBoard en entornos industriales y datos de proyectos ejecutados con arquitecturas serverless en AWS.
Qué significa «Compose on AWS»
No es construir una plataforma IoT desde cero. Es orquestar servicios gestionados de AWS que ya resuelven cada capa del stack: AWS IoT Core para conectividad MQTT, DynamoDB/S3 para almacenamiento, Lambda para lógica de negocio, API Gateway para APIs, Cognito para autenticación, y Tinybird o QuickSight para analítica. El desarrollo custom se limita a la lógica de negocio específica del dominio y al frontend.
Qué es ThingsBoard
Plataforma IoT open source (Community Edition, Apache 2.0) con ediciones comerciales (Professional y Enterprise). Incluye device management, dashboards, rule engine, alertas, multi-tenancy y white-labeling. +8 años de desarrollo, miles de despliegues en producción.
Aplicabilidad a otras plataformas similares
Aunque este análisis se centra en ThingsBoard como representante del enfoque «plataforma IoT integral», las conclusiones son extensibles a plataformas de arquitectura y modelo de negocio similar, como Thinger.io. Thinger.io comparte con TB el mismo patrón: edición community open source, ediciones comerciales con licenciamiento por dispositivos/funcionalidades, despliegue self-hosted o cloud, dashboards integrados, y un motor de reglas visual. Los trade-offs fundamentales descritos en este documento — coste oculto del self-hosted, limitaciones del no-code a escala, dependencia del broker MQTT, y complejidad operativa — aplican de manera análoga a Thinger.io y a otras plataformas IoT del mismo segmento. De la misma manera, existen otras plataformas de IoT con este enfoque como Cumulocity, Datacake, Losant, etc.
2. ThingsBoard: Modos de Despliegue y Licenciamiento
Un punto crítico que a menudo se subestima es que TB no es un único producto con un único precio. Existen múltiples combinaciones de edición + despliegue + add-ons que impactan radicalmente el coste y la complejidad:
2.1 Public Cloud (SaaS)
ThingsBoard Cloud, disponible en EU y NA. Managed por el equipo de TB.
| Aspecto | Detalle |
|---|---|
| Modelo | SaaS puro. Conectas dispositivos y listo. |
| Planes | Free → Maker ($10/mes) → Prototype ($149/mes) → Startup ($399/mes) → Business → Business+ |
| Infra | Gestionada por TB. Sin preocupaciones operativas. |
| Limitaciones | Recursos compartidos. Sin control de infra. Regiones limitadas (EU/NA). Datos en servidores de TB. |
| Ideal para | PoCs, pilotos, startups. Proyectos con requisitos estándar. |
2.2 Private Cloud (Managed)
Cluster dedicado gestionado por TB. Kubernetes con load balancers.
| Aspecto | Detalle |
|---|---|
| Modelo | Cluster dedicado, managed. Planes: Launch → Growth → Scale → Enterprise. |
| Infra | AWS como IaaS preferido (Azure/GCP bajo petición). TB gestiona el cluster. |
| Coste | Significativamente mayor que Public Cloud. Pricing bajo petición (contactar ventas). |
| Ventajas | SLA garantizado, aislamiento, migración asistida desde Public Cloud o self-hosted. |
| Ideal para | Empresas que necesitan aislamiento pero no quieren operar la infra. |
2.3 Self-Hosted (Pay-as-you-go o Perpetua)
El cliente despliega y opera TB en su propia infraestructura.
| Aspecto | Detalle |
|---|---|
| Licencia | Pay-as-you-go (suscripción) o Perpetua (~$3K+ one-time, $1.2K/año updates). |
| Infra necesaria | Mínimo: EC2 (m5.large ~$42/mes) + PostgreSQL. Producción: EKS + RDS + ElastiCache + MSK (Kafka). |
| Coste infra (producción) | $1,000 – $1,800/mes para un cluster con HA (2x TB nodes, Kafka, Redis, RDS Multi-AZ). |
| Operación | El cliente (o su partner) es responsable de updates, backups, monitoring, scaling. |
| Ideal para | Empresas con equipo DevOps, requisitos de data sovereignty, o despliegue air-gapped. |
[!] El coste oculto del self-hosted: TB self-hosted en producción no es «instalar y olvidar». Necesita EC2/EKS + PostgreSQL (o Cassandra para alto throughput) + Kafka + Redis. Un cluster de producción con HA en AWS cuesta fácilmente $1,500-$2,000/mes solo en infraestructura, sin contar la licencia PE, el equipo de operaciones, ni los add-ons.
2.4 Comparativa de costes de despliegue TB
| Concepto | Public Cloud | Private Cloud | Self-Hosted |
|---|---|---|---|
| Licencia TB PE | Incluida en plan | Incluida en plan | $3K+ perpetua o suscripción |
| Infra /mes | $0 (incluida) | Alto (dedicado, bajo petición) | $1,000-$1,800 (EC2/EKS+RDS+Kafka+Redis) |
| Operación | TB la gestiona | TB la gestiona | El cliente la gestiona |
| Escalado | Automático (dentro del plan) | Gestionado por TB | Manual (planificación de capacidad) |
| Data sovereignty | Servidores TB (EU/NA) | Región a elegir | Control total |
| HA / SLA | Según plan | SLA dedicado | Responsabilidad del cliente |
3. La Capa MQTT: Cómo Funciona Realmente en ThingsBoard vs AWS IoT Core
Este es un punto que muchos análisis omiten y que tiene implicaciones directas en arquitectura, costes y responsabilidades operativas. La documentación oficial de TB Professional lo explica claramente, pero las implicaciones pasan desapercibidas.
3.1 Cómo funciona realmente la integración MQTT en TB Professional
Un malentendido frecuente es asumir que ThingsBoard «incluye» un broker MQTT completo. La realidad es distinta. TB Professional ofrece una funcionalidad llamada MQTT Integration que, según la propia documentación de TB, funciona así:
- TB se conecta como cliente MQTT a un broker externo que el usuario debe proveer.
- En el sentido uplink: TB se suscribe a los topics del broker externo, recibe los mensajes y los convierte en telemetría y atributos de dispositivos internos de TB.
- En el sentido downlink: TB convierte los comandos destinados a dispositivos al formato adecuado y los publica de vuelta en el broker externo.
- Requisito de red: El broker MQTT externo debe estar co-localizado con la instancia de TB o desplegado en la nube con un nombre DNS válido y una IP estática accesible. TB en cloud no puede conectarse a un broker MQTT en una red local sin configuración de red adicional.
Esto significa que en TB Professional, la arquitectura real en producción es:
Dispositivos → [Broker MQTT externo] → TB Professional (como cliente MQTT)
← TB Professional (downlink commands)
TB no es el broker. TB es un consumidor/productor más conectado a un broker que el cliente debe provisionar, operar y mantener. Las implicaciones son significativas:
- El cliente es responsable de la disponibilidad, escalado, seguridad y mantenimiento del broker MQTT externo.
- El broker es una pieza de infraestructura adicional con su propio coste (licencias si es comercial como EMQX o HiveMQ, infraestructura para ejecutarlo, operación).
- Si el broker falla, TB deja de recibir datos. Es un single point of failure externo a la plataforma.
- La configuración de la integración MQTT en TB tiene sus propias limitaciones y complejidad (mapeo de topics, conversión de formatos, gestión de credenciales).
En resumen: ThingsBoard Professional no incluye un broker MQTT. Requiere un broker externo al que TB se conecta como cliente. El cliente asume la responsabilidad completa de esa pieza de infraestructura, o bien contrata TBMQ como producto adicional con su propia licencia.
3.2 TBMQ (ThingsBoard MQTT Broker)
TBMQ es el producto separado de ThingsBoard Inc. que resuelve la necesidad del broker externo. Es un producto aparte con su propia licencia y despliegue.
- Community Edition: Open source, gratuita. Capaz de manejar millones de conexiones en single-node.
- Professional Edition: Licencia separada. Pricing por sesiones + throughput (msg/seg) + instancias. Pricing exacto no público (contactar ventas). Incluye SSO, RBAC, white-labeling.
- Modelo: Suscripción anual o perpetua. Add-ons adicionales.
Cuando se adopta TBMQ, la arquitectura pasa a ser: Dispositivos → TBMQ → TB. Pero TBMQ requiere su propia infraestructura (EC2/EKS, Kafka, PostgreSQL) y operación, sumando al coste total.
3.3 AWS IoT Core: Broker MQTT Nativo e Integrado
En el enfoque Compose on AWS, el problema del broker MQTT simplemente no existe. AWS IoT Core es el broker MQTT, fully managed, sin infraestructura que operar:
- Messaging: $1.00 por millón de mensajes (primeros 1B). Baja a $0.70/M en volúmenes altos.
- Conectividad: ~$0.042/dispositivo/año para conexión 24/7.
- Rules Engine: $0.15 por millón de reglas ejecutadas + $0.15 por millón de acciones disparadas.
- Incluido: Broker MQTT nativo, device shadows, registry, seguridad TLS/X.509.
- Sin licencia separada. Todo pay-per-use.
[!] Importante sobre el coste real de IoT Core: El pricing no es solo por mensajes. Cada mensaje procesado por una IoT Rule genera cargos adicionales de rules + actions. Para 1M mensajes/día con 1 rule y 1 action por mensaje: $30/mes (mensajes) + $4.50/mes (rules) + $4.50/mes (actions) = ~$39/mes total, no $30. Si un mensaje dispara múltiples rules o actions (ej: guardar en DynamoDB + enviar alarma a SNS), el coste de rules/actions se multiplica proporcionalmente. Aun así, sigue siendo una fracción del coste de operar un broker + infra propia.
[>] Tip: Basic Ingest. Si se usa AWS IoT Core como forwarder (Basic Ingest), el coste de entrada de mensajes se elimina y solo se cobran las acciones de forwarding hacia los servicios destino. Dato real de un operador con +1,000 dispositivos y ~400K msgs/día: el coste total de IoT Core con Basic Ingest es mínimo dentro de la factura AWS.
3.4 Comparativa directa
| Dimensión | TB PE (broker externo) | TBMQ PE | AWS IoT Core |
|---|---|---|---|
| ¿Quién es el broker? | Un tercero (Mosquitto, EMQX, HiveMQ…). TB se conecta como cliente. | TBMQ (producto separado de TB Inc.) | AWS IoT Core es el broker |
| Modelo de pricing | Coste del broker elegido + infra propia | Licencia por sesiones + throughput. No público. | Por mensajes. Transparente y público. |
| Quién opera el broker | El cliente o un tercero | El cliente (self-hosted) o TB (cloud) | AWS (fully managed) |
| Coste 10K devices, 1M msgs/día | Infra broker (EC2 + config) + operación | Licencia TBMQ PE + infra (EC2/EKS) | ~$39/mes + ~$1.15/mes conectividad |
| Coste 100K devices, 10M msgs/día | Broker cluster + HA + operación manual | Licencia TBMQ PE escalada + cluster dedicado | ~$390/mes + ~$11.5/mes conectividad |
| ¿TB es autosuficiente? | No. Depende del broker externo. | Sí (TBMQ es el broker) | N/A (IoT Core es el broker) |
| Restricción de red | Broker debe tener DNS/IP pública. TB cloud no conecta a brokers locales. | Mismo requisito si TBMQ está separado | Sin restricciones. Endpoint global de AWS. |
| Infra adicional necesaria | Sí (EC2/instancia para broker) | Sí (EC2/EKS + Kafka + PostgreSQL) | No (fully managed) |
| Escalado | Manual | Manual (añadir nodos) | Automático |
| Offline / Air-gapped | Sí (si el broker lo soporta) | Sí (perpetua) | No |
[>] Nota de experiencia propia: enfoque híbrido TB PE + AWS IoT Core. Hemos implementado arquitecturas donde TB Professional self-managed utiliza AWS IoT Core como broker MQTT externo, combinando la capa de dashboards y rule engine de TB con la escalabilidad y gestión cero del broker de AWS. Es técnicamente viable, pero incrementa significativamente el coste de servicios de ingeniería: la arquitectura resultante es más compleja (dos plataformas que integrar y mantener alineadas), el debugging cruza fronteras entre sistemas, y el equipo necesita dominar tanto el ecosistema TB como AWS. En la práctica, este híbrido hereda los costes de ambos mundos sin eliminar las limitaciones de ninguno — el coste de infraestructura de TB self-hosted se mantiene, y la complejidad operativa se amplifica en lugar de reducirse.
Conclusión: ThingsBoard Professional no resuelve el brokeraje MQTT — lo delega al cliente. TB se conecta como cliente MQTT a un broker externo que hay que provisionar y operar. Con TBMQ PE se añade un producto adicional con licencia opaca e infra propia. Incluso integrando TB con AWS IoT Core como broker, la complejidad y el coste de ingeniería aumentan. AWS IoT Core en un enfoque Compose resuelve este problema de raíz: es el broker MQTT, fully managed, con pricing transparente y escalado automático. El coste total para 1M msgs/día ronda ~$40/mes — una fracción del coste de operar cualquier broker independiente.
4. El Problema de las Rule Chains en ThingsBoard
Este es, basado en experiencia real operando TB en producción, el riesgo más subestimado de adoptar ThingsBoard.
Qué son las Rule Chains
El Rule Engine de TB es un sistema visual de nodos drag & drop que procesa eventos (telemetría, alarmas, lifecycle). Se crean «cadenas de reglas» (rule chains) conectando nodos que filtran, transforman, enrutan y actúan sobre los datos. Es uno de los selling points principales de TB: «lógica sin código».
Por qué se convierten en un problema
En la práctica, las rule chains de TB degeneran en spaghetti no-code a medida que el proyecto crece:
1. Sin versionado ni control de cambios
Las rule chains se configuran exclusivamente por la UI. No existe un formato declarativo que puedas versionar en Git. Si alguien modifica una regla en producción, no hay diff, no hay rollback, no hay audit trail de quién cambió qué y cuándo. La única opción es exportar/importar JSONs manualmente, que no es práctico como workflow de desarrollo.
2. Debugging es una pesadilla
Es técnicamente posible activar logging en las rule chains y redirigirlo a un destino externo (por ejemplo, Datadog). Los logs llegan, pero el problema se traslada: para investigar un fallo hay que construir queries en la herramienta de logs, filtrar por nodo, correlacionar timestamps, y navegar entre eventos dispersos. Esto requiere un perfil técnico que domine tanto el rule engine de TB como la herramienta de observabilidad — algo inmanejable para usuarios no especializados, que son precisamente el público objetivo del «no-code». Para equipos técnicos, si igualmente van a acabar haciendo queries en Datadog, la pregunta es por qué no escribir directamente código con logging estructurado nativo desde el principio. En una cadena con 30+ nodos, ramificaciones y sub-chains, encontrar dónde falla un flujo sigue siendo extraordinariamente tedioso independientemente de la herramienta de logs.
3. Complejidad visual inmanejable
A partir de ~15-20 nodos, el canvas visual se vuelve inmanejable. Las conexiones se cruzan, los nodos se solapan, y la lógica se distribuye en múltiples sub-chains que son difíciles de navegar. No hay «zoom out» conceptual — tienes que entrar y salir de cada sub-chain para entender el flujo completo.
4. Sin testing automatizado
No existe un framework de testing para rule chains. No puedes escribir unit tests, no puedes simular escenarios, no puedes hacer regression testing. Cada cambio es un acto de fe que se valida manualmente en un entorno de pre-producción (si lo tienes, y si lograste replicar las rule chains correctamente).
5. Replicación de entornos costosa
Mover rule chains de dev → staging → producción requiere exportar JSON desde un entorno e importar en otro. Las referencias internas (IDs de dispositivos, dashboards, relaciones) no se mantienen, lo que obliga a ajustes manuales en cada entorno. Esto es frágil y propenso a errores.
6. Lock-in de conocimiento
El conocimiento de las rule chains reside en la persona que las diseñó. No hay documentación auto-generada, no hay diagramas estáticos exportables (más allá de screenshots). Cuando esa persona se va, el conocimiento se va con ella.
7. Incompatibilidad con IA generativa (GenAI)
Las herramientas de IA generativa (GitHub Copilot, Claude, Cursor, etc.) están transformando radicalmente la productividad en desarrollo de software: generan código, escriben tests, depuran errores, documentan y refactorizan. Pero solo funcionan con código. Las rule chains de TB son configuraciones visuales en una UI propietaria — no hay código que un modelo de IA pueda leer, generar o mejorar. Un equipo que trabaja con rule chains queda completamente al margen de la revolución GenAI en desarrollo. Un equipo que trabaja con Lambda functions en Python o TypeScript puede multiplicar su productividad con estas herramientas desde hoy. Esta brecha solo va a ampliarse con el tiempo.
Cómo se resuelve en el enfoque AWS Compose
| Problema en TB | Solución en AWS Compose |
|---|---|
| Sin versionado | Lambda functions / Step Functions en Git. CI/CD estándar. PRs, code review, blame. |
| Debugging complejo | CloudWatch Logs, X-Ray tracing, métricas por función. Logging estructurado nativo en el código, sin herramientas intermedias. |
| Complejidad visual | Código legible. Funciones pequeñas y testeables. Diagramas generables desde IaC. |
| Sin testing | Unit tests, integration tests, contract tests. Frameworks estándar (Jest, pytest, etc.). |
| Replicación de entornos | IaC (CloudFormation, Terraform, CDK). Un terraform apply replica el entorno completo. |
| Lock-in de conocimiento | Código documentable, legible, revisable. Onboarding con el repo, no con la UI. |
| Sin beneficio de GenAI | Código compatible con IA generativa (Copilot, Claude, Cursor). Generación, testing, documentación y refactoring asistidos por IA. Multiplicador de productividad creciente. |
Cómo se implementan las reglas de negocio en el enfoque AWS Compose
En el enfoque Compose on AWS, la lógica de negocio no reside en un canvas visual sino en código desplegado sobre servicios gestionados que se combinan en capas:
AWS IoT Core Rules es el primer nivel de procesamiento. Cada mensaje MQTT que llega al broker pasa por un motor de reglas basado en SQL. Estas reglas permiten filtrar, transformar y enrutar mensajes en tiempo real hacia otros servicios de AWS: insertar telemetría en DynamoDB o Timestream, enviar alertas a SNS, disparar una Lambda function, encolar mensajes en SQS para procesamiento asíncrono, o reenviar datos a Kinesis Firehose para ingestión masiva hacia S3. Las IoT Rules son declarativas, se definen en IaC (CloudFormation, CDK, Terraform), se versionan en Git, y se despliegan con CI/CD. Son el equivalente funcional de los nodos de filtrado y enrutamiento de una rule chain de TB, pero con la diferencia fundamental de que son código versionable y reproducible.
AWS Lambda es donde reside la lógica de negocio propiamente dicha. Cada función Lambda es una pieza de código (Python, TypeScript, Go, etc.) que ejecuta una tarea concreta: validar un payload, calcular un indicador derivado, evaluar condiciones de alarma, enriquecer datos con información contextual, o invocar APIs externas. Las funciones son pequeñas, testeables unitariamente, desplegables de forma independiente, y escalan automáticamente de cero a miles de ejecuciones concurrentes sin provisionar servidores. Un equipo puede escribir tests para cada función, hacer code review en PRs, y desplegar con confianza usando pipelines de CI/CD. Además, son el escenario ideal para la IA generativa: herramientas como Copilot o Claude pueden generar, mejorar y testear estas funciones directamente.
AWS Step Functions entra en juego cuando la lógica requiere orquestación: flujos multi-paso, bifurcaciones condicionales, reintentos con backoff, ejecuciones paralelas, o procesos de larga duración (ej: un workflow de aprovisionamiento de dispositivo que espera validación humana). Step Functions define estos flujos como máquinas de estado en JSON/YAML, versionables en Git, con visualización automática del flujo, logging integrado, y trazabilidad completa de cada ejecución. Es el equivalente funcional de una rule chain compleja de TB, pero con la diferencia de que cada paso es una Lambda testeable, el flujo completo es reproducible, y el historial de ejecuciones es consultable sin necesidad de herramientas externas.
En combinación, el patrón típico es: IoT Core Rules filtra y enruta → Lambda procesa la lógica unitaria → Step Functions orquesta flujos complejos → los resultados se almacenan en DynamoDB/S3/Timestream y se sirven vía API Gateway + Tinybird al frontend. Todo definido como código, todo versionado, todo testeable, todo desplegable con un git push.
5. TCO Comparativo
5.1 Desglose de costes anuales — 1,000 dispositivos, ~1M mensajes/día
| Concepto | AWS Compose | TB Public Cloud (Startup/Business) | TB Private Cloud (Managed) | TB Self-Hosted PE |
|---|---|---|---|---|
| Proyecto (desarrollo/integración) | €60K-€100K (una vez) | €30K-€60K (una vez) | €30K-€60K (una vez) | €40K-€80K (una vez) |
| Licencia/Suscripción año 1 | €0 (pay-per-use) | aprox. €5K-€10K | aprox. €15K-€30K (plan dedicado) | €3K-€10K perpetua |
| Licencia/Suscripción años 2+ | €0 | aprox. €5K-€10K/año | aprox. €15K-€30K/año | €1.2K-€4K/año (updates) |
| MQTT Broker | Incluido en IoT Core | TBMQ CE (gratis) o PE (licencia extra) | Incluido o TBMQ PE (add-on) | TBMQ CE (gratis) o PE (licencia extra) |
| Infra /año | €4K-€8K (serverless) | €0 (incluida en plan) | €0 (incluida en plan dedicado) | €12K-€22K (EC2/EKS+RDS+Kafka) |
| Analítica /año | Tinybird: €3.5K-€7K | Trendz: €5K-€15K (add-on) | Trendz: €5K-€15K (add-on) | Trendz: €5K-€15K (add-on) |
| Soporte /año | €8K-€15K (partner) | Incluido en plan | Incluido (SLA dedicado) | €12K-€24K (TB Premium) |
| Operación /año | Partner AWS o equipo interno | €0 (managed) | €0 (managed por TB) | Equipo DevOps necesario |
[>] Dato real Tinybird (enero 2026): Un operador de +1,000 puntos de recarga conectados con $3,600/año, muy por debajo del coste de Trendz o soluciones analíticas alternativas.
5.2 TCO a 3 años
| Componente | AWS Compose | TB Public Cloud | TB Private Cloud | TB Self-Hosted PE |
|---|---|---|---|---|
| Proyecto inicial | €60K-€100K | €30K-€60K | €30K-€60K | €40K-€80K |
| Licencias (3 años) | €0 | €15K-€30K | €45K-€90K | €5.4K-€18K |
| Infraestructura (3 años) | €12K-€24K | €0 (incluida) | €0 (incluida) | €36K-€66K |
| Analítica (3 años) | €10.5K-€21K | €15K-€45K | €15K-€45K | €15K-€45K |
| Soporte (3 años) | €24K-€45K | €0 (incluido) | €0 (incluido) | €36K-€72K |
| TOTAL 3 años | €106K – €190K | €80K – €170K | €90K – €195K | €150K – €300K |
5.3 TCO a 5 años
A 5 años, los costes recurrentes dominan y las diferencias entre modelos se amplifican significativamente:
| Componente | AWS Compose | TB Public Cloud | TB Private Cloud | TB Self-Hosted PE |
|---|---|---|---|---|
| Proyecto inicial | €60K-€100K | €30K-€60K | €30K-€60K | €40K-€80K |
| Licencias (5 años) | €0 | €25K-€50K | €75K-€150K | €7.8K-€26K |
| Infraestructura (5 años) | €20K-€40K | €0 (incluida) | €0 (incluida) | €60K-€110K |
| Analítica (5 años) | €17.5K-€35K | €25K-€75K | €25K-€75K | €25K-€75K |
| Soporte (5 años) | €40K-€75K | €0 (incluido) | €0 (incluido) | €60K-€120K |
| Evolución funcional (años 3-5) | €20K-€40K | €15K-€30K | €15K-€30K | €15K-€30K |
| TOTAL 5 años | €157.5K – €290K | €95K – €265K | €145K – €315K | €210K – €440K |
[!] Nota sobre TB Public Cloud a 5 años: El rango bajo (€95K) asume el plan Startup sin add-ons y con personalización mínima. En la práctica, proyectos que llegan al año 3-5 suelen necesitar Trendz, posiblemente TBMQ PE, y evolución funcional que empuja el coste real hacia la parte alta del rango. Además, a partir de cierto volumen, TB fuerza la migración a planes superiores (Business/Business+), incrementando la suscripción anual.
[!] Nota sobre TB Private Cloud a 5 años: El rango (€145K-€315K) refleja el coste de un cluster dedicado gestionado por TB. La suscripción anual (€15K-€30K) es significativamente mayor que Public Cloud porque incluye infraestructura dedicada, SLA garantizado y aislamiento. La ventaja es que el cliente no opera la infra, pero el pricing no es público y escala con el uso — a medida que crece el número de dispositivos o el throughput, TB negocia planes superiores. Trendz y otros add-ons se suman igualmente.
[!] Nota sobre TB Self-Hosted a 5 años: Es el escenario con mayor dispersión (€210K-€440K). El rango alto incluye cluster HA completo (múltiples nodos TB + Kafka + Redis + RDS Multi-AZ), TBMQ PE, Trendz, soporte Premium, y un equipo DevOps parcial dedicado a operar la plataforma. Muchos proyectos subestiman estos costes al inicio.
Nota sobre AWS Compose a 5 años: El coste es el más predecible a largo plazo. La infraestructura serverless mantiene costes proporcionales al uso real, sin saltos por redimensionamiento de clusters. El soporte de partner se estabiliza o incluso decrece a medida que el equipo interno gana competencia. La analítica con Tinybird mantiene un coste flat-rate predecible (~$300/mes) para volúmenes significativos.
5.4 Resumen visual TCO
TCO a 3 años (€K, punto medio del rango):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AWS Compose ████████████████░░░░░░░░░░ €148K
TB Public Cloud █████████████░░░░░░░░░░░░░ €125K
TB Private Cloud ███████████████░░░░░░░░░░░ €143K
TB Self-Hosted ██████████████████████████ €225K
TCO a 5 años (€K, punto medio del rango):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AWS Compose ███████████████░░░░░░░░░░░ €224K
TB Public Cloud ████████████░░░░░░░░░░░░░░ €180K
TB Private Cloud ██████████████████░░░░░░░░ €230K
TB Self-Hosted ██████████████████████████ €325K
5.5 Observaciones clave
- TB Public Cloud es el más económico en coste directo, pero tiene limitaciones de control, regiones (EU/NA), data sovereignty, y el TCO crece con add-ons. Además, la mantenibilidad de las rule chains (sección 4) es un coste oculto de productividad que no aparece en estos números.
- TB Private Cloud es la opción «managed premium» de TB. Elimina la carga operativa del self-hosted, pero la suscripción anual de un cluster dedicado (€15K-€30K/año) eleva el TCO significativamente respecto al Public Cloud. A 3 años compite en rango con AWS Compose (aprox. €143K vs aprox. €148K), pero a 5 años se encarece (aprox. €230K) por el peso acumulado de la suscripción. El pricing no es público y escala con el uso, lo que reduce la predictibilidad.
- TB Self-Hosted es el más caro con diferencia cuando se hace bien (HA, backups, monitoring, TBMQ PE). El coste de infra eclipsa el ahorro de licencia. Requiere equipo DevOps dedicado. Es la opción que más proyectos eligen inicialmente y más lamentan a largo plazo.
- AWS Compose está en el medio en coste directo, pero ofrece la mejor relación flexibilidad/coste, el menor coste de infraestructura recurrente (serverless), y ventajas de mantenibilidad (código vs UI) que no se reflejan en el TCO pero impactan enormemente la productividad del equipo. El coste de analítica con Tinybird ($300/mes flat-rate para volúmenes significativos) refuerza la competitividad de este enfoque.
- A 5 años, AWS Compose se posiciona mejor que TB Private Cloud y muy por debajo de TB Self-Hosted, porque los costes recurrentes de infra fija y suscripciones dedicadas pesan más con el tiempo, mientras que serverless mantiene costes proporcionales al uso.
5.6 Escenario de escala: 50K+ dispositivos
| Concepto | AWS Compose | TB Private Cloud | TB Self-Hosted PE |
|---|---|---|---|
| Infra /mes | Variable. Crece con uso pero IoT Core escala a $0.70/M msgs | Gestionada por TB. Pricing Enterprise (contactar ventas) | $1,800-$3,500+ (cluster HA escalado) |
| MQTT Broker /mes | Incluido (~$50-150 IoT Core) | TBMQ incluido o add-on PE | TBMQ PE licencia separada + infra adicional |
| Escalado | Automático | Gestionado | Manual (añadir nodos, rebalancear Kafka/Cassandra) |
6. Trade-offs Clave
| Dimensión | AWS Compose | ThingsBoard |
|---|---|---|
| Time-to-PoC | 2-4 semanas | Días (dashboards sin código) |
| Time-to-producción | 2-3 meses | 2-3 meses (con personalización) |
| Coste infra (serverless) | <€500/mes para volúmenes moderados | $1,000-$1,800/mes self-hosted. Incluido en SaaS. |
| MQTT Broker | Incluido en IoT Core. Pricing transparente. | TBMQ CE gratis. PE licenciado por separado (opaco). |
| Mantenibilidad | Código en repo. CI/CD, tests, versionado, IaC. | Todo por UI. Sin versionado nativo. Rule chains → spaghetti. |
| Extensibilidad | Ilimitada. Cualquier servicio AWS. | Acotada al framework. Widget SDK y Rule Engine extensible pero con techo. |
| Dashboards | Custom (requiere desarrollo frontend). | +30 widgets sin código. Rápidos pero estéticamente limitados. |
| Rule Engine | Lambda + Step Functions. Code-first. Testeable. | Visual drag & drop. Potente al inicio, problemático a escala. |
| Operación | Equipo con skills AWS o partner especializado. | Generalista para SaaS/Private. DevOps necesario para self-hosted. |
| Vendor lock-in | AWS (ampliamente adoptado). Código propiedad del cliente. | TB Inc. Mitigado por CE open source. |
| Edge / Offline | IoT Greengrass. Potente pero añade complejidad. | TB Edge (add-on). Integrado nativamente. |
| Data sovereignty | Total control (tu cuenta AWS). | SaaS: servidores TB. Self-hosted: control total. |
| Compatibilidad con GenAI | Total. Código en repo compatible con Copilot, Claude, Cursor, etc. Aceleración creciente. | Nula para rule chains y configuraciones UI. La lógica no-code no se beneficia de IA generativa. |
[!] El factor GenAI como multiplicador estratégico. La IA generativa aplicada al desarrollo de software no es una moda pasajera — es un cambio estructural en la productividad de los equipos de ingeniería. Las plataformas cuya lógica reside en interfaces visuales propietarias (rule chains, workflows drag & drop, configuraciones por UI) quedan excluidas de este multiplicador. Solo los enfoques code-first permiten aprovechar la IA para generar, testear, documentar y mantener la lógica de negocio. Elegir una plataforma no-code hoy implica renunciar a una ventaja competitiva que solo va a crecer con el tiempo.
7. Riesgos
7.1 Riesgos AWS Compose
| Riesgo | Descripción | Prob. | Impacto |
|---|---|---|---|
| Dependencia del partner | El código custom lo conoce el partner implementador. Mitigado: código en repo del cliente, stack AWS estándar, documentación, transfer de conocimiento. | Baja-Media | Medio |
| Complejidad operativa | Requiere expertise AWS. Mitigado: servicios gestionados reducen la operación; el equipo necesario es más pequeño que para self-hosted TB. Además, los profesionales con skills AWS son significativamente más abundantes en el mercado que especialistas en plataformas IoT propietarias (ThingsBoard, Thinger.io, Litmus, PTC ThingWorx, etc.). Encontrar, contratar o formar talento AWS es más fácil y económico. | Baja-Media | Medio |
| Frontend por desarrollar | Dashboards custom requieren diseño y desarrollo. No hay widgets predefinidos. | Media | Medio |
| Costos a escala alta | Pay-per-use puede crecer con volumen. Mitigado: optimización de costes es una disciplina establecida en AWS (reserved, savings plans, basic ingest). | Baja | Bajo |
[>] Nota sobre disponibilidad de talento: El ecosistema AWS cuenta con millones de profesionales certificados a nivel global, una extensa red de partners (APN), documentación exhaustiva, comunidades activas y un mercado laboral maduro. En contraste, las plataformas IoT profesionales (ThingsBoard, Litmus, PTC ThingWorx, Cumulocity, etc.) tienen pools de talento reducidos y concentrados geográficamente. Esto impacta directamente en la velocidad de contratación, los costes de personal, la capacidad de sustituir partners, y la resiliencia operativa a largo plazo. En mercados como España y Latinoamérica, la diferencia es especialmente acusada.
7.2 Riesgos ThingsBoard
| Riesgo | Descripción | Prob. | Impacto |
|---|---|---|---|
| Mantenibilidad | Rule chains degeneran en spaghetti no-code. Sin versionado, sin tests, sin CI/CD. Debugging tedioso. Replicación de entornos frágil. El riesgo más relevante. | Alta | Alto |
| Coste real self-hosted | El TCO de self-hosted en producción (EC2/EKS + RDS + Kafka + Redis + TBMQ) puede ser 3-4x mayor que el estimado inicial. Muchos proyectos subestiman esto. | Alta | Alto |
| TBMQ como coste oculto | Para MQTT enterprise, TBMQ PE es necesario y se licencia por separado. El pricing no es público. Suma a la licencia de TB PE. | Media | Alto |
| Techo funcional | Funcionalidades muy específicas del dominio pueden requerir extensiones que estiren los límites del framework. | Media | Medio |
| Pocos partners especialistas | En ciertos mercados (ej: España/Latam) es difícil encontrar integradores de calidad para ThingsBoard. | Alta | Medio |
| Escalabilidad manual (self-hosted) | Requiere planificación de capacidad, dimensionamiento de clústeres, rebalanceo de Kafka/Cassandra. | Media | Medio |
8. Cuándo elegir cada enfoque
Elige AWS Compose si…
- Tu organización ya está en el ecosistema AWS o planea estarlo.
- Necesitas flexibilidad total para evolucionar sin techo funcional.
- La mantenibilidad a largo plazo (versionado, CI/CD, tests) es prioritaria.
- Tienes (o formarás) un equipo con skills AWS, o un partner especializado.
- Quieres el menor coste de infraestructura recurrente (serverless).
- Necesitas integrar con servicios de datos, ML o BI en el futuro.
- El MQTT broker transparente y escalable sin licencia separada es importante.
Elige ThingsBoard si…
- Necesitas un prototipo funcional en días, no semanas.
- Tu equipo no tiene expertise cloud y prefieres un stack self-contained.
- Los dashboards sin código son suficientes y no necesitas UX premium.
- La complejidad del rule engine se mantendrá baja (<15-20 nodos).
- Prefieres un modelo SaaS (Public Cloud) sin gestionar infraestructura.
- Necesitas despliegue air-gapped u offline (TB PE Perpetua + TBMQ).
- El proyecto es un piloto o PoC que quizás no escale a producción.
EVITA ThingsBoard self-hosted si…
- No tienes un equipo DevOps dedicado.
- Subestimas los costes de EC2/EKS + RDS + Kafka + Redis.
- Necesitas TBMQ PE y no has presupuestado la licencia por separado.
- Tu rule engine crecerá más allá de 15-20 nodos.
- Necesitas CI/CD, versionado y testing de tu lógica de negocio.
9. Recomendación
Este análisis utiliza ThingsBoard como caso de estudio representativo, pero las conclusiones son aplicables al conjunto de plataformas IoT autocontenidas del mercado — ThingsBoard, Thinger.io, Litmus, PTC ThingWorx, Cumulocity, Losant, etc. Todas comparten un patrón común: son soluciones «todo en uno» con lógica configurada por UI, ecosistemas cerrados y modelos de licenciamiento que escalan con el uso. Los puntos que suelen subestimarse al evaluarlas frente a un enfoque de composición sobre servicios cloud son:
- Las plataformas IoT autocontenidas no son tan baratas como parecen. Las opciones SaaS sí son económicas para empezar, pero en producción — con HA, brokeraje MQTT enterprise, analítica avanzada y add-ons — el TCO puede igualar o superar al de un enfoque serverless sobre AWS. En self-hosted, el coste de infraestructura por sí solo eclipsa cualquier ahorro de licencia.
- El «no-code» es una trampa a medio plazo. Los motores de reglas visuales, los workflows drag & drop y las configuraciones por UI funcionan bien para lógica simple. Pero a medida que el proyecto crece, degeneran en complejidad inmanejable: sin versionado, sin testing, sin CI/CD, sin posibilidad de code review. El código versionado, testeable y desplegable con pipelines estándar es superior para proyectos industriales serios.
- El broker MQTT no viene incluido en la mayoría de estas plataformas — o si viene, es un producto separado con licencia adicional. AWS IoT Core resuelve esto de raíz: broker MQTT nativo a $1/millón de mensajes, fully managed, escalado automático, sin licencia separada.
- La infraestructura serverless reduce drásticamente los costes recurrentes. Un stack Lambda + DynamoDB + IoT Core puede costar <€500/mes donde un equivalente self-hosted de cualquier plataforma IoT cuesta €1,500-€2,000/mes o más. La analítica con servicios como Tinybird ($300/mes flat-rate para +1,000 dispositivos) refuerza esta ventaja.
- Las plataformas cerradas quedan fuera de la revolución GenAI. La IA generativa (Copilot, Claude, Cursor) está multiplicando la productividad de los equipos que trabajan con código. Las configuraciones visuales, rule chains y lógica definida por UI de las plataformas autocontenidas no pueden beneficiarse de estas herramientas — no hay código que la IA pueda leer, generar, testear o mejorar. Un enfoque code-first aprovecha plenamente este multiplicador, y la brecha solo va a ampliarse.
- El talento AWS es abundante; el de plataformas IoT propietarias, no. Encontrar profesionales con experiencia en AWS es órdenes de magnitud más fácil que encontrar especialistas en ThingsBoard, PTC ThingWorx, Litmus o cualquier plataforma IoT de nicho. Esto impacta directamente en la velocidad de contratación, los costes de personal, y la resiliencia operativa a largo plazo.
Para proyectos industriales que van a escalar y necesitan mantenibilidad a largo plazo, el enfoque Compose sobre servicios cloud gestionados ofrece mejor relación calidad-precio-riesgo que cualquier plataforma IoT autocontenida. Es el único enfoque que permite capitalizar la IA generativa, mantener costes proporcionales al uso real, y acceder a un pool de talento global. Las plataformas IoT SaaS siguen siendo una opción válida para PoCs y pilotos, pero hay que planificar cuidadosamente la transición a producción y ser realista sobre el TCO total a medio-largo plazo.
Fuentes y referencias:
ThingsBoard: Pricing · Deployment Scenarios · Performance Benchmarks · TBMQ · New Pricing Blog
AWS: IoT Core Pricing · IoT Core · Lambda · DynamoDB · IoT Greengrass · IoT SiteWise
Analítica: Tinybird Pricing
Plataformas IoT autocontenidas mencionadas: ThingsBoard · Thinger.io · PTC ThingWorx · Litmus · Cumulocity IoT (Software AG) · Losant · Ubidots · Kaa IoT · EMQX · Datacake · TagoIO · Siemens Insights Hub (ex-MindSphere)