Internet de las cosas

Usar el bus de servicios de Windows Azure para... ¡cosas!

Clemens Vasters

 

Cuando paseamos (o vitrineamos) a lo largo de una tienda de electrónica bien provista, descubrimos un abanico increíble de “cosas” que poseen la capacidad de conectarse a una red. No piense solo en teléfonos, tabletas, equipos portátiles o de escritorio, o solo en televisores, reproductores de Blu-ray y decodificadores. Piense en máquinas de café, refrigeradores y marcos de fotografías. Piense en dispositivos para abrir las puertas del garaje, sistemas de aire acondicionado y de alarma. Si mira a su alrededor y detrás de los paneles que cubren los entornos industriales o comerciales, como su propio edificio de oficinas, encontrará sensores de temperatura y humedad, sensores de movimiento, cámaras de vigilancia y una multitud de otros tipos de sensores e interruptores de control dentro de los equipos.

Muchos de estos dispositivos generan datos útiles: lecturas de temperatura; cantidad de tazas de café preparadas y la configuración del molinillo; imágenes infrarrojas que revelan que no hay nadie en la sala de reunión y por lo tanto se pueden apagar las luces. 

Resulta fácil imaginar un escenario en el que también querríamos cargar algunos datos en esas “cosas”, por ejemplo para enviar las imágenes más recientes de nuestros hijos (o mascotas) a un marco de fotografías que está en la mesita de la abuela; o cuando deseamos mover un interruptor a la distancia (incluso si esa distancia solo es el teléfono conectado a través de la red 3G/4G del operador móvil) para subir un poco la temperatura de la casa. Desde el punto de vista de las redes, esta realidad está a tres mundos de distancia, pero desde el punto de vista del consumidor no hay una diferencia considerable entre activar el interruptor en casa o hacerlo desde el interior de un taxi camino del aeropuerto después de unas vacaciones de dos semanas.

Las oportunidades que brindan los dispositivos conectados son enormes. La entrega de servicios para dispositivos especializados puede tener un potencial de capitalización mayor para los desarrolladores de la nube con cierta capacidad de innovación que las aplicaciones en dispositivos de pantalla de uso general adaptados para la interacción humana, como teléfonos, tabletas o varios de los factores en forma de PC. Esto parece ser especialmente cierto cuando esos dispositivos se combinan con las tecnologías de nube que surgen a partir del análisis de “big data”.

El escenario

Para el siguiente análisis de arquitectura, imaginemos que la oferta es un software como servicio (SaaS) para sistemas de aire acondicionado. Aunque el escenario es ficticio, igual que todos los números, los patrones y las magnitudes se acercan bastante a los escenarios reales que el equipo de Windows Azure ha analizado con socios y clientes.

Lo bueno de los equipos de aires acondicionado (desde el punto de vista comercial) es que existe una demanda saludable y las tendencias climáticas globales indican que no pasarán de moda en un futuro cercano. No tan bueno es su enorme consumo de electricidad y el hecho que pueden sobrecargar la red eléctrica en las regiones calurosas, lo que resulta en apagones en cadena.

La solución SaaS, para la cual perfilaré la arquitectura, se dirige a las empresas de electricidad que buscan información analítica sobre el uso del aire acondicionado para emplearla en la administración de la capacidad y para un mecanismo que les permita realizar grandes ajustes de emergencia en los sistemas de aire acondicionado que están conectados a la red eléctrica cuando esta está a punto de colapsar.

La apuesta es que los clientes preferirían que la temperatura ambiental se ajuste de manera forzada a una temperatura cómoda de 27 °C (80 °F) antes que sufrir el corte de la red de alimentación, lo que los dejaría indefensos contra la temperatura exterior asoladora de 38 °C (100 °F).

Supongamos también que el SaaS irá emparejado con una cantidad de fabricantes de equipos de aires acondicionado que integrará el hardware y los protocolos requeridos. Una vez que los dispositivos estén instalados y conectados al servicio, existirán oportunidades para vender aplicaciones complementarias bajo el nombre de las empresas de electricidad o de los fabricantes de equipos a través de tiendas de aplicaciones móviles que permitan que los clientes supervisen y controlen los equipos de aire acondicionado desde sus teléfonos o tabletas. En la Ilustración 1 encontramos la información general del escenario.

Ilustración 1 Información general de la solución de software como servicio

A medida que creamos la arquitectura de la solución, debemos acomodar dos direcciones generales de tráfico de mensajes. Entrante (desde la perspectiva de la nube): debemos recopilar métricas y eventos de los dispositivos, agregar los datos y enviarlos al sistema de análisis. Saliente: debemos ser capaces de enviar comandos de control a los dispositivos.

Cada dispositivo de aire acondicionado debe ser capaz de enviar las lecturas de humedad, temperatura y de estado del dispositivo, con una frecuencia que puede variar entre una hora y 10 minutos, según las necesidades. Los cambios en el estado del dispositivo también deben causar que se generen y envíen eventos. Los comandos de control serán mucho más escasos, probablemente no más de un evento o dos al día por dispositivo.

Para la implementación inicial, establecemos una escala objetivo de unos 250.000 dispositivos para el primer año, para alcanzar los 2,5 millones de dispositivos después del tercer año. A esa escala, podremos esperar entre 250 mil y 1,5 millones de eventos por hora para el primer año y cerca de 2,5 a 15 millones de eventos por hora durante el tercer año.

Arquitectura de la solución

En la arquitectura debemos abarcar tres áreas principales de preocupación: aprovisionamiento, absorción de los eventos y diseminación de los comandos.

El aprovisionamiento se relaciona con la configuración de los dispositivos nuevos, la asignación de una identidad única a cada uno dentro del sistema y la entrega de un método a cada uno para comprobar su identidad. Además, los dispositivos se deben asociar con recursos determinados dentro del sistema y deben recibir un documento de configuración que contenga toda esta información.

La absorción de los eventos implica diseñar el sistema para que pueda procesar la capacidad de proceso deseada para el consumo de los eventos. 15 millones de eventos por hora se traduce (aproximadamente) a unos 4.200 eventos por segundo, lo que justifica que nos tomemos el tiempo de reflexionar seriamente sobre cómo particionar el sistema. Este resulta justamente el caso en que dichos eventos se originan en 4.200 fuentes diferentes, donde cada cliente se conecta de manera remota y establece una sesión nueva, lo que puede tener repercusiones serias en la latencia de red.

Como los eventos y las estadísticas resultantes de cada unidad de vivienda en especial no solo importan en el nivel macro, sino que también para los residentes que compran la aplicación móvil y desean acceder a gráficos de tendencias precisos, no solo debemos enviar datos empaquetados para el análisis, sino que también idear la forma de conservar 360 millones de eventos por día.

La diseminación de los comandos trata del flujo de comandos hacia los dispositivos. Los comandos le pueden ordenar al dispositivo que cambie la configuración o pueden ser consultas de estado que le piden al dispositivo que emita un evento de estado. En los casos en los que las compañías eléctricas tienen que realizar ajustes globales para aliviar la presión en la red, es posible que deseen enviar un comando único a todos los dispositivos al mismo tiempo y en la manera más rápida posible. En el caso de los teléfonos móviles, en el que un residente desea ajustar la temperatura para su comodidad, el comando se dirige a un dispositivo determinado o a todos los dispositivos de la unidad de vivienda.

Absorción de los eventos

La Ilustración 2 muestra el diseño general del modelo de absorción para el escenario de aire acondicionado.

Ilustración 2 El modelo de absorción

El primer aspecto y el más evidente de la arquitectura es la presencia de particiones. En vez de ver la población de millones de dispositivos conectados como un todo, lo que hace es subdividir dicha población en particiones mucho menores de varios miles de dispositivos y, por lo tanto, más fácil de administrar. Pero la facilidad de administración no es la única razón para usar particiones.

En primer lugar, cada recurso en un sistema distribuido tiene un límite para la capacidad de proceso y de almacenamiento. Por lo tanto, lo que pretendemos es limitar la cantidad de dispositivos asociados con un solo tema de bus de servicio, para que los eventos enviados por los dispositivos no excedan la capacidad de proceso del tema y para que el trabajo pendiente de mensajes que se pueda acumular temporalmente no exceda la capacidad de almacenamiento del tema. En segundo lugar, también deseamos asignar los recursos de proceso apropiados y no queremos sobrecargar el back end de almacenamiento con demasiadas escrituras. Como resultado, deberíamos agrupar un conjunto relativamente pequeño de recursos con unas características de rendimiento relativamente conocidas en una “unidad de escala” autónoma y aislada en gran medida.

Cada unidad de escala admite un número máximo de dispositivos, lo que resulta importante para limitar los riesgos de la subida en cadencia escalable. Un efecto secundario grato del uso de las unidades de escala es que reducen en forma significativa el riesgo de una interrupción total del sistema. Si un sistema depende de un solo almacén de datos, y este tiene problemas de disponibilidad, entonces todo el sistema se ve afectado. Pero si por el contrario, el sistema se compone de 10 unidades de escala con almacenes independientes, entonces una interrupción en una de ellas solo afecta el 10 por ciento del sistema.

La decisión de arquitectura que aparece en la Ilustración 2 consiste en que los dispositivos envían todos los eventos a los temas del bus de servicios de Windows Azure, en vez de hacerlo a un extremo de servicio entregado por la solución. El bus de servicios de Windows Azure ya proporciona una puerta de enlace de servicios de red segura escalada horizontalmente para los mensajes, y conviene aprovechar dicha funcionalidad, cada vez que sea posible.

En este caso en especial, supondremos que todos los dispositivos son compatibles con HTTPS y, por lo tanto, pueden comunicarse directamente con el bus de servicios de Windows Azure con el protocolo existente. Sin embargo, a medida que los dispositivos se vuelven más económicos y más pequeños y poseen apenas unos pocos kilobytes de memoria y un procesar lento, la compatibilidad con SSL (y, por lo tanto, con HTTPS) se puede convertir en una dificultad significativa, e incluso HTTP puede comenzar a verse demasiado pesado. Estos son los casos donde crear y ejecutar una puerta de enlace de red personalizada (consulte el extremo derecho de la Ilustración2) con un protocolo personalizado o uno de industria vertical resulta ser una buena idea.

Cada tema de absorción se configura con tres suscripciones. La primera suscripción es para un escritor de almacenamiento que escribe el evento recibido en un almacén de eventos; la segunda suscripción es para un componente de agregación que acumula los eventos y los envía al sistema de estadísticas global y; la tercera suscripción es para enrutar los mensajes al sistema de control de dispositivos.

Como límite de capacidad de proceso para cada uno de estos temas, supondremos un promedio de 100 mensajes por segundo en el nivel de la entidad. Como crearemos y enrutaremos tres copias de cada evento enviado, podemos absorber a lo más 33 mensajes por segundo en cada tema. Evidentemente, esto resulta ser un número (inquietantemente) defensivo. La razón para ser tan cauteloso es que estamos trabajando con dispositivos distribuidos que envían mensajes cada hora; resultaría ingenuo suponer una distribución perfecta y aleatoria para el envío de eventos a lo largo de una hora dada. Si suponemos el peor escenario posible de un intervalo de eventos de 10 minutos con un mensaje de interacción de respuesta de control adicional por dispositivo y hora, podemos esperar siete mensajes por hora de cada dispositivo y, por lo tanto, si aproximamos hacia abajo, podemos conectar alrededor de 50.000 dispositivos a cada tema.

Si bien esta tasa de flujo no representa dificultades para la capacidad de proceso de almacenamiento, la capacidad de almacenamiento y la capacidad de administración del almacén de eventos sí deben preocuparnos. Los datos de eventos por dispositivo en una resolución de una hora para 50.000 dispositivos alcanza cerca de 438 millones de registros de eventos por año. Incluso si somos muy codiciosos con el empaquetado de estos registros y usamos solo unos 50 bytes por cada registro, de todas maneras nos encontraremos con unos 22 GB de datos por año para cada unidad de escala. Esta cantidad es controlable, pero también demuestra que debemos mantener vigilada la capacidad de almacenamiento y el crecimiento del almacenamiento cuando pensamos en el tamaño de las unidades de escala.

Basado en la proyección de crecimiento de un año, necesitaremos cinco de estas unidades de escala para el primer año y 50 después del tercero.

Almacenamiento, recuperación y agregación de eventos

Ahora veamos más detenidamente cómo se controlarán y usarán los eventos entrantes. Para ejemplificar lo anterior, en la Ilustración 3 vemos una de las unidades de escala más de cerca. 

Ilustración 3 Una unidad de escala

Los mensajes que se originan en los dispositivos se pueden dividir en dos grandes categorías: respuestas de control y eventos. La suscripción del sistema de control filtra las respuestas de control. Los eventos, que contienen el estado actual del dispositivo y las lecturas del sensor, se enrutan al escritor de almacenamiento y al agregador a través de suscripciones separadas.

El trabajo del escritor de almacenamiento consiste en recibir un evento de la suscripción y escribirlo en el almacén de eventos.

Para almacenar los eventos, el almacenamiento de tablas de Windows Azure es un excelente candidato. De acuerdo con el modelo de particionamiento, tendremos una cuenta de almacenamiento compartida a lo largo de todas las particiones del sistema y una tabla por partición. El almacenamiento de tabla requiere de una clave de partición para asignar las filas de datos a una sección de almacenamiento y usaremos el identificador del dispositivo para dicha clave, con el beneficio de un rendimiento favorable en las consultas cuando necesitemos estadísticas históricas para crear gráficos. Para la clave de la fila, simplemente usaremos una marca de tiempo codificada en una cadena en un formato compacto AAAAMMDDHHMMSS, que entrega un ordenamiento cronológico y permite consultas de intervalos para la creación de gráficos. Además, y debido a que los dispositivos individuales nunca (en este caso) enviarán eventos en intervalos inferiores a un segundo, no tendremos que preocuparnos por posibles colisiones. La marca de tiempo se deriva de la propiedad EnqueuedTimeUtc del mensaje que el negociador del bus de servicios de Windows Azure establece automáticamente en cada mensaje entrante, por lo que no tendremos que confiar en el reloj del dispositivo. Si tuviéramos que crear una solución de alta capacidad de proceso, donde existiera la posibilidad de colisiones, podríamos aprovechar también la propiedad SequenceNumber del mensaje, que corresponde a un identificador único y secuencial de 64 bits que el negociador define para cada mensaje.

La tarea del agregador es tomar los eventos entrantes y acumularlos para que se puedan enviar a uno de los temas de estadísticas en todo el sistema que alimentan la infraestructura de análisis. Para esto, se suelen calcular promedios o sumas dentro de conjuntos de eventos para una determinada duración y solo se envían los valores calculados. En este caso, podríamos estar interesados en las tendencias de las lecturas de energía y temperatura en función del vecindario, con una resolución de 15 minutos. De esta forma, el agregador (que se ejecuta en dos funciones web, cada una de las cuales ve aproximadamente la mitad de los datos) mantendrá un mapa de los dispositivos por casas y vecindarios, agregará los datos en depósitos por vecindario a medida que llegan los eventos de los dispositivos y emitirá un evento con los agregados calculados cada 15 minutos. Como cada instancia del agregador solo ve la mitad de los eventos, es posible que el back end de análisis que está detrás del tema estadístico deba hacer una consolidación final de los dos eventos para obtener el panorama completo del vecindario.

El primer artículo de esta serie en MSDN Magazine, “Creación de Internet de las cosas” (msdn.microsoft.com/magazine/hh852591) trata sobre el uso de Microsoft StreamInsight en el contexto de los dispositivos. Ilustra a la perfección la etapa de consolidación; el ejemplo descrito en el artículo podría fácilmente tomar el lugar del agregador de esta arquitectura.

Diseminación de los comandos, dirección y recopilación de las respuestas

Tal como se aprecia en la Ilustración 4, el sistema de control envía comandos a los temas y los dispositivos reciben mensajes desde las suscripciones para la diseminación de los comandos.

Ilustración 4 El modelo de diseminación del control

El argumento clave para usar una suscripción por cada dispositivo es la confiabilidad. Cuando enviamos un comando, queremos que este finalmente llegue al dispositivo, incluso si el dispositivo está apagado o no está conectado momentáneamente. Por lo tanto, necesitamos el equivalente de un buzón de correo para el dispositivo.

Es costo de esta confiabilidad y flexibilidad adicional es una mayor complejidad. El límite de la capacidad de proceso para cada entidad que he analizado también se manifiesta en el número de suscripciones que el bus de servicios de Windows Azure permite en cada tema; la cuota del sistema actualmente establece un límite de 2.000 suscripciones para cada tema. La cantidad de suscripciones que realmente asignamos a cada tema para el escenario de diseminación del control depende del caudal deseado. El costo asociado con el filtrado y selección de un mensaje para una suscripción se puede ver como una operación de copiado. Por lo tanto, un tema con 1.000 suscripciones entregará un caudal de un mensaje por segundo, si suponemos una capacidad de proceso por entidad de 1.000 mensajes por segundo.

Para los comandos de emergencia, debemos enviar un comando a todos los dispositivos conectados en forma de transmisión. Para los comandos dirigidos, en que un consumidor ajusta la temperatura de un dispositivo puntual o en una casa determinada mediante una aplicación conectada en 3G, el ajuste debe ocurrir en pocos segundos.

Para saber si un mensaje por segundo también es suficiente para los comandos dirigidos, supongamos que un residente ajustará o solicitará el estado actual de su sistema de aire acondicionado muy de vez en cuando. Esperamos que la mayoría de los comandos ocurrirán durante sucesos climáticos importantes. Supongamos, en forma pesimista, que cada dispositivo se ajusta una vez al día y que dichos ajustes generalmente ocurren entre las 7 de la mañana y las 7 de la tarde. Si suponemos un límite de 1.000 suscripciones por tema para el caso de la transmisión, estos comandos tendrán como resultado un requerimiento de 1,4 mensajes por minuto. Incluso si todos activaran los equipos de aire acondicionado a la misma hora, no tendríamos problemas con unos 16 mensajes por minuto. Como resultado de estas consideraciones de escala y capacidad de proceso, limitaremos cada tema de diseminación del control a 1.000 suscripciones, lo que significa que necesitaremos 50 temas de diseminación del control para cada unidad de escala.

Para dirigir mensajes a dispositivos o unidades de vivienda determinados o enviar mensajes de transmisión a todos los dispositivos, podemos usar filtros de suscripción. En la Ilustración 5 vemos un filtro sencillo que permite los mensajes que poseen una propiedad con un DeviceId o HousingUnit determinado, o que establecieron en verdadero la propiedad personalizada Broadcast. Si se cumple cualquiera de estas condiciones, el mensaje se selecciona para la suscripción. Así, el sistema de control puede usar el mismo tema para los mensajes de transmisión y dirigidos, y selecciona los objetivos al configurar las propiedades de enrutamiento respectivas en el mensaje.

Ilustración 5 Dirección de los mensajes

El sistema de control también puede recibir respuestas a comandos mediante la suscripción en el lado de la absorción, donde las respuestas a los comandos tienen propiedades especiales de filtro que se controlan de manera semejante.

Estructura del espacio de nombres, aprovisionamiento e identidades del dispositivo

El bus de servicios de Windows Azure usa la noción del espacio de nombres para organizar los recursos y gobernar el acceso a dichos recursos. Los espacios de nombres se crean a través del portal de Windows Azure y están asociados con una región determinada del centro de datos. Si una solución abarca varias regiones geográficas grandes, podemos crear varios espacios de nombres y luego asignar los recursos y clientes a un centro de datos Windows Azure determinado, con la evidente ventaja de unas rutas de red más cortas. Para esta solución puedo crear un espacio de nombres en la región norte/central de los EE. UU. (clemensv-ac-ncus-prod.servicebus.windows.net) y otro en la región sur/central de los EE. UU. (clemensv-ac-scus-prod); o también puedo crear espacios de nombres para los clientes de una empresa de suministro eléctrico determinada (clemensv-­ac-myenergy-prod). El sufijo “prod” distingue los espacios de nombre de producción de posibles pruebas paralelas o espacios de nombre provisionales.

Para facilitar la configuración y la administración de las unidades de escala, aprovechamos la estructura jerárquica del espacio de nombres. El nombre de la unidad de escala, que forma la ruta base para todas las entidades dentro de la unidad de escala, puede ser simplemente un número, o se puede asociar con un cliente determinado (/myenergy-3). Como tenemos un solo tema de absorción, podemos ponerlo directamente debajo (/myenergy-3/fan-in) y luego ponemos los temas de diseminación del control debajo de otro segmento, enumerando simplemente los temas (/myenergy-3/fan-out/01). Las suscripciones de diseminación del control para los dispositivos individuales vienen después de esa estructura, donde usamos el identificador del dispositivo como el nombre de la suscripción (/myenergy-3/fan-out/01/subscriptions/0123456).

La creación de una nueva unidad de escala es, de hecho, un script de administración (con la API del bus de servicios de Windows Azure) que crea una nueva estructura con esta forma. Las suscripciones para los dispositivos y las reglas de filtro se crean durante el aprovisionamiento de los dispositivos. Por supuesto, también debemos crear, implementar y configurar el almacenamiento correspondiente y los recursos de proceso. Para el almacén de eventos, tal como vimos previamente, configuraremos una nueva tabla por cada unidad de escala.

El aprovisionamiento se relaciona con la incorporación de un dispositivo nuevo de fábrica al instalarlo la una unidad de vivienda. Para este artículo, omitiré algunos detalles como la desactivación de los dispositivos y simplemente analizaré un modelo de aprovisionamiento en el que los dispositivos se configuran con un identificador de dispositivo único en la fábrica. El modelo alternativo sería que los dispositivos vengan desde la fábrica sin ningún tipo de inicialización e implementar un esquema semejante a lo que conocemos de los servicios como Netflix, Hulu o Twitter, donde un dispositivo nuevo se pone en contacto con un servicio web para obtener un código y luego muestra el código y el usuario inicia sesión en un sitio de activación al escribir el código.

En la Ilustración 6 podemos observar el flujo para el aprovisionamiento de un dispositivo que posee un identificador asignado previamente. El primer paso de la configuración del dispositivo no aparece y se relaciona con la conexión del dispositivo a una red, lo que puede suceder con cable a través de Ethernet, Wi-Fi o alguna red de operador inalámbrico.

Ilustración 6 Modelo de aprovisionamiento

Para el aprovisionamiento, el sistema ejecuta un servicio web especial que controla la configuración y la administración de la identidad y la configuración del dispositivo. El asignador de partición lleva un registro de la cantidad de dispositivos que se activaron y qué dispositivos están asignados a qué unidad de escala. Al asociar un dispositivo a una unidad de escala, el dispositivo se aprovisiona en la unidad de escala.

En el paso 1, el dispositivo establece una conexión con el servicio de aprovisionamiento al presentar el identificador del dispositivo. En este modelo, todos los identificadores de dispositivo emitidos están en una lista de permiso (paso 2), que permite activar el dispositivo una vez. Una vez que se confirma que el dispositivo está aprobado para la activación, el servicio de aprovisionamiento llama al servicio de control de acceso (ACS) para crear una nueva identidad y clave de servicio para el dispositivo (paso 3) y también crea una regla de permiso “Send” para el tema de absorción y una regla “Listen” para la suscripción de diseminación de control creada inmediatamente después del paso 4. Con esto, la cuenta del dispositivo posee solo los derechos exactos necesarios para interactuar con el sistema. Después del paso 4, tenemos una colección de todos los URI de recursos con los que el dispositivo interactuará, como también una cuenta y clave que el dispositivo puede usar para autenticarse con ACS para obtener un token. Toda esa información se pone en la respuesta a la llamada de activación del dispositivo y este la escribe en un almacenamiento de configuración permanente.

Vale la pena destacar que si bien se presentó bastante información sobre el particionamiento de escala horizontal en este artículo, las identidades de control de acceso no se particionaron en este ejemplo.

Para liberar la presión de ACS, simplemente podemos hacer que el cliente adquiera menos tokens. El vencimiento predeterminado del token para la definición de la parte que depende de ACS para el bus de servicios de Windows Azure es de 1.200 segundos o 20 minutos. Podemos aumentarlo a 24 horas o 86.400 segundos y dejar que la memoria caché del dispositivo adquiera los token para ese período. En este caso, los dispositivos tendrán que adquirir un nuevo token solo una vez al día. La única desventaja es que no podemos revocar el acceso al portador del token, en caso de que se interceptara un token de tan larga vida, pero en el caso de los token que se limitan a enviar o recibir a entidades puntuales, esto parece ser un riesgo aceptable.

En la nube

La conexión de “cosas” a la nube y a través de ella es un área en la que el equipo de bus de servicios de Windows Azure se concentrará bastante durante los años siguientes. La arquitectura que perfilamos en este artículo es una que consideramos un buen punto de partida e incluye (por ejemplo, con relación al concepto de las unidades de escala) los procedimientos recomendados adquiridos con esfuerzo a partir de la creación del mismo bus de servicios de Windows Azure. Existe bastante espacio para optimizaciones con relación al flujo de los mensajes, agregación y la distribución de los mensajes, no solo en términos de capacidad, sino que también para modelos de programación y configuración más sencillos.

Comenzaremos a ver que algunas de estas optimizaciones, como el reenvío automático, aparecerán en el bus de servicios de Windows Azure dentro de algunos meses y el equipo aprovechará estas características nuevas para crear abstracciones mejores que permitirán simplificar la administración de los escenarios de escalado horizontal, como el descrito en este ejemplo. La distribución de eventos a millones de dispositivos a tiempo siempre requerirá de una gran cantidad de recursos de sistema diferentes, pero podemos agregar bastante magia de abstracción para reducir la cantidad de piezas visibles.

Para que el escenario sea más tangible y entretenido, el próximo artículo de la serie le ayudará a crear un equipo de aire acondicionado sencillo (¡sí, el hardware!) con la tecnología de Microsoft .NET Micro Framework. Este pequeño equipo de aire acondicionado “hágalo usted mismo” se comunicará con un servicio back-end a través del bus de servicios de Windows Azure con la arquitectura general que analizamos aquí. Hasta entonces.

Clemens Vasters es el líder técnico principal del equipo del bus de servicios de Windows Azure. Vasters ha estado en el equipo del bus de servicios desde las primeras etapas de incubación y trabaja en el mapa de ruta de las características técnicas del bus de servicios de Windows Azure, que incluye notificaciones de inserción y señales de a gran escala para la web y los dispositivos. También participa con frecuencia en congresos y es autor de cursos sobre arquitectura. Puede seguir a Clemens por Twitter en twitter.com/clemensv.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Elio Damaggio, Abhishek Lal, Colin Miller y Todd Holmquist-Sutherland