En nuestras anteriores entradas en este blog (algunas muy extensas, disculpad, pero había mucho que contar) hablamos sobre el sector agrícola incluyendo varios de los casos de uso generales que se presentan dependiendo de su aplicación: explotaciones, logística… y de la tendencia hacia Cloud Computing que ha habido en los últimos años no solo en este sector, sino en general. Pese a que este tipo de infraestructura tiene ventajas que ya comentamos, nos fijábamos también en sus desventajas para ver si algunas de ellas se podrían solucionar o paliar con otras alternativas de distribución de la computación.
Un breve recordatorio de las desventajas Cloud si no te quieres leer todas las entradas anteriores: 1) Hardware ya adquirido para sensorizar del que estamos desaprovechando sus inherentes capacidades de computación y/o almacenamiento (sensores, hubs…); 2) Pérdida de privacidad; 3) Pérdida de control sobre los datos; 4) Pérdida de ajustes sobre la QoS. 5) Aumento de coste a largo plazo; 6) Aumento de consumo energético.
Al aplicar Fog Computing vimos que algunos de estos problemas desaparecían (p.ej., privacidad), otros mejoraban (p.ej., mayor control sobre la QoS aunque algunos parámetros como la latencia siguen teniendo margen de mejora), otros continuaban (p.ej., seguimos necesitando comprar hardware para estas labores de cómputo y almacenamiento) y también aparecía algún problema nuevo (p.ej., aumento de coste a corto plazo derivados de la compra del nuevo hardware requerido).
StoreOnMe
Con StoreOnMe pretendemos paliar algunos de estos problemas concretamente respecto al almacenamiento con réplica de datos de sensores usando la propia red de sensores como infraestructura de almacenamiento. Lógicamente, ninguna solución (incluida esta), será válida para el universo de casos de uso concretos que se pueden presentar. No obstante, creemos que este tipo de aproximación, llevando a cabo el cómputo y el almacenamiento en la propia red de sensores que se despliega, permitirá según nuestros estudios previos abaratar costes en un sector con unos márgenes de maniobra muy pequeños. Tememos que si el gasto de despliegue de este tipo de soluciones es económicamente inviable o difícil de soportar, puede que tarde en llegar la revolución que ha supuesto IoT en otros ambientes a nuestros campos e industrias relacionadas.
StoreOnMe tiene una aproximación radicalmente diferente a la vista hasta el momento para el almacenamiento de datos distribuidos con réplica. Si bien no somos los primeros en explorar este campo y ha habido otras iniciativas desde el mundo académico, StoreOnMe es la primera propuesta que tiene en cuenta realmente las capacidades de cada elemento de la red para poder hacer posible el almacenamiento con réplica lo más seguro y ágil posible.
De nuevo, como discutíamos en post previos, nuevas implementaciones en nuevas capas pueden arreglar problemas de otras capas, pero no están exentas de incluir nueva problemática. Por ejemplo, en un entorno Fog cuando se cambia un servidor por otro nuevo (esto no ocurre de manera continuada) se puede hacer una migración del hardware antiguo al nuevo. Tratando con dispositivos IoT de bajo coste y además desplegados a cielo abierto, lo habitual es que los dispositivos requieran cambios cada menos tiempo. En Fog y Cloud los sistemas de cómputo y almacenamiento son inmóviles y pueden contar p.ej., con direcciones estáticas cuando se considera necesario para asignarles nombre… en Edge y Mist esto no es así siempre, siendo habitual situaciones con nodos móviles donde los sistemas además “aparecen” y “desaparecen” para ahorrar consumo energético.
Además, si tenemos varios servidores propios en Fog, al ser arquitecturas compatibles, aunque no sean los mismos modelos pueden comunicarse entre ellos perfectamente, al poder compartir el mismo software de comunicaciones, middleware y eso permite p.ej., aplicar políticas de balanceo a nivel de carga y almacenamiento con tecnologías existentes creadas justamente con ese objetivo. En Edge y Mist esto no es así, existiendo una amplísima variedad de sistemas y arquitecturas incompatibles entre sí en el sentido de no soportar el mismo middleware y en caso de soportarlo no siempre en el mismo grado, dependiendo de cada plataforma de destino.
En las capas Edge y Mist queda mucho desarrollo tecnológico por recorrer en este sentido, al ser capas que no han sido tradicionalmente usadas p.ej., para computaciones intensivas, ni para almacenamiento distribuido. Es por todo ello que Edge y Mist se trata de entornos de despliegue muy diferentes a lo que estamos acostumbrados en entornos Fog y Cloud y que migrar esas antiguas soluciones a estos nuevos entornos puede no ser viable y casi nunca será óptimo. Así pues, nuestra aproximación con StoreOnMe no es continuista con las soluciones existentes previas para otras capas (Fog y Cloud) debido principalmente a dos hechos.
Por un lado, creemos que no tiene sentido tener la misma aproximación para resolver el problema de computación o almacenamiento que en Fog, pues especialmente en Mist hablamos de hardware, con unas capacidades computacionales y de almacenamiento que no permiten la existencia de un sistema operativo tradicional de PC o servidor. Debemos recordar que los sistemas operativos son la primera capa de middleware entre el hardware y la aplicación de usuario y en los microcontroladores el sistema operativo y el aplicativo muchas veces se funden en un solo binario ejecutable (lo que no permite su cambio o ajuste rápido). No son procesadores pensados para resolver problemas generales a lo largo de su vida, sino para tener una funcionalidad concreta que correrá en ciclos o mediante eventos a lo largo de toda su vida útil.
Por otro lado, el contexto de ese hardware es diferente p.ej., en Fog presuponemos que si el sistema está en funcionamiento tiene energía y casi con toda seguridad si no ocurre nada extraño, conectividad. En cambio, entre los sensores en la capa Mist nos encontramos dispositivos móviles (p.ej., en tractores, cosechadoras, animales…) y/o fijos (en máquinas de embalaje, plantas…); que pueden tener fuentes de energía limitadas (batería) o no con flujos variables (p.ej., paneles solares); conectividad limitada (derivada de la propia movilidad del elemento y la cobertura en terrenos naturales o de limitaciones impuestas por la frecuencia usada en las comunicaciones entre otros); y capacidades de cómputo y almacenamiento muy heterogéneas (al ser hardware muy diverso de muy distintos fabricantes con arquitecturas muchas veces incompatibles entre sí).
Todo esto nos lleva a fijar una serie de 15 requisitos que un almacenamiento en la propia red de sensores debería tener en cuenta para ser efectivo, con requisitos que cubren todos los temas que llevamos comentando en todas nuestras entradas en este blog, relativos al soporte de dispositivos heterogéneos, adaptativo, escalable, mantenible, que proporcionase redundancia en el almacenamiento (réplica de cada dato) de manera distribuida… y no encontramos ninguna solución disponible que diese respuesta a la mayoría de estos requisitos. Si quieres ver los 15 requisitos que fijamos como imprescindibles para una solución de almacenamiento distribuido con réplica en Edge/Mist y cómo de cerca se quedan otras soluciones existentes de cubrirlos, puedes leer más aquí:
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8819993
Esto nos llevó a optar por crear una solución propia para la que buscamos un framework de desarrollo de microcontroladores que estuviese soportado por el mayor número de microcontroladores posible y sobre él construimos un sistema que permitiese interconectar los sensores de la capa Mist que deseamos adquirir para nuestra explotación, logística, industria… junto con los hubs o routers que ya debemos adquirir para centralizar estas comunicaciones en muchos casos de uso típicos del sector agroganadero. A estos elementos computacionales les dotamos, con la incorporación de nuestro framework, de capacidades adicionales de almacenamiento en el propio sensor, de manera que los datos no tienen que viajar a otras capas para ser almacenados y es el propio framework el que se encarga de seleccionar los nodos más adecuados para almacenar los datos que la propia red genera.
Esto permite ciertas mejoras que discutíamos como necesarias en entradas anteriores como p.ej., mejorar la QoS al mejorar la latencia y minimizando los puntos de ataque ante brechas de seguridad. Como no estábamos seguros de ciertas mejoras al 100%, las medimos y las publicamos de manera abierta en https://ieeexplore.ieee.org/abstract/document/8819993 . Os animamos a leerlo para ver p.ej., el tiempo que tarda el almacenamiento en la propia red de sensores en ser económicamente más rentable que el almacenamiento en Cloud, cómo se pueden variar ciertos parámetros de QoS con nuestra solución que Amazon o Google no nos permiten variar cuando usamos su infraestructura, o cuánta energía a nivel global podríamos ahorrar con este tipo de despliegues.
Este último tema, con el problema climático global que vivimos a la vez que queremos seguir innovando, uno de los que más nos preocupan actualmente y la solución que hemos propuesto evita el uso de grandes servidores corriendo de manera continuada, muchas veces apenas con carga de trabajo, pero con un gran consumo tanto de los propios servidores como de los sistemas de almacenamiento y comunicaciones requeridos ya no solo entre ellos, sino por la comunicación entre capas. Por similitud con lo que vemos en el consumo de productos agrícolas, defendemos una postura más cercana al “comercio local”, donde el producto se produce cerca de donde se consume, pero en nuestro caso se producen datos, que son los que se almacenan y procesan lo más cerca posible a donde se producen, en los nodos cercanos al propio nodo que los produce.
Ya disponemos de una versión desplegable que hemos estado probando en diversos casos de uso a nivel de laboratorio, por lo que el siguiente paso lógico, tras el apoyo recibido por la Cátedra Telefónica, es probarlo en casos de uso reales y adaptarlo en la medida que sea necesario para cubrir necesidades específicas que se deban contemplar.
Agradecer en esta última entrada a la Cátedra Telefónica de la Universidad de Extremadura el apoyo a este tipo de proyectos que permite que estos desarrollos tengan una mayor llegada al público, un mayor impacto y no queden relegados.