- Tiempo de lectura: 4 minutos
- Problema: coste económico de la infraestructura tanto inhouse como cloud
- Observación: distribuimos dispositivos que tienen cada vez mayor capacidad de computación, y están infrautilizados
- Propuesta: aprovechar la capacidad de computación de todos los dispositivos conectados a nuestra plataforma que están geográficamente dispersos por todo el planeta
En los últimos cinco años he trabajado en el diseño de una compleja plataforma autodesplegable, cuyo objetivo es la aplicación de inteligencia Cloud en entornos industriales. Además, he tenido el gran honor de haber dirigido al equipo que ha desarrollado dicha plataforma. Ellos son los que han convertido en realidad mis diseños.
Boceto: diseño de plataforma híbrida. Autor: Fernando Sáenz
Una plataforma híbrida tiene innumerables “puntos calientes”, elementos de diseño y tecnología que son muy complejos. Desde protocolos de comunicación hasta los sistemas de crawling para Big Data, han sido muchos los retos que hemos tenido que identificar y superar.
Además de realizar labores complejas, la plataforma es en sí un entorno difícil de gestionar, no apto para administradores novatos. Las mismas características que la convierten en un sistema de posibilidades infinitas, son las que complican enormemente su administración. Tal es el caso, por ejemplo, de la capacidad de autodimensionarse, que le permite a la propia plataforma levantar o dormir nodos Cloud en función de la carga de trabajo que tiene, o que estima que va a tener.
Morfología
Dentro de toda esta complejidad, quiero centrarme en su morfología, ya que es una característica que considero muy replicable en otro tipo de plataformas. El núcleo del sistema, el “cerebro”, se encuentra en un conjunto de nodos Cloud. Se trata de una infraestructura Cloud más o menos clásica, en la que encontramos frontends de recepción de flujo de datos, balanceadores de datos, frontends de interfaz, balanceadores de interfaz, un pool de servidores backend para SGBD relacional, otro pool de servidores backend no relacional para Big Data, etc. Un administrador/diseñador de sistemas que haya trabajado en este tipo de entornos Cloud dominará perfectamente este punto.
Además de eso, nuestra plataforma trabaja con un gran número de captadores desplegados por el mundo, con los que se comunica. Los captadores reciben una serie de instrucciones del Cloud (sobre todo información relativa al despliegue), y transmiten un gran volumen de datos en continuo enviando información sobre su entorno. Por simplificarlo, pensemos que es una especie de maraña de dispositivos IoT.
Apretar las tuercas
Y aquí llegamos al quid de la cuestión. A medida que nuestra plataforma crece, también crecen sus capacidades, y por tanto puede dar servicio a un mayor número de clientes. Pero también aumenta su gasto. Es cierto que la infraestructura es cada vez más rentable a medida que crece el número de clientes que la utilizan, pero también es verdad que nuestro modelo de negocio busca una alta escalabilidad. Nos vemos obligados a estar continuamente intentando apretar las tuercas.
A medida que fuimos actualizando remotamente el firmware de todos estos dispositivos captadores, les fuimos dotando de más recursos para indicarnos su propio estado. Su temperatura, carga de CPU, consumo de memoria, consumo de disco, etc. Vimos que, sobre todo los de última generación (quad-core), estaban escandalosamente ociosos pese a tener una carga que nosotros creíamos que era fuerte. Este ocio, multiplicado por un número muy creciente de dispositivos, era “dinero” que estábamos tirando a la basura. Sobre todo teniendo en cuenta que nuestros clientes pagan el dispositivo, lo alimentan eléctricamente, y lo dotan de conexión a Internet. En resumen, dispositivos que a nosotros no nos suponen ningún gasto, pero que están a nuestras órdenes.
Pasando a la acción
Es evidente cuál fue nuestro siguiente paso; diseñar mecanismos para trasladar tiempo de cómputo desde el Cloud hacia los captadores. Pero con unas ciertas limitaciones que nos impusimos, sobre todo debidas a condiciones de seguridad de los datos. La limitación más importante es que un captador únicamente puede trabajar con datos de ese cliente concreto, es decir, con datos que él mismo haya capturado y transmitido en cualquier momento anterior. Aunque otros captadores hayan terminado su trabajo y estén ociosos, nunca cruzaremos datos entre clientes. El motivo es que, pese al alto grado de seguridad que incluimos en el cifrado de datos y comunicaciones, en última instancia el aparato está en manos de un tercero. Si se diera el caso de que un cliente abriese físicamente un captador para acceder a su disco y memoria, estaría entrando en sus propios datos. En un sector en el que la reputación es muy importante, toda medida de seguridad es aplaudida.
Conclusión
Esta nueva capacidad de nuestra plataforma está suponiendo más de un quebradero de cabeza, ya que la administración del sistema se complica todavía más si cabe. Pero es un paso que hay que dar a la fuerza, a veces no somos conscientes de estar infrautilizando la infraestructura que requieren nuestros sistemas. Y menos conscientes todavía del importante ahorro en costes que puede suponer invertir en dotar a una plataforma de esta capacidad, sobre todo en plataformas similares a la nuestra, donde el número de micro-nodos deslocalizados es muy alto.