Abre LinkedIn cualquier día de la semana y encontrarás ofertas de "DevOps Engineer" que piden experiencia en SRE, conocimiento de plataformas internas y dominio de Kubernetes. Todo junto. Como si fuera lo mismo. No lo es. Y la confusión tiene consecuencias reales: equipos mal estructurados, expectativas imposibles y roles que no resuelven el problema que la organización realmente tiene.
Estos tres términos se usan como sinónimos en la industria. Vamos a separarlos con claridad.
DevOps: una cultura, no un puesto de trabajo
DevOps nació como un movimiento cultural. La idea original era simple y potente: romper el muro entre desarrollo y operaciones. Que el equipo que escribe el código también se responsabilice de operarlo. Que los deploys no sean un evento traumático sino un flujo continuo. Que la colaboración reemplace los tickets de "pásamelo a infra."
Lo que DevOps debería ser: una filosofía de trabajo donde desarrollo y operaciones comparten responsabilidad, herramientas y objetivos. Integración continua, entrega continua, feedback loops cortos, automatización como principio.
Lo que DevOps se convirtió en muchas organizaciones: un título de puesto. El "DevOps Engineer" que en realidad es un sysadmin que aprendió Jenkins y Terraform. No hay cambio cultural. No hay responsabilidad compartida. Solo una persona nueva en el organigrama que ahora gestiona los pipelines y sigue recibiendo tickets.
DevOps como cultura funciona. DevOps como rol aislado es un parche organizacional.
SRE: ingeniería aplicada a las operaciones
Site Reliability Engineering nació en Google con una premisa concreta: tratar las operaciones como un problema de ingeniería de software. No es una filosofía abstracta. Es una disciplina con herramientas conceptuales específicas.
Los pilares de SRE son medibles:
- SLOs (Service Level Objectives): objetivos de confiabilidad definidos con números. No "el sistema tiene que ser confiable," sino "el p99 de latencia debe ser menor a 200ms el 99.5% del tiempo."
- Error budgets: la cantidad de indisponibilidad permitida. Si tu SLO es 99.9%, tienes 43 minutos de error budget al mes. Mientras tengas presupuesto, puedes desplegar rápido. Cuando se agota, frenas y estabilizas.
- Reducción de toil: trabajo operativo manual, repetitivo y sin valor duradero. SRE mide el toil y lo automatiza sistemáticamente. Si un ingeniero pasa más del 50% de su tiempo en toil, algo está mal.
- Postmortems sin culpables: cuando algo falla, se analiza el sistema, no se busca al responsable. El fallo es del proceso, no de la persona.
SRE no reemplaza a DevOps. En muchos sentidos, SRE es una implementación concreta de los principios de DevOps, pero con rigor de ingeniería y métricas que la cultura DevOps por sí sola no define.
Platform Engineering: construir el camino pavimentado
Platform Engineering es la disciplina más reciente de las tres, y surge de un problema real: a medida que las organizaciones adoptan microservicios, Kubernetes, múltiples clouds y decenas de herramientas, la carga cognitiva sobre los desarrolladores se vuelve insostenible.
La respuesta de Platform Engineering: construir plataformas internas de desarrollo (Internal Developer Platforms o IDPs) que abstraen la complejidad de la infraestructura y ofrecen a los desarrolladores caminos dorados (golden paths) para desplegar, observar y operar sus servicios.
En la práctica, un equipo de Platform Engineering construye:
- Templates de servicios con configuración de infraestructura predefinida.
- Pipelines de CI/CD estandarizados que los equipos usan sin configurar desde cero.
- APIs de autoservicio para aprovisionar bases de datos, colas, certificados.
- Portales de desarrollo con documentación, catálogo de servicios y métricas.
El objetivo no es quitar autonomía a los desarrolladores. Es darles autonomía con guardarraíles. Que puedan desplegar en producción sin necesitar un ticket a infraestructura, pero siguiendo estándares de seguridad, observabilidad y resiliencia que la plataforma garantiza por diseño.
Tabla comparativa: lo que realmente diferencia a cada uno
DevOps
Origen: movimiento cultural (2009)
Foco: colaboración Dev + Ops
Métrica clave: frecuencia de deploy, lead time
Entregable: cultura y prácticas CI/CD
Anti-patrón: renombrar sysadmin como "DevOps Engineer"
SRE
Origen: Google (2003)
Foco: confiabilidad medible
Métrica clave: SLOs, error budgets, toil
Entregable: sistemas confiables con ingeniería
Anti-patrón: SRE que solo apaga incendios sin automatizar
Platform Engineering
Origen: evolución de DevOps interno (~2020)
Foco: experiencia del desarrollador
Métrica clave: tiempo de onboarding, autoservicio
Entregable: plataforma interna (IDP)
Anti-patrón: plataforma que nadie usa porque no resuelve problemas reales
Cuándo necesitas cada uno
No todas las organizaciones necesitan los tres. La madurez y la escala definen qué priorizar:
- Startup (5-30 ingenieros): DevOps como cultura. Todo el equipo despliega, todo el equipo opera. No necesitas un rol dedicado. Necesitas prácticas: CI/CD, infraestructura como código, deploys automatizados.
- Scale-up (30-200 ingenieros): SRE cuando el uptime se vuelve crítico para el negocio. Cuando un incidente cuesta dinero real y necesitas error budgets, SLOs y postmortems formales. Cuando el toil operativo amenaza con consumir al equipo.
- Enterprise (200+ ingenieros): Platform Engineering cuando la carga cognitiva de la infraestructura frena a los equipos de desarrollo. Cuando cada equipo reinventa su propio pipeline y la inconsistencia genera fragilidad.
El anti-patrón más común: renombrar al sysadmin
El error más frecuente que veo en la industria es tomar al administrador de sistemas tradicional, cambiarle el título a "DevOps Engineer" y declarar que la organización "ya tiene DevOps."
No funciona así. Si la misma persona sigue recibiendo tickets para aprovisionar servidores, si desarrollo sigue tirando el código por encima del muro, si no hay responsabilidad compartida sobre la operación, entonces no tienes DevOps. Tienes un sysadmin con un título nuevo y las mismas frustraciones de siempre.
Lo mismo aplica para SRE. Si tu "SRE" pasa el 100% del tiempo en guardia y resolviendo incidentes sin tiempo para automatizar, reducir toil o definir SLOs, no tienes SRE. Tienes un bombero permanente con un título de ingeniero.
Pueden coexistir, pero no son lo mismo
DevOps como cultura debería existir en toda la organización. SRE como disciplina complementa esa cultura con rigor de ingeniería donde la confiabilidad es crítica. Platform Engineering construye la infraestructura que hace que ambas funcionen a escala.
No compiten entre sí. Se complementan. Pero implementar uno pensando que es otro genera confusión, roles mal definidos y expectativas imposibles.
El nombre del rol importa menos que el problema que resuelve. Define primero qué problema tienes. Después decide qué disciplina, equipo o práctica lo aborda.
