El Internet de las cosas (IoT) sigue siendo un tema de interés. Y aunque los dispositivos y artilugios orientados al consumidor suelen acaparar los titulares, lo que más me fascina es el trabajo entre bastidores que los primeros usuarios están llevando a cabo para preparar los centros de datos.
Probablemente porque queda mucho trabajo por hacer para respaldar una iniciativa de IoT a gran escala. Y, cuando la «cosa» va dirigida a los consumidores, no existe realmente un despliegue de IoT a pequeña escala. Porque, por si no se habían dado cuenta, hay muchísimos consumidores ahí fuera. Y les encantan los cacharritos relucientes.
Teniendo esto en cuenta, en estos momentos están sucediendo muchas más cosas en todo el sector tecnológico para apoyar tanto a quienes están integrando el IoT en productos existentes (coches, electrodomésticos, juguetes) como a quienes aspiran a convertirse en el próximo gran éxito con productos totalmente nuevos que no sabías que necesitabas hasta que tuviste uno.
En serio. Aunque el sector público encabeza la compra de soluciones de IoT (según nuestro informe Estado de la entrega de aplicaciones de 2016), los proveedores de telecomunicaciones, tecnología y servicios en la nube no se quedan muy atrás. De hecho, todos los sectores registraron un nivel de compras bastante bueno durante los doce meses anteriores, lo que indica que se está trabajando mucho más con el IoT de lo que parece si solo se presta atención al mercado de consumo.
Gran parte de lo que está ocurriendo se encuentra en la infraestructura; en la red que proporciona conectividad y permite que las aplicaciones del back-end respondan de inmediato para gestionar, medir, supervisar, proteger e interactuar con esos pequeños y simpáticos chips integrados en el osito de peluche favorito de tu hijo.
Como cualquier aplicación o cliente (porque eso es lo que son en realidad estos dispositivos remotos: clientes), necesitan un conjunto básico de servicios para funcionar de forma coherente, predecible y fiable. En concreto, necesitan servicios que proporcionen seguridad, entrega y visibilidad.
Seguridad
La seguridad suele ser lo último en lo que nos centramos cuando se trata de nuevas tecnologías, así que voy a empezar por ella, porque hoy en día son las brechas de seguridad las que suelen acaparar más atención, incluso en una tecnología incipiente como el IoT.
Los dispositivos necesitan comunicarse con las aplicaciones de back-end. Ya sea para guardar datos, obtener actualizaciones o parches, o cambiar configuraciones, los dispositivos deben comunicarse de forma segura con las aplicaciones de back-end. Esto implica admitir túneles seguros mediante SSL o TLS. También implica utilizar HTTP seguro, no texto sin cifrar, y no codificar claves directamente en los dispositivos. Esto último va muy en serio. No lo hagas.
La seguridad también implica validar la identidad. Sí, ya sé que esta cosa es un coche, pero ¿de *quién* es? Necesitamos servicios capaces de identificar los dispositivos de forma rápida y precisa, y de asociarlos con sus usuarios y propietarios autorizados, para reducir la posibilidad de que a mi vecino le dé por decidir que mi radio debería estar sintonizada en algo que no sea una emisora de heavy metal. ¡Qué horror!
Por último, la seguridad también implica analizar los protocolos. Esto es especialmente importante dados los nuevos protocolos cuya estandarización se está planteando en todo el universo del IoT. Las vulnerabilidades de los protocolos pueden suponer un riesgo considerable (quizá recuerde Heartbleed) y suelen ser difíciles de subsanar a tiempo. La capacidad de detectar posibles usos indebidos de los protocolos permite mitigar el riesgo desde el principio.
Entrega
Los datos, tanto transaccionales como de cualquier otro tipo, deben enviarse a los dispositivos y a las aplicaciones de back-end. Hacerlo no siempre consiste simplemente en mandar un montón de bits codificados en JSON a alguna API REST. Muchos dispositivos hablan los nuevos lenguajes del IoT: MQTT, CoAP y AQMP. Pero ¿qué ocurre con sus respectivas aplicaciones de back-end? Estas hablan REST, ya que también proporcionan a aplicaciones web y móviles acceso a las mismas funciones e información. En última instancia, esto significa que en algún punto de la ruta de entrega hay una pasarela, un traductor, un intermediario que permite la interoperabilidad entre protocolos.
Esto permite que el dispositivo de tu coche envíe datos o mensajes mediante MQTT que la aplicación de back-end que utiliza REST pueda entender. El intermediario intercepta y traduce (de forma segura) para que tu dispositivo y sus aplicaciones puedan comunicarse sin problemas. Piensa en el intermediario como C3PO y en tu coche (u otro dispositivo) como R2D2. Esto implica compatibilidad nativa con protocolos, así como un enfoque definido por software que proporciona una plataforma de scripting mediante la cual se puede desarrollar rápidamente la compatibilidad con otros protocolos. Scripting de la ruta de datos es uno de los tres componentes clave de la programabilidad de la red, pero es del que menos se habla. En lo que respecta al IoT y a la compatibilidad con lo que probablemente será una amplia variedad de protocolos y lenguajes, la flexibilidad que ofrece esta capacidad, a menudo poco reconocida, será inestimable.
Antes mencioné la escalabilidad como un aspecto que tener en cuenta, y es aquí, en la entrega, donde vemos cómo se satisface ese requisito. Para ampliar la capacidad y admitir, por ejemplo, un millón de dispositivos, probablemente se utilice una arquitectura de aplicaciones basada en la descomposición. Quizá no llegue a ser una arquitectura completa de microservicios, pero es probable que, como mínimo, se separen los dominios funcionales para poder escalar las distintas funciones con una metodología más eficiente y rentable.
Ahí es donde entra en juego algo como el balanceo de carga basado en mensajes. Quizá recuerde que este concepto se mencionó en el ámbito de los proveedores de servicios en relación con protocolos como Diameter y SIP, donde es imprescindible que el escalado sea eficaz y rentable.
El balanceo de carga basado en mensajes es importante porque protocolos como MQTT se basan en mensajes. Siguen un modelo de publicación-suscripción (pub-sub), similar al middleware basado en mensajes que quizá se haya oído mencionar y que opera en las entrañas de la empresa. En cualquier caso, se basan en mensajes, y esos mensajes deben analizarse y enviarse al servicio o dispositivo adecuado. Para hacerlo de forma escalable, el servicio de balanceo de carga debe ser capaz de analizar el mensaje y determinar adónde enviarlo para, a continuación, seleccionar un recurso adecuado que se encargue de procesarlo.
No es ni mucho menos tan fácil como parece, ya que los balanceadores de carga básicos tienen una capacidad limitada para analizar las aplicaciones. Sin embargo, será un requisito imprescindible para poder escalar los protocolos que prefieren los dispositivos IoT.
Visibilidad
Por último, la infraestructura debe ofrecer visibilidad. Esto implica poder ver qué está ocurriendo. La visibilidad de las transacciones seguras (inspección SSL) permite a los equipos de seguridad tomar medidas e identificar a los actores maliciosos. La visibilidad de los patrones de uso puede impulsar el escalado automático de los servicios adecuados.
La visibilidad no consiste únicamente en que el «big data» proporcione análisis operativos sólidos, sino también en disponer de informes y registros. La resolución de problemas va a complicarse mucho en estas arquitecturas complejas, y los registros serán fundamentales para que tanto las herramientas como las personas puedan localizar el problema.
Escalar y dar soporte al IoT no consiste únicamente en los dispositivos. Queda mucho trabajo por hacer en la red, en la infraestructura y en los marcos operativos necesarios para sustentarlo. La buena noticia es que, si eres una de esas personas que trabajan en las importantísimas arquitecturas de back-end que servirán de soporte para algún dispositivo interesante, siempre puedes argumentar que necesitas uno (o tres) para hacer pruebas.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.