Espressif liberó ESP RainMaker Neo, una nueva implementación de su plataforma de Internet de las Cosas en la que todo el recorrido, del dispositivo a la nube y de la nube a la aplicación, queda con el código abierto. La pieza que faltaba, el backend en la nube, se publica ahora bajo licencia Apache 2.0, según anunció la compañía en su blog para desarrolladores.
Durante los últimos años, ESP RainMaker, hoy rebautizado como ESP RainMaker Classic, permitió a los desarrolladores levantar su propia plataforma IoT desplegada directamente en su cuenta de AWS. Ese modelo entrega a las organizaciones la propiedad de su infraestructura y de sus datos, mientras que la arquitectura serverless reduce la administración y escala según la demanda con pago por uso.
¿Qué cambia con ESP RainMaker Neo?
Classic ya ofrecía firmware, aplicaciones móviles y paneles con código abierto, además de una API abierta para el backend. Lo que seguía cerrado era ese backend. Con Neo, ese componente también queda disponible, es apto para producción y se instala en la cuenta AWS del cliente, lo que le da control sobre la infraestructura, los datos y la experiencia de producto. El firmware, las aplicaciones móviles, los paneles y las integraciones con los asistentes de voz de Alexa y Google Home están disponibles como componentes abiertos bajo sus respectivas licencias.
| Aspecto | RainMaker Classic | RainMaker Neo |
|---|---|---|
| Backend en la nube | Código cerrado, API abierta | Abierto, Apache 2.0 |
| Arquitectura | Infraestructura propia de RainMaker | Servicios nativos de AWS IoT |
| Actualizaciones remotas | Implementación propia | AWS IoT OTA |
| Permisos | Modelo propio de RainMaker | Control de acceso a nivel IAM |
| Estado recomendado | Productos ya desplegados | Desarrollos nuevos |
La experiencia de desarrollo se mantuvo familiar. Las API del lado del dispositivo son en gran medida similares a las de Classic y el SDK móvil híbrido, RainMaker Home, sigue siendo el mismo con un transporte adicional para Neo. Quien ya trabajó con Classic puede partir con Neo sin volver a aprender el stack de dispositivo y aplicación.
Hay una advertencia importante. Aunque se conserva la familiaridad en las capas de dispositivo y aplicación, Neo es una implementación nueva con una arquitectura de nube distinta. Los despliegues existentes de Classic no se pueden migrar directamente a Neo y ambas plataformas no son compatibles entre sí. Por eso Espressif recomienda Neo para desarrollos nuevos, mientras que los productos ya desplegados sobre Classic pueden seguir en esa plataforma, que continúa con soporte.
¿Por qué reescribir la plataforma desde cero?
Según Espressif, RainMaker se guió desde su origen por cinco principios de diseño: mantenibilidad, escalabilidad, seguridad, apertura y eficiencia de costos. Lo que cambió no fueron esos principios, sino el entorno tecnológico.
Cuando se diseñó Classic hace varios años, las decisiones de arquitectura respondían a las capacidades y a la economía de los servicios de AWS de ese momento. La empresa explica que optó deliberadamente por no usar AWS IoT OTA en Classic porque su costo de entonces lo hacía inviable para el rango amplio de productos conectados que RainMaker buscaba soportar. Hoy eso ya no es un problema. Algo similar ocurrió con las limitaciones que tenía Device Shadow, que condicionaron la forma de modelar los datos de los dispositivos.
Neo es una implementación más liviana que se apoya de manera más directa en servicios nativos de AWS IoT como Device Shadow, Thing Groups y AWS IoT OTA. Los permisos de usuarios y dispositivos se aplican con control de acceso a nivel de IAM, apoyándose de nuevo en mecanismos propios de AWS para seguridad y autorización. El resultado, sostiene la compañía, es una arquitectura más simple y más cercana a AWS, con menos infraestructura específica de RainMaker que construir y mantener.
Espressif insiste en que esta evolución no sacrifica la eficiencia de costos: Neo continúa con el modelo serverless de Classic y está pensado para seguir siendo económicamente viable en productos de alto volumen y sensibles al precio.
¿Qué significa "abierto" en la práctica?
Con Neo, la apertura va más allá de poder mirar el código fuente. Implica la libertad de entender, personalizar, integrar y auditar cada capa de la plataforma, desde el firmware del dispositivo y el backend hasta las aplicaciones móviles y los paneles.
Para las empresas de productos conectados, esto abre la posibilidad de convertir la propia plataforma IoT en un diferenciador, sin tener que construir la infraestructura básica desde cero. Y como la implementación completa es abierta y corre en la cuenta AWS del cliente, los equipos con conocimientos de nube y de sistemas embebidos pueden operar, diagnosticar, modificar y mantener la plataforma de forma independiente, sin depender de Espressif para el soporte técnico.
Neo conserva la mayoría de las capacidades conocidas de Classic: registro de dispositivos y asociación con usuarios, gestión de usuarios, control remoto y telemetría, series de tiempo, horarios y automatizaciones. La gestión de flota, la organización por grupos y las actualizaciones remotas se apoyan directamente en la infraestructura de administración de dispositivos de AWS IoT.
Matter en el dispositivo, la app y la nube
ESP RainMaker Neo ofrece soporte integral de Matter en las tres capas. Los dispositivos con Matter de Espressif pueden usar el SDK ESP-Matter, mientras que los SDK móviles y las aplicaciones de referencia entregan capacidades de puesta en marcha y control bajo ese estándar. Neo lleva Matter a la nube con capacidades de Matter Fabric, lo que permite que el backend interactúe de forma segura con los dispositivos de esa red.
La plataforma llega además con especificaciones documentadas que definen arquitectura, interfaces y comportamiento esperado, y con cobertura de pruebas automatizadas que incluye pruebas unitarias y de integración a lo largo del stack.
¿Qué implica para integradores de LatAm?
El punto más relevante para la región no es la licencia en sí, sino dónde vive la infraestructura. Al desplegarse en la cuenta AWS de cada empresa, el operador decide la región del despliegue, y AWS tiene infraestructura en Sudamérica con su región de São Paulo, además de las regiones de Estados Unidos que hoy usan la mayoría de los integradores chilenos. Eso convierte la residencia de los datos en una decisión de arquitectura y no en una condición impuesta por el proveedor de la plataforma.
El segundo punto es el soporte. Al no existir dependencia obligatoria de Espressif para operar el backend, un integrador con equipo propio de nube puede sostener el servicio en su zona horaria, algo que hasta ahora obligaba a coordinar con husos horarios de Asia. Para quien prefiera respaldo formal, el Plan Enterprise de ESP RainMaker Neo agrega soporte técnico con acuerdos de nivel de servicio, junto con complementos como ESP Insights para observabilidad remota de dispositivos y ESP Private Agents para capacidades de agentes de IA en la nube.
¿Cómo empezar hoy?
ESP RainMaker Neo ya está disponible. Existen tres caminos: usar el despliegue público de Neo sin ninguna configuración de nube, ejecutar el backend empaquetado en la cuenta AWS propia, o compilar la nube desde el código fuente y desplegar una versión personalizada.
La guía de inicio recorre el camino completo, desde el despliegue del backend hasta la compilación y grabación del firmware, y el aprovisionamiento del dispositivo con la aplicación ESP RainMaker Home (iOS / Android). Para ir directo al lado del dispositivo, están los ejemplos de firmware.
Todo el stack es abierto: el backend en la nube, el firmware, la aplicación móvil y el SDK de la app, con la referencia completa de API HTTP y MQTT publicada en línea.
