Patrones de Diseño del IoT
Ricardo Vega / 07 diciembre 2016
⏰ 5 minutos
Ricardo Vega / 07 diciembre 2016
⏰ 5 minutos
Como arquitecto de soluciones digitales, procuro conocer el máximo número de patrones de diseño disponibles para así tenerlos disponibles para su utilización en los diferentes proyectos en los que trabajo. Lleva unos meses queriendo compartir contigo alguno de estas guías de desarrollo pero específicamente orientadas al mundo del IoT.
En primer lugar, si no vienes de la industria del software es posible que desconozcas a qué nos referimos cuando hablamos de "Patrón de Diseño"; son metodologías y soluciones dadas a problemas comunes que buscan crear, mediante su aplicación, sistemas complejas empleando "plantillas" reutilizables que de algún modo estandarizan la solución dada y evitan esfuerzos innecesarios.
Tal vez en el mundo del software estén más acotados y sean más fácilmente localizables, sin embargo, cuando hablamos de IoT, a menudo son confundidos con Casos de Uso, lo que, desgraciadamente envuelve a este tema de un montón de ruido que sólo ayuda a crear más confusión, en especial para aquellas personas no técnicas relacionadas en el desarrollo del producto y el usuario final.
El Internet de las Cosas, como cualquier otro sistema, está compuesto de diferentes necesidades que necesitan resolverse y son comunes en gran número de productos. Piensa por ejemplo en el control remoto de un sensor A, en la conexión y envío de información entre un sensor B y un sensor C, la lectura directa de un sensor D, el almacenamiento de toda la información D y otra clase de problemas cuya solución puede ser reutilizada en diferentes sistemas. Para todo ello, construimos los Patrones de Diseño del IoT.
En esta entrada de hoy vamos a comenzar desde la base para descubrir cómo solventar estos problemas a nivel general. Creo que es un post muy interesante y que existe poca información al respecto, siendo prácticamente nula en inglés por lo que espero que te ayude.
En este caso, estamos hablando del envío del estado de una fuente de datos a un "host" conocido. Es un problema típico de los sensores telemétricos que envían datos a un servicio o plataforma usando protocolos como MQTT o peticiones POST a través de HTTP.
En este caso, el envío se produce cada cierto tiempo preconfigurado o cuando ocurre un evento que "merezca la pena" ser enviado pero, en todo caso, el envío se produce cuando el sensor así lo desea.
En este patrón de diseño, el sensor o nodo puede estar durmiendo y despertarse cada X tiempo o cuando se produce un cambio de estado lo que nos proporciona un más que evidente ahorro de energía y ancho de banda. Este despertar se parametriza con interrupciones (que veremos mucho más en detenimiento en otro post).
Es el caso justo contrario donde un nodo ejecuta una llamada o "query" contra otro elemento de la red para conocer su estado. En este caso, se emplea el paradigma cliente/servidor, actuando el sensor como un servidor web que devuelve la información cuando se le es requerido por un usuario o servicio.
Es un patrón muy común, en especial para aquellos desarrolladores con un "background" de desarrollo web a sus espaldas donde el uso de APIs REST es prácticamente un estándar. Como ventaja tiene su sencillez pero viene con una serie de problemas asociados en especial cuando intentamos escalar nuestras soluciones, buscamos sistemas muy rápidos en la respuesta o nos conectamos a Internet directamente empleando una dirección IP pública.
En este blog lo hemos empleado alguna vez pero no es un patrón que recomiende usar cuando pretendemos que nuestra aplicación vaya a un entorno de producción real.
Gracias a este patrón se pretende conseguir el envío de comandos a dispositivos remotos conectados a la misma red, disparando así acciones. Se emplea cuando se requiere una interacción física con el entorno lo que imposibilita que el sistema quede rígidamente configurado y sólo actue conforme a esa configuración.
Un sistema que es capaz de obtener órdenes del exterior no significa que se comporte de forma manual frente a los eventos que ocurren a su alrededor, sino más bien justo lo contrario, posibilitando la automatización y el ahorro de tiempo, esfuerzo, energía y dinero gracias al ajuste remoto integrado en la propia intelegencia del dispositivo y sus acciones preestablecidas.
Supone un reto extra de cara a la seguridad y obliga al nodo a estar constantemente despierto para comprobar si recibe órdenes extra lo que supone varios problemas en cuanto a consumo energético y respuesta del mismo en tiempo real.
En una solución real, podemos encontrarnos con la necesidad de implementar uno, dos o los tres patrones a la vez y dicha implementación se basará en nuestras propias necesidades, estableciendo patrones comunes dentro de los diferentes elementos que forman nuestra red.
Mi recomendación personal es evitar la improvisación y detenerse a pensar seriamente los requisitos de nuestra solución y las posibles evoluciones que tendrá nuestro producto en el futuro para diseñar una arquitectura ampliamente escalable que se adapte a tus necesidades y que implemente estos tres patrones de una forma eficiente y adaptada a las características de dicha arquitectura.
Además, el uso de cada patrón debe quedar claramente delimitado ya que estas implementaciones deberían comportarse como librerías para cada nuevo nodo del sistema que sea desarrollado, evitando que el diseñador o diseñadores principales tengan que estar presente en todas las inclusiones de nuevos elementos.
A partir de estos patrones y una arquitectura escalable, podemos empezar a trabajar realmente en casos de uso que queramos resolver y, como hemos visto en varios posts, pueden ser varios y económicamente muy provechosos.
¡Nos vemos la próxima semana con más contenido interesante!