Capítulo 2: MLOps vs DevOps vs DataOps

Comprendiendo el panorama Ops

El panorama moderno de datos y software involucra múltiples disciplinas "Ops". Comprender cómo se relacionan y en qué difieren es crucial para construir equipos y sistemas efectivos.

Resumen comparativo

Tabla comparativa detallada

Aspecto	DevOps	DataOps	MLOps
Enfoque principal	Entrega de software	Entrega de pipelines de datos	Entrega de modelos de ML
Artefacto principal	Código de aplicación	Productos de datos	Modelos de ML
Pruebas	Unitarias, integración, E2E	Calidad de datos, esquema	Validación de modelos, A/B
Versionado	Solo código	Linaje de datos	Código + Datos + Modelos
Monitoreo	Métricas de app, logs	Métricas de calidad de datos	Desempeño del modelo, drift
Objetivo CI/CD	Desplegar aplicaciones	Desplegar pipelines de datos	Desplegar modelos
Bucle de retroalimentación	Reportes de bugs	Problemas de datos	Degradación del modelo

DevOps: La base

DevOps se enfoca en acortar el ciclo de vida de desarrollo mientras entrega funcionalidades, correcciones y actualizaciones de manera frecuente.

Prácticas clave de DevOps

# Example: Standard DevOps CI/CD Pipeline
name: Application CI/CD
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build
        run: npm run build
      
      - name: Unit Tests
        run: npm test
      
      - name: Integration Tests
        run: npm run test:integration
      
      - name: Build Docker Image
        run: docker build -t myapp:${{ github.sha }} .

  deploy:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Deploy to Production
        run: kubectl apply -f k8s/

Herramientas DevOps

Categoría	Herramientas
Control de versiones	Git, GitHub, GitLab
CI/CD	Jenkins, GitHub Actions, GitLab CI
Contenedores	Docker, Podman
Orquestación	Kubernetes, Docker Swarm
Monitoreo	Prometheus, Grafana, Datadog
IaC	Terraform, Ansible, Pulumi

DataOps: Gestión de pipelines de datos

DataOps aplica principios de DevOps a los flujos de trabajo de analítica y de ingeniería de datos.

Prácticas clave de DataOps

# Example: DataOps Pipeline with Great Expectations
import great_expectations as gx
from great_expectations.core.batch import BatchRequest

# Create data context
context = gx.get_context()

# Define expectations for data quality
validator = context.get_validator(
    batch_request=BatchRequest(
        datasource_name="my_datasource",
        data_connector_name="default_inferred_data_connector",
        data_asset_name="sales_data",
    ),
    expectation_suite_name="sales_data_expectations"
)

# Data quality checks
validator.expect_column_values_to_not_be_null("customer_id")
validator.expect_column_values_to_be_between("quantity", min_value=1, max_value=1000)
validator.expect_column_values_to_be_unique("order_id")
validator.expect_column_values_to_match_regex("email", r"^[\w\.-]+@[\w\.-]+\.\w+$")

# Save expectations
validator.save_expectation_suite(discard_failed_expectations=False)

Herramientas DataOps

Categoría	Herramientas
Orquestación	Apache Airflow, Dagster, Prefect
Calidad de datos	Great Expectations, dbt tests, Soda
Catálogo de datos	DataHub, Amundsen, Apache Atlas
ETL/ELT	dbt, Spark, Fivetran
Linaje de datos	OpenLineage, Marquez

MLOps: La intersección

MLOps se sitúa en la intersección de DevOps y DataOps, heredando prácticas de ambos y agregando capacidades específicas de ML.

Qué aporta MLOps

Retos específicos de MLOps

Reto	Descripción	Solución
Reproducibilidad del modelo	Mismo código, diferentes resultados	Fijar semillas, bloquear entornos
Drift de datos	Los datos de entrada cambian con el tiempo	Detección de drift, monitoreo
Decaimiento del modelo	El desempeño del modelo se degrada	Entrenamiento continuo, alertas
Gestión de experimentos	Seguimiento de muchos experimentos	MLflow, W&B, Neptune
Consistencia de features	Desajuste entre features de entrenamiento y de servicio	Feature stores

Estructuras de equipo

Opción 1: Equipo centralizado de MLOps

┌─────────────────────────────────────────────────────────┐
│                    MLOps Platform Team                   │
├─────────────────────────────────────────────────────────┤
│  • Owns ML infrastructure                                │
│  • Provides self-service tools                          │
│  • Sets standards and best practices                    │
│  • Supports multiple ML teams                           │
└─────────────────────────────────────────────────────────┘
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
     ┌─────────┐    ┌─────────┐    ┌─────────┐
     │ ML Team │    │ ML Team │    │ ML Team │
     │    A    │    │    B    │    │    C    │
     └─────────┘    └─────────┘    └─────────┘

Ventajas:

Estándares consistentes
Uso eficiente de recursos
Especialización

Desventajas:

Potencial cuello de botella
Puede no comprender necesidades específicas de los equipos

Opción 2: Ingenieros de MLOps embebidos

┌─────────────────────────────────────────────────────────┐
│                   Product Team A                         │
├─────────────────────────────────────────────────────────┤
│  Data Scientists (3) + ML Engineer (1) + MLOps (1)      │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│                   Product Team B                         │
├─────────────────────────────────────────────────────────┤
│  Data Scientists (2) + ML Engineer (2) + MLOps (1)      │
└─────────────────────────────────────────────────────────┘

Ventajas:

Conocimiento profundo del dominio
Iteración rápida
Comunicación directa

Desventajas:

Esfuerzos duplicados
Prácticas inconsistentes
Uso intensivo de recursos

Opción 3: Modelo híbrido (Recomendado)

┌─────────────────────────────────────────────────────────┐
│              Central MLOps Platform Team                 │
│  (Infrastructure, Tools, Standards, Support)            │
└─────────────────────────────────────────────────────────┘
                          │
    ┌─────────────────────┼─────────────────────┐
    ▼                     ▼                     ▼
┌───────────┐       ┌───────────┐       ┌───────────┐
│ Product   │       │ Product   │       │ Product   │
│ Team A    │       │ Team B    │       │ Team C    │
│           │       │           │       │           │
│ ML Eng ◄──┼───────┼──► Shared │◄──────┼─► ML Eng  │
│           │       │   Tools   │       │           │
└───────────┘       └───────────┘       └───────────┘

Matriz de responsabilidades

Matriz RACI para un proyecto de ML

Actividad	Data Scientist	ML Engineer	MLOps Engineer	Data Engineer
Recolección de datos	C	I	I	R/A
Ingeniería de features	R/A	C	I	C
Desarrollo de modelos	R/A	C	I	I
Pipeline de entrenamiento	C	R/A	C	I
Despliegue de modelos	I	C	R/A	I
Monitoreo	I	C	R/A	C
Infraestructura	I	I	R/A	I

Leyenda: R = Responsable, A = Autoridad, C = Consultado, I = Informado

Puntos de colaboración

Entrega de datos (DataOps → MLOps)

# Example: Data contract between DataOps and MLOps
data_contract:
  name: customer_features
  version: 1.2.0
  owner: data-engineering@company.com
  
  schema:
    customer_id:
      type: string
      nullable: false
      pattern: "^CUS-[0-9]{8}$"
    
    age:
      type: integer
      nullable: false
      min: 18
      max: 120
    
    total_purchases:
      type: float
      nullable: false
      min: 0.0
  
  sla:
    freshness: 1 hour
    availability: 99.9%
    
  delivery:
    format: parquet
    location: s3://data-lake/features/customer/
    update_frequency: hourly

Entrega de despliegue (MLOps → DevOps)

# Example: Model deployment specification
model_deployment:
  name: customer-churn-model
  version: 2.1.0
  
  container:
    image: mlplatform/models:customer-churn-v2.1.0
    resources:
      cpu: "2"
      memory: "4Gi"
      gpu: "0"
    
  scaling:
    min_replicas: 2
    max_replicas: 10
    target_cpu_utilization: 70%
    
  endpoints:
    health: /health
    predict: /predict
    metrics: /metrics
    
  monitoring:
    latency_p99_threshold_ms: 100
    error_rate_threshold: 0.01

Puntos clave

Summary

DevOps se enfoca en la entrega de aplicaciones - MLOps extiende esto a los modelos
DataOps se enfoca en la calidad de los datos - MLOps depende de datos limpios y versionados
MLOps combina ambos y agrega prácticas específicas de ML (seguimiento de experimentos, versionado de modelos)
La estructura del equipo debe ajustarse a la madurez y tamaño de la organización
Interfaces claras entre equipos previenen cuellos de botella y confusión

Ejercicio práctico

Cree un documento comparativo simple para su organización:

Liste las prácticas actuales de DevOps
Liste las prácticas actuales de DataOps (si existen)
Identifique brechas para la implementación de MLOps
Proponga cambios en la estructura del equipo

Siguiente: Capítulo 3: El ciclo de vida de ML

Comprendiendo el panorama Ops​

Resumen comparativo​

Tabla comparativa detallada​

DevOps: La base​

Prácticas clave de DevOps​

Herramientas DevOps​

DataOps: Gestión de pipelines de datos​

Prácticas clave de DataOps​

Herramientas DataOps​

MLOps: La intersección​

Qué aporta MLOps​

Retos específicos de MLOps​

Estructuras de equipo​

Opción 1: Equipo centralizado de MLOps​

Opción 2: Ingenieros de MLOps embebidos​

Opción 3: Modelo híbrido (Recomendado)​

Matriz de responsabilidades​

Matriz RACI para un proyecto de ML​

Puntos de colaboración​

Entrega de datos (DataOps → MLOps)​

Entrega de despliegue (MLOps → DevOps)​

Puntos clave​

Ejercicio práctico​