Introducción

IoT (Internet of Things) es un tipo de sistema distribuido cuya infraestructura pretende interconectar el mundo físico y el mundo virtual (procesamiento y reacción ante eventos del mundo real y virtual), creando así servicios avanzados para la sociedad de la información.

Ya que el IoT se compone de un gran número de dispositivos edge (la T del IoT, things, habitualmente sistemas empotrados), plantea dos desafíos principalmente:

1. Procesamiento de los datos; teniendo en cuenta un mundo interconectado cuya información del mundo físico se está captando constantemente por sensores y otros métodos, hay que procesar, almacenar y analizar una enorme cantidad de datos que se están generando constantemente. Candidatos de solución: Cloud/fog computing.
2. Aceleración del desarrollo y depliegue de software en dichos dispositivos; para actualizar y mantener el software que se ejecuta en los dispositivos edge hay que adoptar un nuevo modelo que permita el desarrollo y despliege rápido, frecuente y que no sea disruptivo con los servicios. Candidatos de solución: DevOps.

Cloud/Fog Computing se refiere al procesamiento de los datos en máquinas high-end. Fog computing sería la versión jerarquizada de este procesamiento de datos; yendo desde los dispositivos con menos potencia computacional (low-end, empezando por los edge devices) hasta los servidores más potentes (high-end, ya más cercanos al concepto de cloud computing).

DevOps: Abreviación de Development and Operations es una aproximación cultural/organizativa (una filosofía) que pretende romper la barrera entre los procesos del desarrollo software (development) y de la operación del servicio (operations/operational) para conseguir CI/CD (despliegue e integración continuos, es decir, rápido, frecuente y no disruptivo).

Para conseguir estos dos objetivos, nos serán de utilidad las herramientas de Virtualización (Máquinas Virtuales) y Contenedores (Como Docker).

ALM – Application Lifecycle Management

ALM son los procesos y herramientas que ayudan a las organizaciones a gestionar toda la vida útil del desarrollo de aplicaciones software (desde la especificación de requisitos hasta el despliegue y operación del servicio) de tal manera que los servicios estén siempre disponibles.

Es muy común a día de hoy (2020) que todos los procesos ALM estén altamente disgregados entre sí, frenando la innovación y la entrega a tiempo de productos ya que dificultan el trabajo de las otras partes (procesos) porque no se tienen en cuenta entre ellos: el desarrollador no tiene en cuenta todo el hardware en el que se va a desplegar el software.

ALM y DevOps

DevOps pretende eliminar esta disgregación entre la parte de desarrollo (dev-elopmen, que se centra en la innovación) y la parte de operación (ops-operations, que se centra en que el servicio/producto sea estable en cada despliegue).

Con las metodologías ágiles de desarrollo se consiguió romper la barrera entre la parte de negocio y la parte de desarrollo: los cambios son bienvenidos incluso en las etapas tardías de desarrollo, estrecha colaboración entre el cliente y el equipo de desarrollo, desarrollo iterativo e incremental para entregar cuanto antes el MVP (Minimum Viable Product).

Ahora se pretende romper la barrera existente entre la parte de desarrollo y de operación/despliegue con DevOps.

DevOps

Su aplicación es complicada ya que entra en conflicto con la cultura tradicional del flujo de trabajo; requiere de ciclos cortos, entrega continua (mínimo un despliegue al día para considerarse CD/CI) y equipos multidisciplinares.

Buenas prácticas

• Entrega continua: en DevOps se debe realizar CI/CD para reducir el riesgo en despliegues y entregas.
• Feedback continuo: uso de métricas para la identificación y solución rápida y efectiva de problemas.
• Mejora continua (del producto): uso de prácticas de implantación cultural orientadas a la mejora y aprendizaje continuos.

Desafíos en IoT

• Necesidad de una pila estandarizada (como LAMP) para el contexto del IoT.
• Administración remota de miles de dispositivos edge (configuración, y actualización).
• Uso de contenedores para ciclos de despliegue rápido.
• Enfoque a microservicios (permiten que la calidad de las aplicaciones se construya a partir de componentes creados individualmente, que abordan procesos y funciones específicos).
• Pipeline (flujo) de desarrollo + despliegue complejo y fragmentado (hay que tener en cuenta el firmware del dispositivo, el backend
• Posible existencia de dispositivos «legacy» que provoquen incompatibilidades.
• IaC (Infraesstructure as Code) & EaC (Enviroment as Code): Hay que probar el producto en los entornos de producción, los cuales suelen ser heterogéneos en IoT (diferentes arquitecturas, muchos tipos de dispositivos diferentes…); hay que pasar esos entornos a código (mediante virtualización y/o contenedores) para conseguir que la infraestructura esté representada con código (IaC) y posteriormente conseguir simular el entorno mediante código (EaC).
• Automatización del despliegue
• Necesidad de un estándar: actualmente existen el P2675-DevOps y el C/S2ESC – Software & Systems Engineering Standards Committee.

Gestión de la configuración

Herramientas utilizadas para mantener la trazabilidad de las propuestas de cambio, gestión/almacenamiento de versiones (de los componentes del sistema), creación/compilación y para mantener la trazabilidad de las versiones de las entregas.

La gestión de la configuración requiere además de la automatización de un pipeline de integración (compilación+testing) y despliegue para conseguir:

• CI (Continuous Integration / Integración continua): integración, compilación y validación de código en el entorno de desarrollo (mínimo una vez al día para considerarse CI). Requiere de un servidor de integración (CI Server) para realizar estas tareas de forma automatizada.

• CD (Continuous Delivery / Entrega continua): capacidad para realizar despliegues continuos bajo autorización manual (existe la capacidad de despliegue frecuente pero se decide limitar dicha frecuencia debido, normalmente, a decisiones de negocio). Se prioriza el hecho de tener código listo para ser desplegado (esto es, código ya testeado en el pipeline de CI) antes que el hecho de tener funcionalidades nuevas (cambios pequeños y controlados).

• CD (Continuous Deployment / Despliegue continuo): sin autorización manual, cada actualización en la integración de nuevo código es desplegada automáticamente en entorno de producción/explotación.

NOTA: Staging, QA (Quality Assurance), UAT (User Acceptance Test): se usa para referirse a las etapas anteriores a la de producción. Cada una de ellas sigue una metodología diferente para aceptar el despliegue, pero las tres se basan en la comprobación, bajo algún criterio, de que todo está OK antes del despliegue.

NOTA: Check-in: proceso de actualización (push) del código desde el entorno de desarrollo al repositorio global.

Para que el CI/CD esté completo es necesaria la obtención de feedback en cada una de las etapas y procesos (en la compilación, en las pruebas de integración, en el despliegue en entorno de pruebas y en el entorno real, etc).

Metodologías de desarrollo

En desarrollo software tenemos principalmente tres tipos de metodologías de desarrollo: incremental, iterativo e iterativo-incremental. Uso de CI/CD en cada una de ellas:

• Incremental: se puede usar CI sin problemas pero casi imposible conseguir implantar CD ya que se basa en el despliegue continuo de código mientras que el desarrollo incremental debe esperar a tener alguna funcionalidad nueva para realizar un nuevo despliegue.

• Iterativo: se puede usar CI/CD sin problemas ya que no requiere que el producto sea funcional en su totalidad cuando se despliega alguna parte (en cada iteración puede implementar sólo una parte de la funcionalidad deseada, o incluso ninguna).

• Iterativo-incremental: también se puede aplicar CI/CD pues cada iteración no tiene por qué estar funcionalmente completada y posteriormente se va refinando cada «módulo» hasta conseguir todas las funcionalidades deseadas.

Herramientas

Para conseguir DevOps actualmente disponemos de algunas herramientas útiles que facilitan tareas como el pipeline de CI/CD.

Para virtualización por interfaz de línea de comandos para la gestión automatizada de máquinas virtuales (incluyendo archivos de configuración para la instalación automática de software)

Virtualización y contenedores

En el ámbito del IoT mantenido por un equipo de desarrollo que abrace la cultura DevOps, se requiere: por un lado estandarización y homogeneidad sobre los dispositivos sobre los que se va a desplegar algún microservicio de nuestro sistema y por otro lado la alta disponibilidad y escalabilidad horizontal de la computación de los datos generados por los dispositivos.

Lo primero se logra mediante el uso de un kernel común y los contenedores

El segundo puede lograrse mediante el uso de máquinas virtuales y/o contenedores para la replicación y por ende la alta disponibilidad de recursos.

Para estos cometidos tenemos:

Vagrant: para la virtualización automatizada. Hace uso de un archivo de configuración llamado Vagrant File que, de forma automatizada, genera la máquina virtual deseada, reservando los recursos indicados, aplicando la imagen de SO deseada e incluso instalando software específico.

Docker: para los contenedores, que permiten aislar secciones sobre el kernel del SO para que las aplicaciones no entren en conflicto por problemas de incompatibilidad directa o por dependencias de versiones de software (son entornos, similares a los «enviroments» de python, pero estandarizados para funcionar directamente sobre el SO con cualquier tipo de software).

Crear un contenedor en Docker:

La forma de crear un contenedor con Docker se realiza mediante un archivo de configuración llamado DockerFile el cual se «compila» para crear un DockerImage, un paquete con todo el software + dependencias necesarias que puede ejecutarse directamente en un «container runtime» (un host de docker). Cuando se ejecuta la DockerImage, esta pasa a memoria de forma aislada en la máquina host, compartiendo únicamente ficheros y puertos (si se ha configurado así); en ese momento pasa a llamarse contenedor o «Docker Container«.

Gestión de versiones y orquestadores

Docker incluye un sistema de repositorio + gestión de versiones para el uso en CI/CD automático. Esto es útil además para la automatización de creación de réplicas/clusters (swarms) con «Docker Swarm» o «kubernetes«…

…o bien para la creación automática de contenedores para sistemas que hagan uso de varios servicios contenedorizados al mismo tiempo (stacks) con «Docker Compose«.

Contenedores en el contexto de DevOps: