La prestiogiosa revista IoT de IEEE ha publicado el artículo «Devops for IoT Systems» editado por SATEC cuyo «abstract» es el siguiente: “Current Internet of Things (IoT) systems are highly distributed systems, which integrate cloud, fog, and edge computing approaches. Accelerating their maintenance and continuous improvement, while ensuring their availability, is complex. DevOps promotes fast and continuous feedback from operations to development to detect problems before customers are impacted, among other benefits. However, there is not any formal definition about how to do this. This paper defines the “fast and continuous monitoring feedback of system availability” activity (F&CF availability) that supports automatic and continuous monitoring feedback from operations to development of IoT system availability. This activity has been formalized through the software and systems process engineering metamodel (SPEM). Its implementation is demonstrated in a real scenario that provides evidence that the formalization of the F&CF availability activity helps teams in better diagnosing and fixing outage problems. The result is a distributed and configurable monitoring component developed through code (Monitoring as Code, MaC). This component is embedded in the IoT infrastructure. MaC enables DevOps team to configure their own metrics and indicators at run time, i.e. monitoring on demand. The formalization of this activity, based on a MaC technique, enables the automation, versioning, and replication of monitoring elements.”
Pero más allá del escenario de IoT y del caso de estudio, basado en la metodología Design Science, como medio para validar las propuestas a través de artefactos y resultados de sus pruebas, este trabajo expone algunas propuestas que pueden ser llevadas a la práctica de forma directa.
Propuestas referencias por IEEE
La primera de las propuestas que indico en el articulo referenciado por IEEE es la necesidad y la viabilidad de formalizar los procesos y actividades de DevOps para estimular la evolución de esta cultura hacia una metodología en ingeniería TIC. Para demostrarlo se ha formalizado la segunda practica de DevOps (Fast and Continuous Feedback, F&CF) utilizando el metamodelo de ingeniería de procesos de software y sistemas SPEM 2.0, pero que podría haberse realizado con cualquier otra metodología o herramienta de modelado como BPMN (Business Process Modeling Notation), UML (Unified Modeling Language), XPDL (XML Workflow Definition Language), IDEF (ICAM Definition Language), o cualquier otro.
Otra de las contribuciones es el desarrollo del concepto Monitorización como Código (Monitoring as Code, MaC) que consiste en la generación de componentes de monitorización distribuidos y configurables desarrollados a través de código. Estos componentes MaC se integran en la infraestructura de despliegue y ejecución del software y permiten al equipo de DevOps configurar sus propias métricas e indicadores en tiempo de ejecución, es decir, monitorizar un sistema bajo demanda. Además, la formalización de la actividad de DevOps F&CF, basada en una técnica MaC, posibilita la automatización, versionado y replicación de elementos de monitorización.
La implementación de la actividad “F&CF” para disponibilidad de sistemas IoT en un caso de estudio ha permitido la definición de pruebas de disponibilidad específicas, adaptadas al sistema bajo estudio mediante la definición de indicadores específicos y niveles de alarma, y la ejecución de estas pruebas sobre el sistema en ejecución minimizando los riesgos y detectando fallos muy rápidamente.
Como resultado del trabajo desarrollado extraemos dos conclusiones que podrían ser trasladadas a nuestras actividades:
- Las actividades principales de DevOps pueden formalizarse a través de su especificación formal durante las fases de diseño de software contribuyendo a convertir DevOps en una verdadera práctica de ingeniería del software, y no solo una cultura. Esta práctica de ingeniería además cohesionará más los equipos de DevOps y romperá silos entre los grupos de Desarrollo y Sistemas.
- EL desarrollo de componentes MaC puede ser una practica diferenciadora en procesos de mantenimiento y, sobre todo, de operación, y pueden formar parte de una oferta personalizada para clientes. Por ejemplo en un SOC (Service Operations Center) el desarrollo rápido de componentes de monitorización personalizados a las necesidades del cliente y de sus sistemas en producción puede ser una práctica diferenciadora.
Reproducción del artículo, “DevOps for IoT Systems: Fast & Continuous Monitoring Feedback of System Availability”, publicado por la revista IEEE Internet of Things Journal, una de las publicaciones técnicas con mayor factor de impacto, en su número de octubre de 2020. Puedes verlo pulsando aquí. Puedes ver mas sobre el rfc internet.
También te puede interesar: El comercio internacional durante la pandemia 👈