De DevOps a MLOps y platform engineering: qué aprender

La pregunta incómoda de todo profesional DevOps#

Hay una conversación que se repite en los equipos de infraestructura: si la IA puede escribir YAML, generar pipelines básicos, revisar logs y proponer configuraciones iniciales, ¿qué queda del rol DevOps tradicional?

Es una preocupación legítima. Buena parte del trabajo que durante años definió a un ingeniero DevOps es manual, repetitivo y automatizable, lo que el libro de SRE de Google llama toil. Es justo el tipo de trabajo que las herramientas de IA hacen cada vez mejor. Generar un manifiesto de Kubernetes, esbozar un pipeline de CI/CD o resumir un stack trace ya no te diferencia.

Pero confundir “una parte de mis tareas se está automatizando” con “mi rol está desapareciendo” es un error de lectura. DevOps no se está muriendo: se está moviendo hacia arriba en la cadena de valor, y quien entienda ese movimiento a tiempo termina en un rol más estratégico.

Documentación: Google SRE Book · Eliminating Toil ↗

DevOps no desaparece: cambia su centro de gravedad#

El futuro de DevOps no es escribir menos infraestructura, sino diseñarla mejor y dejar que la ejecución repetitiva se automatice.

Cuando la IA absorbe la capa operativa básica, gana valor lo que la IA no hace bien: decisiones de arquitectura, trade-offs de costo y rendimiento, diseño de plataformas seguras y escalables, y operar sistemas complejos en producción sin que se caigan a las 3 de la mañana.

Tres disciplinas concentran ese movimiento, y las tres son una evolución natural de un perfil DevOps, no un cambio de carrera:

• Platform engineering: construir plataformas internas que el resto de la organización consume en autoservicio.
• MLOps: llevar modelos de machine learning e IA a producción de forma confiable, reproducible y monitoreada.
• DevSecOps: integrar seguridad y cumplimiento en el diseño, no como parche final.

La buena noticia: si vienes de DevOps, buena parte del camino ya está recorrida.

De DevOps a platform engineering: de operar a habilitar#

Platform engineering responde a un problema real: los equipos de desarrollo no quieren convertirse en expertos en Kubernetes, redes y configuración cloud para desplegar una aplicación. Cada hora que un desarrollador pelea con la infraestructura es una hora que no construye producto.

El rol DevOps tradicional resolvía esto atendiendo tickets. Platform engineering lo resuelve construyendo un producto interno: caminos pavimentados (golden paths), plantillas seguras por defecto y autoservicio que esconden la complejidad de la nube. DORA reporta que en 2025 el 90 % de las organizaciones declaraba usar una plataforma interna de desarrollo y el 76 % tenía equipos de plataforma dedicados.

El cambio mental es grande. Dejas de ejecutar despliegues y pasas a diseñar el sistema con el que cientos de despliegues ocurren solos. Tu cliente ya no es un servidor, es el desarrollador interno, y tu métrica ya no es “ticket cerrado” sino cuánto tarda un equipo en llevar código a producción de forma segura.

Las bases, Kubernetes, infraestructura como código, automatización, pipelines y observabilidad, siguen siendo el cimiento. Lo que se agrega es pensamiento de producto, diseño de experiencia de desarrollador y criterio de estandarización. Backstage, el framework de portales de desarrollador que Spotify donó a la CNCF, es un buen lugar para ver cómo se modela un catálogo de servicios y plantillas.

Documentación: DORA · Platform engineering ↗ · CNCF TAG App Delivery · Platforms white paper ↗ · Backstage · What is Backstage? ↗

De DevOps a MLOps: la infraestructura es el verdadero reto de la IA en producción#

Existe un mito costoso: que hacer IA es sobre todo un problema de ciencia de datos. El paper de Google sobre deuda técnica oculta en sistemas de ML lo muestra con claridad: el código del modelo es una fracción pequeña del sistema, rodeado de recolección de datos, configuración, serving, monitoreo e infraestructura. Mantener un modelo en producción, con baja latencia, detectando su degradación, reentrenándolo cuando los datos cambian, controlando el costo de GPU y con trazabilidad, es un problema de infraestructura y operaciones. Es decir, tu terreno.

MLOps es, en esencia, DevOps aplicado al ciclo de vida de los modelos, y casi todo lo que sabes se transfiere:

• Los pipelines de CI/CD se extienden para versionar datos y modelos, no solo código; Google describe esto como pasar de despliegues manuales a entrenamiento continuo.
• La observabilidad se amplía: además de CPU y latencia, monitoreas deriva de datos (data drift), deriva de concepto y calidad de las predicciones.
• La automatización cubre el reentrenamiento y el despliegue de nuevas versiones de modelo.
• La gestión de costos se vuelve crítica: la IA consume cómputo caro, y alguien tiene que diseñar la infraestructura para que escale sin quemar el presupuesto.

Lo nuevo es vocabulario y herramientas: registros de modelos, feature stores, versionado de datasets, frameworks de serving y monitoreo de modelos. Conceptos nuevos, montados sobre fundamentos que ya dominas. Un registro de modelos, por ejemplo, es para un modelo lo que un registro de imágenes es para un contenedor:

import mlflow
from mlflow import MlflowClient

MODEL = "fraud-detector"
run_id = "<run-id-del-entrenamiento>"   # lo entrega el pipeline de entrenamiento

# 1. Registrar el artefacto como una nueva versión del modelo
mv = mlflow.register_model(f"runs:/{run_id}/model", MODEL)

# 2. Promover solo si pasó la evaluación automática en CI
client = MlflowClient()
client.set_registered_model_alias(MODEL, "champion", mv.version)

# 3. El servicio de inferencia carga el alias, no una versión fija:
#    un rollback es mover el alias a la versión anterior.
model = mlflow.pyfunc.load_model(f"models:/{MODEL}@champion")

Los servicios gestionados siguen la misma lógica: SageMaker Model Monitor y Vertex AI Model Monitoring comparan el tráfico de producción con una línea base y alertan cuando se desvía.

Documentación: NeurIPS 2015 · Hidden Technical Debt in Machine Learning Systems ↗ · Google Cloud · MLOps: continuous delivery and automation pipelines in ML ↗ · MLflow · Model Registry ↗ · AWS · SageMaker Model Monitor ↗ · Google Cloud · Vertex AI Model Monitoring ↗

DevSecOps: la seguridad deja de ser opcional#

A medida que la infraestructura soporta IA, automatización y datos sensibles, la superficie de ataque crece y la regulación se endurece. DevSecOps pasa a ser parte del diseño base: gestión de secretos, políticas como código, escaneo continuo, control de accesos y cumplimiento auditable desde el primer commit.

El Secure Software Development Framework del NIST (SP 800-218) es una buena referencia para ordenar esas prácticas, y herramientas como Open Policy Agent permiten expresar reglas de despliegue como código revisable.

Para un perfil DevOps es una oportunidad clara de especialización: una empresa que adopta IA sin una capa de seguridad sólida está construyendo un riesgo, no una ventaja.

Documentación: NIST SP 800-218 · Secure Software Development Framework ↗ · Open Policy Agent · Documentation ↗

Qué priorizar para evolucionar sin empezar de cero#

Con una base DevOps sólida no necesitas reinventarte: necesitas reorientarte. Un orden razonable:

• Profundiza Kubernetes e infraestructura como código hasta el nivel de diseño, no solo de uso; incluye la programación de GPUs en Kubernetes si vas hacia MLOps.
• Domina la observabilidad real: métricas, trazas y logs, y sobre todo la capacidad de explicar el comportamiento de un sistema en producción. OpenTelemetry es el estándar abierto que conviene conocer.
• Aprende el ciclo de vida de modelos: versionado de datos y modelos, serving, reentrenamiento y monitoreo de drift.
• Incorpora pensamiento de plataforma y de costos: autoservicio, escalabilidad y eficiencia del gasto cloud.
• Trata la seguridad como diseño, no como parche.
• Usa la IA como multiplicador: deja que automatice lo repetitivo para concentrarte en arquitectura y decisiones.

Documentación: Kubernetes · Schedule GPUs ↗ · OpenTelemetry · What is OpenTelemetry? ↗ · Kubeflow · Pipelines overview ↗

La infraestructura sigue siendo la base#

La IA no elimina la necesidad de buena infraestructura: la amplifica. Cada modelo en producción, cada agente y cada flujo automatizado se apoya en cómputo, redes, seguridad, pipelines y observabilidad que alguien tiene que diseñar y operar bien. Esa capa decide si un proyecto de IA escala de forma rentable o se convierte en un agujero de costos.

Por eso el perfil DevOps no está en riesgo de extinción. Está en el centro de la próxima ola, siempre que se mueva de la ejecución operativa al diseño estratégico. No puedes montar IA sobre infraestructura improvisada, y construir esa base sigue siendo el trabajo más valioso del mundo DevOps.

Preguntas frecuentes#

¿Qué diferencia hay entre MLOps y platform engineering? MLOps gestiona el ciclo de vida de los modelos en producción; platform engineering diseña plataformas internas de autoservicio para desarrolladores. Ambas nacen de DevOps con distinto foco, y en muchas empresas la plataforma termina ofreciendo capacidades de MLOps como un servicio más.

¿Qué habilidades técnicas necesito para MLOps? Fundamentos de machine learning, orquestación de pipelines con herramientas como Kubeflow o MLflow, y monitoreo de modelos en producción: deriva de datos, deriva de concepto y latencia de inferencia. No necesitas convertirte en data scientist.

¿Sigue valiendo la pena aprender DevOps? Sí. Automatización, CI/CD e infraestructura como código siguen siendo la base de ambas especialidades. Lo que cambia es el foco: diseño de sistemas y plataformas en lugar de ejecución manual repetitiva.

¿Cómo empiezo con platform engineering? Asume que construyes un producto para otros desarrolladores. Explora golden paths y Backstage, y mide el éxito por la reducción de tickets de soporte y del tiempo que tarda un equipo nuevo en desplegar.

¿Qué pasa si no evoluciono mi perfil? El riesgo es la comoditización: las tareas operativas manuales son cada vez más automatizables, y el valor profesional se desplaza hacia arquitectura, diseño de plataformas y operación de sistemas complejos.

Documentación: Backstage · What is Backstage? ↗ · Kubeflow · Pipelines overview ↗ · MLflow · Model Registry ↗