Llegamos a ustedes gracias a:



Reportajes y análisis

Reseña: Azure trae la IoT para desarrolladores .Net

[28/03/2016] Las tendencias tecnológicas no son más nebulosas que la "Internet de las cosas". Después de todo, una cosa puede ser cualquier cosa. Para los desarrolladores que desean hacer que un concepto difuso se convierta en código real, la nube de Microsoft Azure es un buen lugar para comenzar. Al igual que AWS IoT de Amazon, la suite IoT de Azure equipara los servicios de back-end con los SDK para dispositivos cliente de baja potencia, como Raspberry Pi. A diferencia de la IoT de AWS, Azure apoya el desarrollo .Net como parte de su oferta.

La suite IoT de Azure, que incluye IoT Hub de Azure y otros servicios, puede ayudarle a generar soluciones a partir de plantillas comunes. Una vez que haya generado una solución IoT, se puede conectar a dispositivos reales y modificarlos según sea necesario.

El Hub IoT de Azure es un servicio para el control y la ingestión de datos de los dispositivos IoT, típicamente computadoras de una sola placa, como la Raspberry Pi, que a su vez están conectadas a sensores, relés, y máquinas del mundo real en última instancia, que van desde bombillas "inteligentes" a automóviles, plantas de fabricación, y ciudades enteras. El Hub IoT de Azure puede conectarse a una serie de otros servicios Azure para construir una solución completa de IoT.

Los SDKs del cliente IoT Hub de Azure le permite conectarse realmente a los dispositivos. Los SDK son de código abierto y se actualizan con frecuencia. En el momento de escribir estas líneas, la lista de dispositivos IoT certificados de Azure incluía más de 50 tableros. De acuerdo con la documentación de instalación en el repositorio, se admiten más computadoras de una sola placa de las que se enumeran. Por ejemplo, el SDK C contiene instrucciones de instalación para un Arduino Yun.

En este momento, los únicos entornos de desarrollo apoyados explícitamente por las SDK C y Java son Windows y Ubuntu. La SDK de .Net, como era de esperarse, solo es compatible con un entorno de desarrollo de Windows, y la documentación dice: "Se puede utilizar cualquier versión de Visual Studio 2015, incluyendo la edición de la comunidad". La documentación SDK Node.js solo habla de configuración para Windows y Linux; no me sorprendería si las instrucciones de Linux fueran sustancialmente correctas para Mac OS X también.

Dispositivos y clientes SDK

He utilizado una versión temprana de la SDK C#/. Net en la conferencia Build del año pasado, con una laptop que ejecuta Visual Studio 2015, como el entorno de desarrollo y un cliente Raspberry Pi 2 con Windows 10 con un Core IoT conectado a un vehículo robot de juguete. En ese entorno, con todo lo que ya se ha configurado, se desarrolló un ejercicio práctico distribuido, con ayuda personal disponible, y todo fue bastante simple.

En teoría, puede comprar un starter kit de Raspberry Pi IoT para Windows 10 que proporciona una tarjeta SD preconfigurada y el dongle Wi-Fi. He comprado un kit diferente de Raspberry Pi 2, ya que el kit IoT de Windows estaba fuera de stock. Vino con una tarjeta microSD cargada con el instalador de NOOBS (Nuevo software salido de la caja) y un dongle Wi-Fi menos costoso que (ejem) no es compatible con el Coreo IoT de Windows 10, así que instalé Raspbian para NOOBS y tuve a Pi trabajando en mi red. El cliente Raspbian es apoyado por C, el nodo, y los SDK de Java, pero no el C#/. Net SDK. (Yo estaba planeando descargar la imagen IoT de Windows 10 y grabarla en otra tarjeta microSD para que pudiera utilizar el dispositivo SDK C#/.Net con Visual Studio, pero no tuve el dongle Wi-Fi oficial de Raspberry Pi a tiempo.)

Aunque OS X no se encuentra entre los entornos de desarrollo compatibles, después de leer el código creo que puedo adaptar la configuración de Ubuntu para que los tres SDK trabajen en OS X con un poco de esfuerzo. También tengo Windows 10 y Visual Studio 2015 instalados en una HP Spectre 360, junto con una MV Ubuntu x64 que se puede ejecutar en VMware Fusion, los cuales se apoyan los entornos de desarrollo para algunos de los SDKs de dispositivos.

También compré un Arduino Yun, que parecía la forma más fácil de probar la SDK IoT de AWS. Al leer el código para el instalador Arduino Yun en Ubunto en el dispositivo C IoT SDK de Azure, también pienso que puedo adaptarlo a trabajar en OS X. Ni siquiera podría ser difícil de hacer.

BeagleBone, Intel Edison, Freescale FRDM-K64, y Texas Instruments CC3200 también son soportados oficialmente por la suite IoT de Azure. Tengo fe de que los SDKs para ellos funcionan como está documentado, sobre todo desde que he visto videos donde algunos de los directores de programa de Microsoft hacen demostraciones con ellos.

Más allá del gran problema de la configuración del dispositivo con los controladores adecuados, hay un problema de compilación cruzada, al menos para C. Raspberry Pi 2, una CPU de 900MHz de cuatro núcleos ARM Cortex-A7 con 1GB de RAM, en realidad puede compilar y enlazar el código C en sí, pero es mucho, mucho más lento que la compilación cruzada en una Intel Core i7 de 2,8GHz con 16GB de RAM. Visual Studio 2015 se encarga de esto mismo, con una bonita interfaz gráfica de usuario. No me resultó difícil encontrar los interruptores necesarios para compilar ARM de Clang en una Mac, aunque tuve que sumergirme en Internet. El entorno de desarrollo Arduino Yun para Mac hace su propia compilación; a continuación, descarga el binario al dispositivo a través de Wi-Fi o una conexión USB.

Si está confundido por la ausencia de soporte para Mac, únase al club. Es una lástima que Microsoft aún no haya adaptado y probado un entorno de desarrollo OS X para dispositivos IoT Azure IO. Después de todo, la mayor parte de la tecnología está ahí, y la IoT de la competencia, Amazon, es compatible con OS X como entorno de desarrollo.

Soy consciente de que el equipo IoT de Azure tiene mucho que ofrecer; sin embargo, está claro que varios de los servicios que se muestran en los diagramas aún no han sido liberados. También está trabajando en un dispositivo SDK de Python, pero no ha prometido una fecha de entrega.

Sin embargo, la programación del dispositivo real no es muy complicada. El dispositivo se configura para enviar mensajes de estado y manejar comandos. Hay una API sencilla que hace todo lo necesario para para llevar a cabo esto.

Gestión, protocolos y análisis

Microsoft proporciona una buena consola de administración web para el concentrador de Hub IoT, como se muestra en la Figura 1. En realidad, puede llegar hasta el nivel de dispositivo y enviar comandos, que por supuesto no van a escalar a miles o millones de dispositivos.

El Hub IoT de Azure puede conectarse a una serie de otros servicios Azure para construir una solución completa de IoT. Esta pantalla es donde se crea un nuevo Hub IoT.
Hub IoT de Azure

Además de la consola de administración Web, puede (en Windows) gestionar el Hub IoT Azure desde Visual Studio 2015, con los actuales plug-ins instalados, y desde PowerShell una vez que añada los módulos PowerShell Resource Manager y Service Manager. En cualquier plataforma se puede instalar y utilizar la CLI Azure. Si desea una forma escalable para, por ejemplo, conectar miles de dispositivos, puede escribir scripts de shell o programar contra las APIs IoT de Azure para REST (utilizando cualquier lenguaje o plataforma) o .Net.

Para los dispositivos que se pueden conectar a una red TCP/IP, Microsoft admite HTTPS y el protocolo más eficiente Advanced Message Queuing Protocol (AMQP) de forma nativa, y el protocolo MQTT (que es lo que utiliza IoT de AWS) a través de una pasarela de protocolo. Para los dispositivos que utilizan una red local no rooteable como ZigBee, tendría que pasar los mensajes a través de una pasarela de campo para convertirlos desde AMQP. Por desgracia, el código de puerta de enlace de campo aún no ha sido liberado.

Una cosa que he notado en el diseño de una aplicación real en el Hub IoT de Azure es que requiere una gran cantidad de partes móviles, lo suficiente para ser un dolor de cabeza a la hora de configurar. Sin embargo, hay un atajo: aprovisionar plantillas de solución IoT, que creó toda la gama de servicios de Azure junto con algunos dispositivos simulados. Una vez que la solución se aprovisiona, puede sumar y restar servicios y clientes, según sea necesario.

Actualmente hay dos plantillas de solución IoT: una para el monitoreo (Figura 2) y otra para el mantenimiento predictivo. Este último no solo es más útil y especializado; sino que también requiere monitoreo en tiempo real de antemano, así como un poco de registro de eventos, análisis de datos, construcción de modelos, y el ajuste del modelo. Como ya he aprendido de primera mano hace muchos años cuando automaticé un ciclotrón, incluso los sistemas para los que existen ecuaciones exactas exhibirán comportamientos inesperados que necesitan ser añadidos al modelo, y eso requiere tiempo y experiencias amargas.

Además de Azure Stream Analytics, Azure IoT suele almacenar datos en gotas. Estos pueden ser analizados mediante HDInsight y el aprendizaje automático, luego incorporarse a Power BI para un análisis adicional, tanto de rutina como ad hoc.

La Suite de la IoT Azure ofrece actualmente dos plantillas de solución. Arriba se muestra el diagrama del sistema para la solución de Monitoreo Remoto.
Hub IoT Azure

En general, hay muchas cosas buenas en la IoT de Azure. Si bien es útil para muchas aplicaciones en su estado actual, varias piezas siguen desaparecidas, incluido el intermediario de puerta de entrada, lo que eventualmente permitirá a los grupos de dispositivos trabajar sobre ZigBee, Z-Wave, Insteon o Bluetooth Low Energy para enviar datos al Hub IoT y aceptar comandos desde ahí. Al menos Microsoft está hablando de esta necesidad; todavía no he escuchado que AWS haya anunciado planes para los dispositivos conectados sin IP.

Si compara las puntuaciones obtenidas en mis críticas a las IoT de Azure y AWS, descubrirá que son idénticas en todas las categorías. Es cierto que existen diferencias entre los dos servicios, pero no vale la pena desde un punto completo -y completamos nuestros resultados con los números enteros.

En el área de valor, se me hace muy difícil predecir los costos relativos entre las dos plataformas. La IoT de AWS cobra por cada millón de mensajes de entrada y salida; IoT de Azure tiene un sistema de tipo de niveles que depende del número de dispositivos, así como el volumen de mensajes. En cualquiera de los casos hay una media docena de otros servicios que probablemente utilice como parte de su solución, todos los cuales tienen sus propios costos.

En este punto, no hay un claro ganador. No estoy seguro de que lo sea siempre, pero sin duda hay diferencias entre los dos enfoques, y uno puede estar más cerca de sus necesidades, habilidades y preferencias que el otro.

El apoyo de Microsoft para el desarrollo .Net y bias en contra de los entornos de desarrollo de Mac son dos diferencias claras. También hay una diferencia arquitectónica. IoT de AWS utiliza la autenticación basada en certificados, y el protocolo MQTT, todos los cuales se adaptan a los clientes más simples. Azure tiene preferencia por el protocolo AMQP y el uso de tokens SAS para la autenticación del cliente, que está más orientado hacia Raspberry Pi 2 o Intel Edison que, por ejemplo, un Arduino Mini.