Fundamentos en DevOps y arquitecturas de microservicios E-Book

José Manuel Ortega Candel

• Herausgeber: Marcombo
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Spanisch

Seitenzahl: 478

Veröffentlichungsjahr: 2025

Beschreibung

Domine DevOps y microservicios para construir el futuro del software La creciente demanda de aplicaciones más rápidas, escalables y resilientes ha impulsado la adopción de nuevas metodologías y arquitecturas. En este contexto, DevOps y la arquitectura de microservicios han emergido como pilares fundamentales para construir y operar sistemas de software modernos y complejos. Este libro se presenta como una guía integral para comprender cómo la filosofía DevOps y la arquitectura de microservicios se entrelazan para crear sistemas de software robustos, escalables y flexibles. A lo largo de sus páginas, aprenderá a: -Comprender la filosofía DevOps: descubrirá los principios de colaboración, automatización y mejora continua que forman el núcleo de esta cultura. -Dominar los microservicios: aprenderá a definir, diferenciar y descomponer monolitos en servicios pequeños y autónomos, entendiendo las ventajas y los desafíos de esta arquitectura. -Aplicar patrones de diseño: explorará estrategias para la comunicación síncrona y asíncrona, la gestión de datos y la seguridad en entornos distribuidos. -Implementar tecnologías clave: se sumergirá en el uso de herramientas fundamentales como contenedores (Docker y Kubernetes), la orquestación y las prácticas de CI/CD. -Garantizar la calidad y el rendimiento: Entenderá las prácticas de automatización, monitorización y observabilidad para asegurar la salud y la disponibilidad de sus sistemas. -Implementar prácticas de automatización: comprenderá las prácticas de automatización esenciales en un entorno DevOps, incluyendo la infraestructura como código, la gestión de la configuración y las pruebas automatizadas. Dirigido a desarrolladores, arquitectos, líderes de equipo y profesionales de operaciones, este libro aborda los conceptos esenciales, patrones de diseño, las tecnologías y herramientas que sustentan el desarrollo de aplicaciones modernas. Este libro es la hoja de ruta ideal para transformar los equipos de desarrollo en cualquier organización, al permitir construir sistemas más robustos, escalables y eficientes. Adquiera ahora los conocimientos que le distinguirán en la industria y le prepararán para liderar la próxima generación de proyectos de software.

Leseprobe

Fundamentos en DevOps y arquitecturas de microservicios

© 2026 José Manuel Ortega Candel

Primera edición, 2026

© 2026 MARCOMBO, S. L.

Gran Via de les Corts Catalanes 594, 08007 Barcelona

www.marcombo.com

Contacto: [email protected]

Ilustración de cubierta: Jotaká

Corrección: José López Falcón

Maquetación: Reverté-Aguilar, S.L.

Directora de producción: M.a Rosa Castillo

Cualquier forma de reproducción, distribución, comunicación pública o transformación de esta obra solo puede ser realizada con la autorización de sus titulares, salvo excepción prevista por la ley. Diríjase a CEDRO (Centro Español de Derechos Reprográficos, www.cedro.org) si necesita fotocopiar o escanear algún fragmento de esta obra.

ISBN del libro en papel: 978-84-267-4115-8

ISBN del libro electrónico: 978-84-267-4203-2

Producción del ePub: booqlab

Dedicado a los lectores. Su curiosidad y pasión por el conocimiento hacen que la escritura cobre vida.

Antes de comenzar a leer

El código fuente de los ejemplos, y todos los recursos didácticos y de programación que se emplean, podrán descargarse a medida que se avanza en la lectura.

Estos recursos están disponibles en www.marcombo.info con el código DEVOPS26.

Contenido

Cubierta

Título

Créditos

Contenido

Introducción

CAPÍTULO 1

Introducción a DevOps

1.1. Ciclo de vida DevOps

1.2. Arquitecturas DevOps

1.2.1. Principios de arquitectura de la infraestructura

1.3. SRE (Site Reliability Engineering)

1.3.1. SRE (Site Reliability Engineering) vs DevOps

1.4. Metodologías de desarrollo

1.4.1. Code First

1.4.2. API First

1.5. Otras metodologías DevOps

1.5.1. DevSecOps

1.5.2. DataOps

1.5.3. MLOps

1.5.4. AIOps

1.5.5. GitOps

CAPÍTULO 2

Arquitecturas basadas en microservicios

2.1. Introducción

2.2. Arquitectura monolítica vs arquitectura de microservicios

2.3. Características de las arquitecturas orientadas a microservicios

2.3.1. Despliegue

2.3.2. Contenedores y orquestadores

2.3.3. Monitorización

2.3.4. Alta disponibilidad

2.3.5. Autoescalado

2.4. Componentes de una arquitectura de microservicios

2.5. Arquitecturas de microservicios

2.5.1. Metodología DDD (Domain-Driven Design)

2.5.2. Comunicación entre microservicios

2.5.3. Servicios basados en HTTP y REST

2.5.4. Comunicación asíncrona basada en mensajes

2.5.5. Registro de servicios

2.5.6. Utilizando un API Gateway

2.5.7. Utilizando GraphQL

2.5.8. Utilizando gRPC

2.5.9. API REST vs GraphQL vs gRPC

2.6. Implementar una arquitectura de microservicios

2.7. Casos de uso de microservicios

CAPÍTULO 3

Patrones de diseño en microservicios

3.1. Introducción

3.2. Patrón Service Discovery

3.2.1. Client-side

3.2.2. Server-side

3.2.3. Soluciones para implementar Service Discovery

3.2.4. Service Discovery con Spring Cloud Eureka Server

3.3. Patrón DDD (Domain-Driven Design)

3.4. Command Query Responsibility Segregation (CQRS)

3.4.1. Eventos en CQRS

3.4.2. Casos de uso de CQRS

3.5. Event Sourcing para aplicaciones escalables

3.5.1. Casos de uso de Event Sourcing

3.6. Patrón Change Data Capture (CDC)

3.6.1. Kafka Streams

3.6.2. Debezium

3.7. Patrón Publish/Subscribe

3.7.1. Tópico compartido por n suscriptores

3.7.2. 1 tópico por cada suscriptor

3.7.3. n tópicos por cada suscriptor

3.7.4. n tópicos y m tópicos de forma compartida por cada suscriptor

CAPÍTULO 4

Estrategias de despliegue en microservicios

4.1. Introducción

4.2. Despliegue de microservicios en producción

4.2.1. Despliegue blue-green

4.2.2. Despliegue canary

4.2.3. Despliegue en fases (rolling deployment)

4.3. Integración continua (CI)

4.4. Despliegue continuo (CD)

4.5. Entrega continua

4.5.1. Ventajas de la entrega continua

4.5.2. Fases del pipeline de entrega continua

4.5.3. Integración continua vs entrega continua

4.6. Herramientas CI/CD

4.7. Estrategias para organizar repositorios

4.7.1. Monorepo

4.7.2. Multirepo

4.7.3. Estrategia híbrida

4.8. Versionado de código

4.8.1. GitFlow

4.8.2. Trunk Based Development

4.8.3. Git Flow vs Trunk Based Development

4.9. Infraestructura como código (IaC)

4.9.1. Ventajas de la IaC

4.9.2. Buenas prácticas para securizar la infraestructura como código

4.9.3. Tipos de infraestructura como código

4.9.4. Herramientas para IaC

4.9.5. Ansible

4.9.6. Puppet

4.9.7. Chef

4.9.8. Terraform

CAPÍTULO 5

Generadores de microservicios

5.1. Introducción

5.2. Yeoman

5.3. Jhipster

5.3.1. Componentes principales de Jhipster

5.3.2. Jhipster online

5.4. Atomist

5.5. Spring Initializer

CAPÍTULO 6

Microservicios en Java

6.1. Introducción

6.2. Spring Boot

6.2.1. Creación de proyectos con Spring Boot Suite

6.2.2. Spring Boot Actuators

6.2.3. Spring Security

6.3. Micronaut

6.3.1. Creación de microservicios con Micronaut

6.3.2. Inyección de dependencias e inversión de control

6.3.3. Descubrimiento de servicios

6.3.4. Ejemplo de aplicación con Micronaut

6.4. Quarkus

6.4.1. Creación de recursos y endpoints en Quarkus

6.4.2. Inyección de dependencias en Quarkus

6.4.3. Creando nuestro proyecto base en Quarkus

6.4.4. Desplegando una aplicación Quarkus en Kubernetes

6.5. GraalVM

6.5.1. Imágenes nativas

6.5.2. GraalVM vs Micronaut

6.6. Helidon

CAPÍTULO 7

Programación reactiva

7.1. Introducción

7.2. Manifiesto reactivo

7.3. Patrón Observer

7.4. Reactive eXtensions (RX)

7.5. Frameworks de programación reactiva

7.5.1. Ecosistema Java / JVM

7.5.2. RxJava

7.5.3. Eclipse Vert.x

CAPÍTULO 8

Tecnologías basadas en contenedores y orquestadores

8.1. Introducción

8.2. Introducción a los contenedores

8.2.1. Casos de uso y ventajas de los contenedores

8.2.2. Contenedores vs máquinas virtuales

8.3. Docker

8.3.1. Gestión de secretos en Docker

8.3.2. Podman

8.4. Orquestadores

8.5. Kubernetes

8.5.1. Arquitectura de Kubernetes

8.5.2. Componentes de Kubernetes

8.5.3. Trabajar con Kubernetes

8.5.4. Micro8ks

8.5.5. Otras soluciones para trabajar con Kubernetes en local

8.5.6. Patrones de diseño en Kubernetes

8.6. Plataformas de contenedores

8.6.1. Portainer

8.6.2. OpenShift

8.6.3. Rancher

8.7. Comunicaciones y enrutado con Traefik

8.7.1. Despliegue de Traefik

8.7.2. Traefik middlewares

CAPÍTULO 9

Service mesh

9.1 Introducción

9.2. Definición de service mesh

9.3. Arquitectura de un service mesh

9.3.1. Data plane

9.3.2. Control plane

9.3.3. Casos de uso de service mesh

9.3.4. Implementaciones de un service mesh

9.4. Istio

9.4.1. Ventajas de Istio

9.4.2. Arquitectura de Istio

9.4.3. Gestión del tráfico en Istio

9.4.4. Seguridad en Istio

9.5. Linkerd

9.5.1. Funcionamiento de Linkerd

9.5.2. Casos de uso de Linkerd

9.5.3. Linkerd vs Istio

CAPÍTULO 10

Arquitecturas serverless

10.1. Introducción

10.2. Ventajas de las arquitecturas serverless

10.3. Manifiesto Twelve-Factor App

10.4. Estrategias de despliegue en aplicaciones serverless

10.5. AWS Lambda

10.5.1. AWS API Gateway

10.5.2. Funciones lambda

10.5.3. Casos de uso en AWS Lambda

10.6. Serverless DevOps

10.6.1. Herramientas y plataformas serverless DevOps

CAPÍTULO 11

Arquitecturas orientadas a eventos

11.1. Introducción

11.2. Introducción a los brokers de mensajería

11.2.1. Sistema de mensajería punto a punto

11.2.2. Sistema de mensajería de publicación y suscripción

11.3. Protocolos de mensajería

11.3.1. Advanced Message Queuing Protocol (AMQP)

11.3.2. Message Queue Telemetry Transport (MQTT)

11.4. Apache Kafka

11.4.1. Componentes de Apache Kafka

11.4.2. Plataforma de Apache Kafka

11.4.3. Requisitos para utilizar Apache Kafka

11.4.4. Iniciando Apache Kafka con Docker

11.4.5. Implementar productor y consumidor en Python

11.4.6. Herramientas para monitorizar Apache Kafka

11.5. Apache Pulsar

11.5.1. Apache Pulsar con Python

11.5.2. Apache Pulsar vs Apache Kafka

11.6. RabbitMQ

11.6.1. Componentes de RabbitMQ

11.6.2. Arquitectura de RabbitMQ

11.6.3. Ventajas de RabbitMQ

CAPÍTULO 12

Arquitecturas big data

12.1. Introducción

12.2. Apache Spark

12.2.1. Ecosistema de Apache Spark

12.2.2. Ventajas de Apache Spark

12.2.3. Arquitectura de Apache Spark

12.3. Procesamiento de datos en tiempo real

12.4. Apache Flink

12.4.1. Arquitectura de Apache Flink

12.4.2. Control de eventos en Apache Flink

12.4.3. Tipos de ventanas de procesamiento en Apache Flink

CAPÍTULO 13

Observabilidad y monitorización de microservicios

13.1. Introducción

13.2. Observabilidad vs monitorización

13.3. Ventajas de la observabilidad

13.4. Métricas de rendimiento en aplicaciones

13.5. Herramientas DevOps para observabilidad

13.5.1. OpenTelemetry

13.6. Herramientas de monitorización

13.6.1. Configuración de métricas con Prometheus

13.6.2. Visualización de métricas con Grafana

Glosario

Guide

Cubierta

Título

Start

Introducción

El panorama del desarrollo de software ha experimentado una transformación radical en las últimas décadas. La creciente demanda de aplicaciones más rápidas, escalables y resilientes ha impulsado la adopción de nuevas metodologías y arquitecturas. En este contexto, DevOps y la arquitectura de microservicios han emergido como pilares fundamentales para construir y operar sistemas de software modernos y complejos.

Más que una simple herramienta o tecnología, DevOps representa una filosofía cultural y un conjunto de prácticas que buscan integrar los equipos de desarrollo y operaciones, fomentando la colaboración, la automatización y la mejora continua en todo el ciclo de vida del software. Por otro lado, la arquitectura de microservicios propone una alternativa al enfoque monolítico tradicional, descomponiendo las aplicaciones en pequeños servicios independientes que se comunican a través de la red.

Este libro se presenta como una guía integral para comprender los conceptos esenciales, los patrones de diseño, las estrategias de implementación y las tecnologías clave que sustentan el desarrollo de aplicaciones modernas utilizando estos dos paradigmas. A lo largo de sus páginas explicaremos cómo DevOps y los microservicios se complementan para ofrecer soluciones robustas, escalables y adaptables a las necesidades cambiantes del negocio.

Este libro está dirigido a desarrolladores de software, arquitectos de sistemas, profesionales de operaciones, líderes de equipo y cualquier persona interesada en comprender y aplicar los principios y las prácticas de DevOps y las arquitecturas de microservicios para construir sistemas de software de próxima generación.

Entre los principales objetivos de aprendizaje que se persiguen con esta obra podemos destacar:

● Comprender los fundamentos y principios clave de la filosofía DevOps, incluyendo la colaboración, la automatización, la mejora continua y la cultura.

● Definir y diferenciar la arquitectura de microservicios de otros estilos arquitectónicos tradicionales, comprendiendo sus ventajas y desafíos.

● Identificar y aplicar los patrones de diseño de microservicios más comunes para construir sistemas resilientes, escalables y mantenibles.

● Conocer las estrategias de descomposición de un monolito en microservicios y los criterios para definir los límites de los servicios.

● Comprender las consideraciones clave para la comunicación entre microservicios, incluyendo patrones síncronos y asíncronos.

● Explorar las estrategias de gestión de datos en arquitecturas de microservicios, abordando la consistencia y la independencia de las bases de datos.

● Conocer las principales tecnologías y herramientas utilizadas en el desarrollo y despliegue de microservicios dentro de un entorno DevOps, como contenedores (Docker, Kubernetes), orquestación, observabilidad y CI/CD.

● Entender las prácticas de automatización esenciales en un entorno DevOps, incluyendo la infraestructura como código, la gestión de la configuración y las pruebas automatizadas.

● Implementar estrategias de monitorización y observabilidad para garantizar la salud, el rendimiento y la disponibilidad de las aplicaciones basadas en microservicios.

● Comprender los aspectos de seguridad específicos de las arquitecturas de microservicios y cómo abordarlos en un contexto DevOps.

● Aplicar los principios de mejora continua para optimizar los procesos de desarrollo y operación de sistemas basados en microservicios.

CAPÍTULO 1

INTRODUCCIÓN A DEVOPS

1.1. Ciclo de vida DevOps

En los últimos años, la metodología DevOps se ha afianzado como la respuesta a la necesidad de estandarizar un proceso mediante el cual un desarrollo software (nueva funcionalidad, mejora o corrección) pasa de la implementación a la explotación. Se trata de un enfoque ágil cuyo objetivo principal es reducir los tiempos necesarios dentro del ciclo de vida software (migración entre versiones, ejecución de pruebas, detección de bugs, etc.).

Para alcanzar ese objetivo, la metodología se basa en la idea de reducir la distancia entre los técnicos de desarrollo (Dev) y los de sistemas (Ops), permitiendo a ambos equipos trabajar de forma más cercana, lo que aportará mayor agilidad y productividad al entorno de trabajo.

El objetivo de este enfoque es agilizar y facilitar el proceso de desarrollo y entrega de software, uniendo para ello equipos que tradicionalmente no estaban tan comunicados, como por ejemplo los equipos de desarrollo y los de mantenimiento de sistemas. Con la colaboración de estos grupos, se busca optimizar el trabajo de los desarrolladores, a la vez que se asegura la funcionalidad de las aplicaciones desarrolladas mediante medidas de monitorización aplicadas por el equipo de operaciones.

El proceso de DevOps se representa como un bucle infinito. Comprende las etapas de planificación, codificación, compilación, pruebas, despliegue, implementación, operación, monitoreo y, a través de la retroalimentación, planificación, lo que restablece el bucle.

Figura 1.1 Ciclo de vida en proyectos que siguen una metodología DevOps

El proceso que se sigue en la aplicación de DevOps suele estar formado por ocho fases, que se repiten durante el ciclo de vida de las aplicaciones desarrolladas. En cada fase se llevan a cabo diferentes tareas, realizadas por el equipo de desarrollo y el de operaciones:

●Fase planificación: el equipo de desarrollo habla con el cliente sobre los detalles de su aplicación y se planean las funcionalidades que se van a implementar, corregir o mejorar según los resultados recibidos del equipo de operaciones.

●Fases desarrollo, implementación y testeo: en estas fases se desarrollan, implementan y testean las funcionalidades que se van a añadir a la aplicación.

●Fases de despliegue y puesta en producción: el equipo de operaciones recibe las nuevas implementaciones y despliega y publica el código generado, de tal manera que no entre en conflicto con las funcionalidades ya implementadas.

●Fases de operación y monitorización: se definen medidas de control y monitorización para asegurar el funcionamiento de la aplicación una vez puesta en producción, y se van comunicando los resultados de las mediciones al equipo de desarrollo. Desde aquí, con las mediciones obtenidas, el proceso volvería otra vez a la fase de planificación, lo que iniciará una nueva etapa dentro del ciclo de vida de la aplicación.

Las ventajas de DevOps son claras: los equipos que adoptan esta cultura, las prácticas y las herramientas de DevOps mejoran el rendimiento y crean productos de mayor calidad, pero empleando menos tiempo, lo que se traduce en una satisfacción mayor en el cliente final. Esta mejora en la colaboración y la productividad es también vital para alcanzar objetivos de negocio.

El pilar fundamental sobre el que se basa el sistema de trabajo es la automatización de todos los procesos que intervienen en el ciclo de vida de una aplicación: integración, pruebas, despliegue, monitorización y operación. En la siguiente tabla se resumen las implicaciones que tienen los beneficios de la metodología DevOps:

Ventajas

Impacto en el negocio

Reducción de los tiempos de despliegue de nuevas versiones

Reducción del “time to market”

Mayor número de despliegues

Los clientes perciben más agilidad y calidad del producto

Testing automatizado

Los errores se detectan y resuelven antes de que lleguen al cliente

FeedBack continuo

Se consigue mayor calidad en el producto final

Procesos automáticos

Los procesos de negocio no se ven afectados por errores humanos

Escalabilidad

Capacidad de adaptación a las demandas que puedan surgir de los usuarios o clientes

1.2. Arquitecturas DevOps

Una arquitectura DevOps engloba un conjunto de principios, patrones y mejores prácticas arquitectónicas que, cuando se aplican en conjunto, facilitan y potencian la implementación de la filosofía y las prácticas de DevOps en una organización. Una arquitectura DevOps es aquella que está diseñada y construida para soportar la velocidad, la colaboración, la automatización, la monitorización continua y la mejora iterativa que son fundamentales para DevOps. Una arquitectura DevOps se construye sobre un conjunto de principios arquitectónicos que habilitan las prácticas de DevOps:

●Microservicios: descomponer las aplicaciones monolíticas en servicios pequeños, independientes y autónomos que se pueden desarrollar, desplegar, escalar y mantener de forma independiente. Los microservicios facilitan la agilidad, la resiliencia y la escalabilidad, y son altamente compatibles con la automatización de DevOps.

●Infraestructura como código: tratar la infraestructura (servidores, redes, almacenamiento, etc.) como código, permitiendo su gestión automatizada, versionada y declarativa. La IaC es esencial para la automatización del aprovisionamiento, la configuración y el despliegue en DevOps.

●Contenedores: empaquetar aplicaciones y sus dependencias en contenedores (Docker, etc.) que proporcionan aislamiento, portabilidad y consistencia entre diferentes entornos (desarrollo, pruebas, producción). Los contenedores simplifican el despliegue, la escalabilidad y la gestión de aplicaciones en DevOps.

●Orquestación de contenedores: utilizar plataformas de orquestación de contenedores (Kubernetes, Docker Swarm) para automatizar el despliegue, la gestión, la escalabilidad y la autorrecuperación de aplicaciones contenerizadas. La orquestación de contenedores es un componente clave de las arquitecturas DevOps modernas.

●Automatización: la automatización debe ser un principio fundamental en todos los aspectos de la arquitectura DevOps. Se deben automatizar tareas repetitivas, procesos de build, pruebas, despliegues, configuración, monitorización y respuesta a incidentes siempre que sea posible. La automatización aumenta la velocidad, la eficiencia y la fiabilidad.

●Observabilidad: diseñar arquitecturas fácilmente observables, implementando sistemas de monitorización centralizados para recopilar métricas, logs y trazas. La observabilidad permite entender el estado interno de los sistemas basándose en datos externos, lo cual facilita la detección temprana de problemas, el diagnóstico rápido y la optimización del rendimiento.

●Seguridad integrada: incorporar la seguridad en la arquitectura desde el inicio (Shift-Left Security). Integrar prácticas de seguridad en todas las fases del ciclo de vida de DevOps, automatizando pruebas de seguridad y controles de seguridad operativos.

●Escalabilidad y resiliencia: diseñar arquitecturas que sean fácilmente escalables para manejar picos de demanda y crecimiento futuro, y que sean resilientes ante fallos, con redundancia, autorrecuperación y planes de contingencia.

●API (Application Programming Interface) y desacoplamiento: utilizar unas API bien definidas para la comunicación entre componentes y servicios, promoviendo el desacoplamiento y la independencia. Las API facilitan la integración, la reutilización y la evolución independiente de los componentes.

Dentro de las arquitecturas DevOps, se utilizan patrones comunes que potencian la agilidad y la eficiencia. La arquitectura de microservicios, donde las aplicaciones se dividen en servicios pequeños e independientes, facilita el despliegue y la escalabilidad individual de los componentes. Las arquitecturas basadas en contenedores, con Kubernetes como orquestador principal, ofrecen portabilidad y gestión simplificada de aplicaciones complejas. También son relevantes las arquitecturas serverless, que minimizan la gestión de la infraestructura, y las arquitecturas cloud (híbridas o multinube), que aprovechan la elasticidad y los servicios gestionados de la nube para construir sistemas más robustos y adaptables.

El objetivo de estas herramientas es tratar de optimizar, acortar y automatizar aún más las diversas etapas del flujo de trabajo de creación de software. Muchas de estas herramientas también promueven los postulados principales de DevOps, como son la automatización, la colaboración y la integración entre los equipos de desarrollo y operaciones. A continuación, se ofrece un ejemplo de herramientas que se emplean en las diversas etapas del ciclo de DevOps.

●Planificación: en esta fase se definen los requisitos y valores empresariales. Algunas herramientas de muestra son Jira o Git, con las cuales se puede hacer un seguimiento de los problemas conocidos y llevar a cabo la gestión de los proyectos.

●Codificación y control de versiones: esta fase implica el diseño del software y la creación del código. Algunas herramientas en este punto son GitHub, GitLab, Bitbucket o Stash.

●Integración continua: en esta fase se gestionan las versiones y las compilaciones del software utilizan herramientas automatizadas que ayudan a compilar y crear paquetes de código para publicarlos después en producción. Se utilizan repositorios de código fuente o repositorios de paquetes que también empaquetan la infraestructura que se necesita para el lanzamiento del producto. Algunas herramientas en este punto son Docker, Ansible, Puppet, Chef, Gradle, Maven o JFrog Artifactory.

●Pruebas automatizadas: esta fase incluye la realización de pruebas automatizadas para garantizar la calidad del desarrollo. Algunas herramientas en este punto son JUnit, Codeception, Selenium, Vagrant, TestNG o BlazeMeter.

●Despliegue continuo: en esta fase se emplean herramientas que ayudan a gestionar, coordinar, programar y automatizar las tareas de producción de las versiones de productos. Algunas herramientas en este punto son Puppet, Chef, Ansible, Jenkins, Kubernetes, OpenShift, OpenStack, Docker o Jira.

●Operaciones: en esta fase se gestiona el software durante su producción. Algunas herramientas en este punto son Ansible, Puppet, PowerShell, Chef, Salt u Otter.

●Monitorización: en esta fase se identifica y se recopila información sobre problemas que surgen en una versión de software específica que se encuentra en producción. Algunas herramientas en este punto son New Relic, Datadog, Grafana, Wireshark, Splunk, Nagios o Slack.

1.2.1. Principios de arquitectura de la infraestructura

La arquitectura de la infraestructura subyacente es importante para habilitar las prácticas de DevOps. Los principios clave en la arquitectura de infraestructura DevOps incluyen:

●Infraestructura como código: la infraestructura debe ser gestionada como código (IaC) para permitir la automatización del aprovisionamiento, la configuración y la gestión. Se utilizan herramientas como Terraform, Ansible, Chef, Puppet.

●Infraestructura dinámica y elástica: la infraestructura debe poder escalar automáticamente según la demanda, aprovisionando recursos de forma dinámica. Se aprovechan las capacidades de la nube pública y las plataformas de orquestación de contenedores.

●Infraestructura inmutable: en lugar de modificar servidores existentes, se reemplazan estos por nuevas instancias cada vez que se requiere un cambio. La infraestructura inmutable reduce los cambios de configuración, mejora la consistencia y facilita los rollbacks.

●Infraestructura de autoservicio: proporcionar a los equipos de desarrollo la capacidad de aprovisionar y gestionar la infraestructura que necesitan bajo demanda, utilizando portales de autoservicio y API.

●Redes definidas por software: utilizan SDN para automatizar la configuración y la gestión de la red, lo que permite una infraestructura de red más ágil y programable, y facilita la microsegmentación y la seguridad de la red.

1.3. SRE (Site Reliability Engineering)

En el mundo tecnológico actual, la confiabilidad de las aplicaciones es esencial para el éxito empresarial. Ante la creciente complejidad de las infraestructuras tecnológicas y la demanda de una experiencia de usuario fluida, surge la figura del ingeniero de fiabilidad del sitio (SRE), que las organizaciones utilizan para garantizar que las aplicaciones mantengan un nivel mínimo de fiabilidad en medio de las frecuentes actualizaciones llevadas a cabo por los equipos de desarrollo.

SRE es una disciplina que incorpora diversos aspectos del desarrollo de software y lo aplica a problemas y tareas en operaciones de TI específicamente. El objetivo principal de SRE es desarrollar una aplicación o sistema de software altamente confiable y escalable. Entre las principales características de SRE podemos destacar:

●Ingeniería de software aplicada a la infraestructura: trata la infraestructura como código, utilizando principios de ingeniería de software como la automatización, la monitorización, las pruebas y la revisión por pares para gestionar y mejorar los sistemas.

●Colaboración estrecha con los equipos de desarrollo: fomenta una estrecha colaboración entre los equipos de desarrollo y operaciones, rompiendo los silos tradicionales y compartiendo responsabilidades.

●Enfoque en la automatización: la automatización es fundamental para SRE. Se automatizan tareas repetitivas como el despliegue, la configuración, la monitorización y la resolución de problemas.

●Monitorización y observabilidad: se basa en una sólida estrategia de monitorización para recopilar datos sobre el rendimiento del sistema, identificar problemas potenciales y responder rápidamente a los incidentes que surjan.

●Cultura de la mejora continua: fomenta una cultura de aprendizaje continuo a través de la realización de post mortems, el análisis de incidentes y la búsqueda de mejoras continuas en los procesos y sistemas.

●Aceptación de errores: reconoce que los fallos son inevitables y se enfoca en diseñar sistemas resilientes que puedan recuperarse rápidamente de los errores.

●Utilización de métricas: utiliza métricas clave para medir el rendimiento del sistema, como el tiempo de actividad, la latencia, la tasa de errores y el tiempo de resolución de incidentes.

1.3.1. SRE (Site Reliability Engineering) vs DevOps

SRE y DevOps son enfoques clave en el desarrollo y la operación de sistemas de software, pero presentan diferencias notables en sus objetivos y en cómo abordan los desafíos de lograr una entrega de software eficaz. Algunas diferencias entre ambos perfiles son:

El objetivo principal de un perfil SRE es garantizar que los sistemas sean confiables, escalables y resistentes, manteniendo altos niveles de disponibilidad y rendimiento. DevOps busca acortar los ciclos de desarrollo y entrega, fomentando la entrega continua y mejorando la colaboración y la comunicación entre los equipos.

Los perfiles SRE aplican principios de ingeniería de software para mantener la estabilidad y el rendimiento del sistema en entornos operativos. En cambio, DevOps abarca la colaboración entre equipos de desarrollo y operaciones para agilizar el desarrollo, las pruebas y la entrega de software.

SRE utiliza prácticas como el monitoreo proactivo, la automatización de operaciones y la gestión de incidentes para garantizar la fiabilidad del sistema en producción, mientras que DevOps se besa en la integración continua, la entrega continua y la automatización de procesos de desarrollo y operaciones para agilizar la entrega de software.

Los ingenieros de SRE son expertos en confiabilidad y operaciones. Se enfocan en el monitoreo, la gestión de la capacidad, la escalabilidad y la resolución de problemas en producción. Por otro lado, DevOps promueve la colaboración entre desarrolladores y operaciones, compartiendo responsabilidades para todo el ciclo de vida del software.

En la siguiente figura podemos ver que DevOps representa una cultura de colaboración entre desarrollo y operaciones, enfocada en acelerar la entrega de software. SRE, por su parte, es una disciplina de ingeniería que se basa en los principios de DevOps y se centra en la fiabilidad y escalabilidad de los sistemas en producción. Mientras que DevOps busca acortar los ciclos de desarrollo, SRE se asegura de que los sistemas puedan soportar cargas de trabajo crecientes y recuperarse de fallos de manera rápida y eficiente.

Figura 1.2 SRE vs DevOps

A continuación, mostramos una tabla comparativa entre SRE (ingeniería de fiabilidad del sitio) y DevOps, destacando las principales diferencias y similitudes:

Característica

DevOps

SRE

Objetivo principal

Acelerar la entrega de software

Asegurar la fiabilidad y escalabilidad de los sistemas en producción.

Enfoque

Colaboración entre desarrollo y operaciones para acelerar la entrega de software.

Garantizar la fiabilidad, escalabilidad y rendimiento de los sistemas en producción.

Responsabilidades

Abarca todo el ciclo de vida del software, desde el desarrollo hasta la implementación.

Se centra principalmente en la operación y mantenimiento de los sistemas en producción.

Cultura

Fomenta una cultura de colaboración, automatización y mejora continua.

Amplía la cultura DevOps con un enfoque en la ingeniería de fiabilidad y la resolución de problemas.

Métricas

Tiempo de actividad, frecuencia de despliegues, tiempo medio para la recuperación (MTTR).

Métricas de rendimiento, latencia, errores por segundo, satisfacción del usuario.

Herramientas

Herramientas de automatización, contenedores, orquestación, monitoreo, etc.

Herramientas de monitoreo, alerta, automatización, análisis de incidentes, etc.

Habilidades

Desarrollo de software, operaciones, automatización, pruebas.

Desarrollo de software, sistemas operativos, redes, análisis de datos, resolución de problemas.

1.4. Metodologías de desarrollo

La forma en que diseñamos y desarrollamos software ha evolucionado significativamente en las últimas décadas. Dos enfoques principales han surgido en el desarrollo de las API: Code First y API First. Cada uno tiene sus propias fortalezas y debilidades. La elección entre uno u otro dependerá de los objetivos específicos del proyecto.

El enfoque más tradicional o Code First consiste en crear una aplicación con todas las funcionalidades requeridas por la lógica de negocio, elaborar la interfaz de usuario, back-end, etc., y luego, casi como un side project, montar una API para interactuar la lógica de negocio que tenemos implementada.

Los enfoques más actuales emergen hoy en busca de la planificación y especificación de contratos de diseño para las API que satisfagan la lógica del negocio de manera sostenible y escalable. Recuerda que la API no es más que el lenguaje común que utilizarán para comunicarse todas las partes de un proyecto y que, por tanto, debe ser consensuado, especificado, validado y de dominio colectivo.

El enfoque API First prioriza la planificación de la API a través de la especificación del contrato de diseño, utilizando especificaciones como OpenAPIhttps://www.openapis.org. Iniciar un proyecto con un contrato de API garantiza la coherencia, la reutilización y la amplia interoperabilidad de la API resultante, siendo posible utilizar herramientas gratis para generar documentación y ejemplos de prueba a partir de las especificaciones establecidas en el contrato de la API. A continuación, se muestra una tabla comparativa entre ambas metodologías.

Característica

Code First

API First

Foco inicial

Código

Diseño de la API

Flexibilidad

Alta

Media

Reutilización

Baja

Alta

Documentación

Tiende a ser posterior

Generada automáticamente

Tiempo de desarrollo inicial

Más rápido

Más lento

Escalabilidad

Menor

Mayor

La elección entre ambos enfoques depende de una variedad de factores, incluyendo el tamaño del proyecto, la complejidad de la API, los requisitos de escalabilidad y la importancia de la reutilización. En general, el enfoque API First es cada vez más popular, debido a sus beneficios a largo plazo, pero el enfoque Code First puede ser adecuado para ciertos tipos de proyectos.

1.4.1. Code First

El enfoque Code First es una metodología de desarrollo de software en la que se prioriza la escritura del código de la aplicación antes de definir formalmente las interfaces o contratos. En otras palabras, se construye la lógica de la aplicación y luego se exponen sus funcionalidades a través de API o interfaces de usuario. Las principales características del enfoque Code First son:

●Flexibilidad: permite un desarrollo ágil y adaptable, ya que el diseño de la API puede evolucionar a medida que se desarrolla la aplicación.

●Velocidad: puede ser más rápido de implementar, especialmente para proyectos pequeños o prototipos.

●Énfasis en la funcionalidad: prioriza la implementación de las características de la aplicación.

●Menor planificación inicial: requiere menos planificación formal en comparación con otros enfoques.

El enfoque Code First, aunque ofrece una gran flexibilidad, se adapta mejor a ciertos tipos de proyectos y escenarios. A continuación, analizamos algunos de los casos de uso más comunes:

●Proyectos pequeños y rápidos: cuando se necesita una solución rápida y no se requiere una API estable y escalable.

●Prototipos: para construir prototipos rápidamente y obtener feedback temprano de los usuarios.

●Desarrollo interno: cuando la aplicación está destinada a ser utilizada internamente y no requiere una API públicamente expuesta.

●Proyectos en los que la funcionalidad es más importante que la reutilización: si el objetivo principal es construir una aplicación específica y no se prevé reutilizar el código en otros proyectos.

1.4.2. API First

El desarrollo API First es una metodología de desarrollo de software que se centra en la creación de una API como el primer paso en el proceso de desarrollo de una aplicación. En lugar de desarrollar primero la interfaz de usuario y luego crear una API para conectarla con el backend, el enfoque API First implica diseñar y desarrollar primero la API, y luego construir la interfaz de usuario en función de esa API.

Al adoptar el enfoque API First, se mejora la experiencia del usuario, se facilita la integración con otras aplicaciones, se permite una mayor escalabilidad y se promueve la reutilización de código. Las principales ventajas de usar esta metodología son las siguientes:

●Mejora la experiencia del usuario: al adoptar el enfoque API First, se pone el foco en el diseño de una API bien estructurada y fácil de usar. Esto permite que la interfaz de usuario se construya en torno a la funcionalidad de la API, lo que resulta en una experiencia de usuario más coherente. Además, al separar la lógica de negocio de la interfaz de usuario, se facilita la actualización y mejora de la aplicación sin afectar la experiencia del usuario.

●Facilita la integración con otras aplicaciones: al desarrollar una API como punto de entrada a su aplicación, se está facilitando la integración con otras aplicaciones y servicios. Esto es especialmente útil hoy con la integración de sistemas, donde es común encontrar que las aplicaciones se conecten entre sí. Al proporcionar una API bien documentada y fácil de usar, estamos abriendo las puertas a la integración con otras aplicaciones y permitiendo a la aplicación formar parte de un ecosistema más amplio.

●Permite una mayor escalabilidad: el enfoque API First permite una mayor escalabilidad de su aplicación. Al desarrollar primero la API, podrías realizar el diseño de manera que sea fácil de escalar y manejar grandes volúmenes de peticiones. Además, al separar la lógica de negocio de la interfaz de usuario, podríamos escalar cada componente por separado según sea necesario. Esto ofrece flexibilidad para añadir más recursos a la API o a la interfaz de usuario según las demandas del negocio y el número de usuarios que estén haciendo uso de la aplicación.

●Promueve la reutilización de código: al desarrollar primero la API, se fomenta la reutilización de código. Una API bien diseñada y modular puede ser utilizada por diferentes aplicaciones y servicios, lo que reduce la necesidad de escribir código duplicado. Esto no solo ahorra tiempo y esfuerzo en el desarrollo, sino que también facilita el mantenimiento y la actualización de la aplicación.

●Mejora la seguridad de las API: al definir el contrato primero, permite validar la seguridad basada en la definición y encontrar bugs de seguridad antes de haber comenzado con la fase de implementación.

●Arquitectura de la API mejorada: en el enfoque Code First, la API se desarrolla método a método, por lo que un desarrollador puede perder fácilmente la pista de la arquitectura general de la API. Sin embargo, con el enfoque API First el desarrollador se ve obligado a interactuar con una API desde la posición de usuario de esta, lo que con frecuencia puede ayudarle a diseñar una arquitectura de API más limpia.

El enfoque API First nos invita a comenzar inicialmente por el diseño y desarrollo de la API, lo que da como resultado que la misma contemple un contexto más amplio. Al ser el contexto inicial más amplio, la extensión o adición de nuevas funcionalidades a nuestra API tiende a ser más orgánico y ordenado. Además, esta metodología posibilita trabajar en varias partes simultáneas de la aplicación, testear, corregir e iterar nuevamente, teniendo en mente no sólo la lógica de negocio de la aplicación, sino también cómo se utilizará cada parte de la misma.

El enfoque API First es ideal para proyectos grandes y complejos, en los cuales la reutilización, la escalabilidad y la colaboración son fundamentales. A continuación, analizamos algunos de los casos de uso más comunes:

●Proyectos grandes y complejos: cuando se requiere una API estable y escalable que pueda ser utilizada por múltiples aplicaciones.

●Proyectos donde la reutilización es importante: cuando se espera que la API sea reutilizada en otros proyectos.

●Proyectos que requieren una colaboración estrecha entre equipos: cuando diferentes equipos trabajan en diferentes partes de la aplicación.

Una variante de esta metodología es la de API-Design First, que resulta un enfoque más ambicioso en cuanto a la planificación: antes de comenzar a escribir cualquier línea de código, o incluso de especificación del contrato, las partes involucradas técnicas y no técnicas podrán discutir las funcionalidades de la API, la estructura del contrato, realizar simulacros de funcionamiento y trazar las posibles pruebas de validación, todo ello en un ciclo corto de retroalimentación. En una fase posterior podrán ser definidas en código las especificaciones de la API y, a partir de ahí, los desarrolladores podrán pasar a implementar en paralelo con apoyo de la documentación y entornos de prueba generados hasta ese momento.

1.5. Otras metodologías DevOps

En esta sección se presentan algunas de las metodologías DevOps que han surgido en los últimos años para diferenciar diferentes formas de trabajo en los proyectos.

1.5.1. DevSecOps

Desde hace algunos años, la seguridad viene ganando cada vez más importancia en el ámbito del desarrollo de software, en especial cuando se trata de procesos cortos de desarrollo, que tienen que producirse cada vez con más rapidez entre las versiones. El cumplimiento de los estándares de seguridad en estos casos es todo un desafío. En este contexto, si se deja la seguridad para el final, tras la fase de desarrollo en sí, puede que no se logre alcanzar tales estándares. En muchos casos, las empresas tienen que elegir entre un alto nivel de seguridad, que requiere una gran inversión de tiempo, o ciclos cortos de lanzamiento que renuncian a la seguridad.

DevSecOps es una práctica que integra la seguridad (Sec) en todo el ciclo de vida del desarrollo y operaciones (DevOps). Esta metodología busca automatizar la implementación de controles de seguridad y garantizar que la seguridad sea una responsabilidad compartida entre los equipos de desarrollo, seguridad y operaciones.

DevSecOps permite utilizar de manera óptima la agilidad y la rapidez de reacción que ofrece el enfoque DevOps. En este sistema, los mecanismos de seguridad están integrados en el proceso ya desde el inicio del desarrollo. Esta es una de las claras diferencias entre el paradigma DevSecOps y los enfoques convencionales, en los que los equipos de seguridad suelen aplicar las medidas correspondientes una vez se ha desplegado la solución en producción.

Figura 1.3 Ciclo de vida en proyectos que siguen una metodología DevSecOps

Una de las principales ventajas que aporta este modelo en una organización es servir de nexo de unión para dos departamentos entre los que frecuentemente existen roces, como son desarrollo y operaciones (sistemas). La necesidad de coordinar ambos departamentos a la hora de detectar, analizar y corregir las distintas vulnerabilidades e introducir esas modificaciones en el ciclo de entrega continua, redunda en una mejora del trabajo en equipo, la comprensión y el entendimiento entre ellos. El éxito de la implantación de un modelo DevSecOps se encuentra en tres pilares fundamentales:

●Seguridad desde el diseño: introducción de la seguridad desde el mismo momento del diseño y en todas las fases del ciclo de vida del software.

●Fomento de una cultura de desarrollo seguro entre los desarrolladores: mediante formación adecuada e información constante sobre guías y recomendaciones de algunas organizaciones como OWASP https://owasp.org, IEE https://www.ieee.org, SANS https://www.sans.org.

●Pruebas de seguridad y herramientas de análisis de código: la implementación de pruebas de seguridad estáticas (SAST) y dinámicas (DAST) permiten identificar vulnerabilidades en el código. Este enfoque ayuda a detectar problemas de seguridad durante el desarrollo y la ejecución de las aplicaciones, lo que reduce el riesgo de vulnerabilidades en entornos de producción.

○SAST (pruebas de seguridad estáticas): se analizan los códigos fuente en busca de vulnerabilidades sin ejecutar el programa. Esto permite identificar problemas en las primeras etapas del desarrollo.

○DAST (pruebas de seguridad dinámicas): se realizan pruebas en aplicaciones en ejecución para identificar vulnerabilidades que solo pueden ser detectadas durante el tiempo de ejecución.

1.5.2. DataOps

DataOps es la convergencia de procesos, personas y tecnología para mejorar la colaboración y la automatización en la gestión de datos. Su objetivo principal es acelerar la entrega de análisis de datos de alta calidad, al tiempo que garantiza la calidad y la seguridad de los datos. Sus características principales son:

●Colaboración continua: DataOps fomenta la colaboración continua entre los equipos de desarrollo, operaciones y análisis de datos. Rompe las barreras tradicionales y crea un entorno donde la comunicación es transparente, lo que facilita la integración efectiva de la perspectiva analítica y operativa desde el inicio del ciclo de vida del proyecto.

●Automatización de procesos: la automatización es el corazón de DataOps. Desde el ingreso de datos hasta la entrega de resultados, la automatización agiliza los procesos, reduce errores manuales y acelera el tiempo de entrega. La automatización no solo se aplica a las tareas rutinarias, sino también a las pruebas de calidad, la monitorización y la implementación, asegurando la coherencia y confiabilidad de los datos.

●Escalabilidad: DataOps está diseñado para escalar de manera eficiente, permitiendo a las organizaciones manejar grandes volúmenes de datos de manera efectiva. La arquitectura escalable facilita la incorporación de nuevas fuentes de datos y la expansión de la infraestructura según las necesidades del negocio, sin comprometer la estabilidad del sistema.

●Agilidad: la agilidad es un pilar fundamental de DataOps, al adoptar prácticas ágiles que permiten a los equipos adaptarse rápidamente a los cambios en los requisitos y responder de manera eficiente a las demandas del mercado.

●Calidad y seguridad de los datos: DataOps pone un énfasis especial en la calidad y seguridad de los datos. La implementación de prácticas de integración continua garantiza que los datos sean confiables y estén disponibles en todo momento. Las medidas de seguridad están integradas en cada fase del ciclo de vida, para proteger la integridad y confidencialidad de la información.

●Retroalimentación continua: DataOps fomenta un ciclo de retroalimentación constante. La monitorización proactiva, la recopilación de comentarios y la mejora permanente son elementos esenciales para garantizar que los procesos evolucionen y se puedan optimizar de forma continua. Esta mentalidad de aprendizaje constante fortalece la capacidad de adaptación de las organizaciones.

●Automatización de las pruebas: la reducción de la participación humana en las fases de pruebas, como las pruebas de no regresión, permite acelerar los despliegues en producción.

●Metadatos y gestión de versiones: el aumento de la frecuencia y el número de lanzamientos requiere la presencia de un sistema de control de versiones; además, cada versión de una solución intensiva en datos implica cambios que pueden expresarse mediante metadatos. Estos metadatos, puestos a disposición de todos los roles que participan en el pipeline de datos, garantizan una gestión eficaz y compartida de los cambios.

Figura 1.4 Ciclo de vida en proyectos que siguen una metodología DataOps

DataOps surge de la filosofía de DevOps, pero enfocándose en el análisis de datos con una búsqueda de la automatización, velocidad y precisión en el procesamiento de estos datos. Las ventajas que implican este tipo de operaciones son:

●Evitar la duplicación de datos: puesto que se busca la creación de productos de datos más accesibles, de calidad y con disponibilidad.

●Creación de una estrategia de datos: facilitando la colaboración de los equipos en todas las fases de desarrollo, para que los datos estén disponibles cuanto antes.

●Mejora de la analítica de datos: gracias al uso de algoritmos de aprendizaje automático. Pueden gestionar gran cantidad de datos.

●Mejora en la eficiencia operativa: se optimiza la eficiencia, la agilidad, la seguridad y el cambio de transformación del dato.

●Procesos avanzados: al adoptar DataOps, las empresas y organismos aceleran la transición a la nube y la ejecución de estrategias de transformación digital.

●Apoyo a tecnologías de automatización: se eliminan el tiempo necesario para la ejecución de tareas manuales.

A continuación, mostramos una tabla donde comparamos Devops y DataOps desde diferentes puntos de vista. Mientras que DevOps se centra en la eficiencia y la velocidad en el ciclo de vida del software, DataOps aplica principios similares al ciclo de vida de los datos, buscando mejorar la calidad, la velocidad y la confiabilidad en la entrega de datos para el análisis y la toma de decisiones. Ambas metodologías comparten la importancia de la automatización, la colaboración y la mejora continua.

Característica

DevOps

DataOps

Enfoque principal

Desarrollo y operaciones de software

Desarrollo y operaciones de datos

Objetivo principal

Automatizar y optimizar el ciclo de vida del desarrollo de software para una entrega más rápida y confiable.

Automatizar y optimizar el ciclo de vida de los datos para una entrega más rápida, confiable y de mayor calidad.

Alcance

Ciclo de vida del desarrollo de aplicaciones (codificación, pruebas, despliegue, infraestructura, operaciones).

Ciclo de vida de los datos (adquisición, preparación, integración, almacenamiento, análisis, visualización).

Equipos involucrados

Desarrolladores, equipos de operaciones de TI, equipos de seguridad (DevSecOps).

Científicos de datos, ingenieros de datos, analistas de datos, equipos de TI.

Procesos clave

Integración continua (CI), entrega continua (CD), infraestructura como código (IaC), monitoreo y logging.

Integración continua (CI), entrega continua (CD) para datos, infraestructura como código (IaC) para datos, monitoreo y logging de pipelines de datos, gobernanza de datos

Datos

Considerados principalmente como parte de la aplicación. La gestión de bases de datos es un componente, pero no el foco central.

El dato es el activo principal. Se enfoca en la calidad, la disponibilidad, la seguridad y la gobernanza de los datos.

Infraestructura

Principalmente infraestructura de aplicaciones (servidores, redes, contenedores).

Infraestructura de datos (almacenamiento, procesamiento, pipelines de datos, lagos de datos).

Herramientas

Git, Jenkins, Docker, Kubernetes, Ansible, Chef, Prometheus, Grafana.

Apache Kafka, Apache Spark, Airflow, dbt, Snowflake, AWS Glue, Google Cloud Dataflow.

Métricas

Frecuencia de despliegue, tiempo de entrega, tiempo de recuperación de incidentes, tasa de cambio de fallos.

Tiempo de ciclo de datos, calidad de los datos, disponibilidad de los datos, tiempo de detección de problemas de datos.

Filosofía

Cultura de colaboración, automatización, mejora continua, enfoque en la entrega de valor al cliente.

Cultura de colaboración (entre equipos de datos y TI), automatización de flujos de trabajo de datos, enfoque en la calidad y el valor del dato.

Casos de Uso

Desarrollo y despliegue de aplicaciones web y móviles, microservicios, gestión de infraestructura.

Pipelines de datos para análisis, machine learning, inteligencia de negocios, almacenamiento y gestión de grandes volúmenes de datos.

1.5.3. MLOps

En un mundo en el que los datos son tan importantes, los modelos MLops surgen con la intención de facilitar y agilizar los proyectos de machine learning e inteligencia artificial dentro de una empresa. Gracias a estos modelos entrenados, se ha conseguido una mayor optimización de procesos. Los tiempos han cambiado y el flujo de datos que necesita procesar una empresa a día de hoy requiere de herramientas que permiten hacerlo de forma automática.

MLOps https://ml-ops.org son las siglas de Machine Learning Operations, una extensión de la metodología DevOps que tiene como objetivo incluir los procesos de aprendizaje automático y ciencia de datos en la cadena de desarrollo y operaciones, de forma que el machine learning resulte más productivo y confiable. Lo que busca este sistema es poder desarrollar y entrenar modelos de machine learning con procesos más automatizados para que se integren en los equipos de data, a los desarrolladores y a los que se encargan de la seguridad y de la infraestructura.

El enfoque MLOps es la aplicación de las prácticas DevOps en el desarrollo y puesta en producción de los modelos de machine learning. Este nombre viene de la combinación de los términos machine learning y operations. La aplicación de las prácticas MLOps trata de agilizar el proceso de experimentación y desarrollo de modelos, facilitar y hacer más eficiente el proceso de desplegado y mantenimiento de los modelos ya puestos en producción, y asegurar la calidad de los resultados obtenidos mediante estos modelos.

Figura 1.5 Ciclo de vida en proyectos que siguen una metodología MLOps

Este nuevo ciclo de vida y las fases que lo componen tienen un funcionamiento similar a las del enfoque DevOps. En este caso, el equipo de desarrollo de machine learning se encarga de diseñar y crear una arquitectura de modelo que satisfaga las necesidades del cliente, o planifica los cambios necesarios según la información recibida del equipo de operaciones.

El nuevo modelo pasa a manos de los ingenieros y analistas de datos, que realizan los cambios necesarios al conjunto de datos y envían los cambios realizados de vuelta al equipo de ingenieros de machine learning. Estos testean y evalúan el modelo, y se comunican con el equipo de operaciones, para desplegar y realizar las configuraciones necesarias para la puesta en marcha del modelo creado. Este equipo monitoriza el comportamiento del modelo y reporta a los ingenieros de machine learning los resultados para que puedan evaluar si es necesario realizar algún cambio en el modelo, con lo que vuelve a comenzar el proceso anterior.

Una de las herramientas más interesantes para gestionar el ciclo de vida de este tipo de proyectos es MLflow https://mlflow.org, una plataforma de código abierto diseñada para gestionar el ciclo de vida completo de los proyectos de aprendizaje automático. Desde el seguimiento de experimentos hasta la implementación de modelos en producción, MLflow ofrece una solución unificada y flexible.

La idea que hay detrás de MLFlow es ofrecer a los científicos de datos una herramienta para controlar la experimentación, la reproducibilidad y el despliegue de modelos de aprendizaje automático. MLFlow le permite:

● Realizar un seguimiento de los hiperparámetros y métricas de los modelos con MLFlow Tracking https://mlflow.org/docs/latest/tracking.html.

● Guardar sus modelos en un formato que permita la reproducibilidad en otras máquinas con MLFlow Projects https://mlflow.org/docs/latest/projects.html.

● Poner en producción modelos de una manera muy fácil en AWS o Azure con MLFlow Models https://mlflow.org/docs/latest/models.html.

● Tener un registro para centralizar y guardar sus modelos con MLFlow Registry https://mlflow.org/docs/latest/model-registry.html.

Figura 1.6 Componentes de MLFlow para la gestión del ciclo de vida de los proyectos

MLFlow nos permite hacer tracking de todos los componentes que conforman un modelo, desde su código y artefactos hasta los parámetros y las métricas, así como otros metadatos de interés. También nos ayuda en la gestión de los modelos mediante el model registry, que nos permite indicar en qué fase se encuentra cada versión del modelo.

1.5.4. AIOps

AIOps (Artificial Intelligence for IT Operations) son una serie de metodologías que tienen como objetivo automatizar procesos como la detección de anomalías o correlación de eventos. Para ello, se utilizan técnicas de inteligencia artificial y algoritmos de machine learning, con el fin de filtrar los datos en busca de eventos significativos o patrones de comportamiento del sistema relacionados con su rendimiento. Esta información se le comunica en tiempo real al grupo encargado del mantenimiento del sistema, que puede solucionar esos fallos de manera rápida y eficaz —aunque, dependiendo del entorno, el propio sistema de inteligencia artificial puede ser capaz de dar solución a estos problemas—.

AIOps se puede definir como la aplicación de capacidades de inteligencia artificial, como el procesamiento del lenguaje natural y los modelos de aprendizaje automático, para automatizar y agilizar los flujos de trabajo operativos. Mediante capacidades de big data, analítica y aprendizaje automático, este tipo de operaciones va a permitir:

● Recopilar y agregar enormes volúmenes de datos generados por múltiples componentes de la infraestructura de IT.

● Separar de forma inteligente lo importante con el objetivo de identificar sucesos y patrones significativos relacionados con el rendimiento de las aplicaciones y los problemas de disponibilidad.

● Diagnosticar las causas y comunicarlas a los departamentos de IT y DevOps para una respuesta y corrección rápidas, o para resolver de forma automática los problemas sin intervención humana.

Las ventajas que aporta AIOps se pueden resumir en los siguientes puntos:

●Tiempo medio de reparación más rápido: al reducir el ruido de las operaciones de IT y correlacionar los datos de operaciones de varios entornos, la AIOps puede identificar las causas del problema y proponer soluciones de forma más rápida y precisa que lo haría un humano.

●Menores costes operativos: gracias a la identificación automática de problemas operativos y los scripts de respuesta automática reducirán los costes asociados.

●Mayor observabilidad y mejor colaboración: se facilita una colaboración entre equipos más eficaz en todas las funciones de DevOps, ITOps, gobierno y seguridad.

1.5.5. GitOps

La metodología DevOps ha cambiado en los últimos años la forma en que el software se desarrolla y se gestiona; sin embargo, dado que los sistemas se van volviendo cada vez más complejos, es necesario implementar prácticas que mejoren la eficiencia. GitOps está siendo la clave, porque combina la automatización con el control de versiones. En esta sección vamos a conocer en qué consiste, su funcionamiento y su implementación.

GitOps se basa en los principios fundamentales de DevOps, como la automatización, la integración continua (CI) y la entrega continua (CD), pero los lleva un paso más allá al centralizar todas las configuraciones y las operaciones en un repositorio Git. De este modo, GitOps convierte a Git en el centro de operaciones para todo el ciclo de vida del software. Por tanto, cualquier cambio en la infraestructura o en las aplicaciones se realiza a través de commits en el repositorio Git, y se garantiza que el control de versiones es total y que hay una trazabilidad clara.

En GitOps, la infraestructura se define como código y se almacena en un repositorio distribuido como Git. Los cambios en el código activan unas acciones automatizadas que despliegan estos cambios en el entorno de destino, lo que facilita el mantenimiento y la coherencia en los entornos de desarrollo, pruebas y producción. GitOps sigue un flujo de trabajo sencillo que incluye los siguientes pasos:

● El código de la infraestructura se almacena en un repositorio Git.

● El estado deseado de la infraestructura se define como código y se versiona en Git.

● Los cambios en el código activan un proceso automatizado que recupera la última versión del código de Git, la prueba y la despliega en el entorno de destino.

● La infraestructura desplegada se supervisa y audita para garantizar el cumplimiento de los requisitos normativos.

Todo comienza con la definición del estado deseado del sistema. Esto incluye la configuración de la infraestructura, las definiciones de las aplicaciones y cualquier otro aspecto del sistema que necesite ser gestionado. Este estado deseado se describe en archivos de configuración y código, que se almacenan en un repositorio de Git. Por ejemplo, podríamos tener archivos YAML que describiesen cómo debería ser la infraestructura de usted y qué aplicaciones deben ejecutarse.

Para aplicar el estado deseado, existen herramientas de GitOps como Argo CD https://argoproj.github.io/cd/ o Flux https://fluxcd.io, que permiten supervisar continuamente el repositorio de Git en busca de cambios en el estado deseado. Cuando se detectan cambios, la herramienta compara el estado deseado con el estado actual del sistema; si existe alguna diferencia, se aplican los cambios necesarios para que coincidan. Por ejemplo, si se añade una nueva definición de aplicación al repositorio, la herramienta se asegura de que esa aplicación se despliegue automáticamente en el entorno de producción.

Después de aplicar los cambios, la herramienta de GitOps continúa monitoreando el sistema para detectar cualquier desviación del estado deseado. Por ejemplo, si una aplicación se cae inesperadamente, la herramienta la reiniciará automáticamente para restaurarla al estado deseado.

GitOps se fundamenta en los siguientes principios básicos, que son los que guían su funcionamiento y que son esenciales para su implementación:

●Automatización mediante CI/CD: utiliza herramientas de integración y entrega continua (CI/CD). Cualquier cambio en el repositorio Git desencadena automáticamente pipelines que aplican estos cambios a los entornos de destino, ya sea desarrollo, pruebas o producción.

●Observabilidad y monitorización: GitOps exige una fuerte capacidad de observabilidad y monitoreo para garantizar que los sistemas funcionen según lo previsto. Para ello, se usan herramientas que proporcionan métricas, registros y alertas en tiempo real.

●Sincronización continua: el funcionamiento de GitOps se basa en la sincronización constante entre el repositorio Git y los entornos de implementación. Cuando un desarrollador realiza un cambio en la configuración o el código y lo confirma en Git, una herramienta de CI/CD como Jenkins, GitLab CI o Argo CD se encarga de desplegar automáticamente esos cambios. Si hay algún problema en la implementación, el ingeniero DevOps puede revertir fácilmente los cambios a un estado anterior utilizando las capacidades de control de versiones de Git.

Si analizamos las diferencias entre el enfoque GitOps con el tradicional de integración continua y despliegue continuo, en un pipeline CI/CD tradicional cuando un desarrollador sube al repositorio de la aplicación el código, se lanza el proceso de construcción, que habitualmente se compone de ejecución de pruebas unitarias, de integración, comprobación de la calidad, generación de la imagen con la aplicación y subida al repositorio de imágenes. Posteriormente se despliega en el clúster de Kubernetes, todo ello desde el propio pipeline.

Figura 1.7 Pipeline tradicional Integración continua + despliegue continuo

En cambio, el pipeline de GitOps es ligeramente diferente: separa el proceso de construcción del proceso de despliegue.

Figura 1.8 Pipeline de GitOps integración continua + despliegue continuo

Como se puede ver en el diagrama, el proceso de construcción es idéntico al anterior. El verdadero cambio se centra en el despliegue. Aparecen dos nuevos elementos: el repositorio de configuración, donde se almacenan todos los ficheros de despliegue de nuestra aplicación y un operador desplegado en el clúster de Kubernetes, que se encarga de monitorizar el repositorio de configuración y cuando exista un cambio desplegarlo en el clúster. De esta forma, cuando se quiera subir una nueva versión de la aplicación, se deberá realizar un Pull Request en el repositorio de configuración, y cuando este se haya aprobado por las personas encargadas para este propósito, se despliega automáticamente en el entorno correspondiente en el que se haya solicitado el despliegue.

Además, GitOps añade una ventaja desde el punto de vista de seguridad. El propio clúster es el que se encarga de desplegar las aplicaciones, a diferencia de los pipelines tradicionales, que necesitan tener las credenciales con privilegios de administrador para poder desplegar las aplicaciones. Además, con GitOps cualquier cambio de estado del clúster está registrado, es decir, se sabe quién realizó el cambio, quién lo aprobó y cuándo se desplegó.

Otro aspecto importante es cuando se necesita restaurar el clúster por algún desastre. En el caso de GitOps sólo se deben sincronizar los repositorios de configuración, mientras que en el pipeline tradicional se deben volver a ejecutar los jobs de todas las aplicaciones. Entre las principales ventajas del uso de GitOps podemos destacar:

●Control de versiones y trazabilidad: al utilizar Git como única fuente de verdad, hay un historial completo de cambios que facilita el seguimiento. Si hay un error en la infraestructura como código, GitOps puede identificar con rapidez qué cambio lo causó y revertirlo.

●Automatización y eficiencia: GitOps automatiza los procesos de despliegue de las infraestructuras y aplicaciones, lo que se traduce en una mayor eficiencia y productividad. Al definir el estado deseado de la infraestructura como código y automatizar el proceso de despliegue, los equipos pueden ahorrar una cantidad significativa de tiempo y recursos que, de otro modo, se emplearían en tareas manuales de configuración y despliegue.

●Consistencia y confiabilidad: GitOps promueve un enfoque declarativo de la gestión de infraestructuras, en el que el estado deseado de la infraestructura se especifica en código y se versiona en Git. Este enfoque hace que sea más fácil garantizar que la infraestructura desplegada sea coherente con el estado deseado, lo que conduce a una mayor fiabilidad.

●Mayor colaboración: GitOps promueve la colaboración entre equipos con un repositorio centralizado donde todos los cambios son visibles y se pueden revisar antes de aplicarlos. Se mejora también la comunicación y la coordinación al revisar y aprobar cambios desde el repositorio Git.

●Mayor seguridad: GitOps promueve un enfoque seguro y auditable de la gestión de la infraestructura aprovechando las capacidades de control de acceso y auditoría integradas en Git. Esto facilita el seguimiento de los cambios en la infraestructura y garantiza el cumplimiento de los requisitos normativos.

●Mayor velocidad de despliegue y recuperación ante fallos: con GitOps los despliegues se vuelven más rápidos y predecibles. Al automatizar el proceso de implementación y alinear la infraestructura y el código con el repositorio de Git, podemos desplegar cambios de forma rápida y consistente. Además, en caso de fallo o necesidad de hacer un rollback, GitOps facilita la recuperación. Como todo está versionado en Git, podemos revertir cambios rápidamente de versiones anteriores y restaurar el sistema a un estado conocido y estable.

La implantación de GitOps implica varios pasos, entre ellos:

●Definir el estado deseado de la infraestructura como código: el primer paso en la implementación de GitOps es definir el estado deseado de la infraestructura como código. Esto implica identificar los componentes de la infraestructura, como servidores, bases de datos y balanceadores de carga, y definir sus configuraciones como código.

●Almacenamiento del código de la infraestructura en Git: el siguiente paso es almacenar el código de la infraestructura en Git. Esto implica crear un repositorio Git y enviar el código de la infraestructura al repositorio.

●Establecer un proceso automatizado: el siguiente paso es configurar las acciones automatizadas necesarias que recuperen la última versión del código de Git, se ejecuten las pruebas automatizadas y se despliegue en el entorno de destino.

●Supervisión y auditoría: una vez desplegada la infraestructura, es importante supervisar y auditar los cambios para garantizar el cumplimiento de los requisitos normativos.