Diferencias entre SRE vs DevOps vs Platform Engineer
La confusión de los roles modernos
Si has trabajado en tecnología en los últimos años, es posible que te hayas encontrado con estas tres siglas en ofertas de trabajo, en conversaciones de café o en conferencias: SRE, DevOps y Platform Engineer. A menudo se usan como si fueran sinónimos, o peor, se mezclan en una sopa de letras que no aclara nada. Y la verdad es que, aunque comparten territorio, cada uno tiene su propia identidad, sus propias herramientas y, sobre todo, su propia forma de entender el día a día.
Llevo tiempo dando vueltas a este tema, no solo por curiosidad académica, sino porque en el campo real los límites se difuminan. He visto equipos donde un “DevOps Engineer” hace exactamente lo mismo que un SRE, y plataformas donde el Platform Engineer es el héroe silencioso que hace que los desarrolladores no tengan que pensar en infraestructura. Así que voy a intentar poner orden en este caos, desde mi perspectiva y con lo que he visto funcionar.
DevOps: La filosofía que lo empezó todo
DevOps no es un rol, es una cultura. Eso es lo primero que hay que tener claro. Nació como una respuesta al muro que existía entre desarrollo y operaciones. El equipo de desarrollo quería ir rápido, lanzar features cada dos días. El equipo de operaciones quería estabilidad, que nada se rompiera en producción. Esa tensión generaba cuellos de botella y resentimiento.
La solución era simple en teoría: romper ese muro. Hacer que ambos equipos trabajaran juntos, con objetivos compartidos. DevOps propuso automatizar todo lo que pudieras automatizar, medir todo lo que pudieras medir y crear un ciclo de retroalimentación continua.
En la práctica, el “DevOps Engineer” se convirtió en la persona que construye y mantiene la infraestructura de CI/CD, las pipelines de despliegue, los entornos de testing automatizado y las herramientas que permiten a los desarrolladores entregar código de forma continua. Piensa en Jenkins, GitLab CI, GitHub Actions, Terraform para la infraestructura como código, Ansible para la configuración.
Lo que hace un DevOps Engineer en su día a día típico:
┌─────────────────────────────────────────────────────┐
│ DevOps Engineer │
├─────────────────────────────────────────────────────┤
│ │
│ Diseña pipelines CI/CD │
│ Gestiona infraestructura como código (IaC) │
│ Implementa automatización de despliegues │
│ Configura herramientas de monitoreo básico │
│ Facilita el proceso de entrega de software │
│ │
│ Métricas: frecuencia de deploy, tiempo de entrega │
│ │
└─────────────────────────────────────────────────────┘
El DevOps Engineer es el que construye la autopista por la que viaja el código. No se preocupa tanto por la fiabilidad del servicio una vez que está desplegado, sino por que el proceso de llevar ahí el código sea rápido, fiable y repetible.
SRE: La ingeniería aplicada a la operación
SRE nació en Google, y la definición original es brillante: “lo que sucede cuando le pides a un ingeniero de software que diseñe un equipo de operaciones”. No es una cultura, es una disciplina con principios, métricas y herramientas concretas.
La diferencia fundamental con DevOps es el enfoque en la fiabilidad. Mientras DevOps se centra en acelerar la entrega, SRE se centra en mantener el servicio funcionando una vez que está desplegado. Y lo hace de una forma muy específica: con SLOs, SLIs y Error Budgets.
Un SRE define un SLO (Objetivo de Nivel de Servicio) para cada servicio crítico. Por ejemplo, “el 99.9% de las peticiones HTTP deben responder en menos de 200ms”. Ese 0.1% de margen de error es el Error Budget. Si el servicio está dentro de ese presupuesto, los desarrolladores pueden lanzar nuevas features con confianza. Si se sale, todo el equipo se detiene a arreglar la fiabilidad antes de hacer nada nuevo.
En el día a día, un SRE hace cosas como:
┌─────────────────────────────────────────────────────┐
│ SRE │
├─────────────────────────────────────────────────────┤
│ │
│ Define y monitoriza SLOs/SLIs │
│ Gestiona incidentes y postmortems │
│ Reduce toil (trabajo manual repetitivo) │
│ Implementa observabilidad profunda │
│ Participa en diseño de arquitectura │
│ │
│ Métricas: disponibilidad, latencia, error rate │
│ │
└─────────────────────────────────────────────────────┘
El SRE es el que se asegura de que la autopista que construyó DevOps no tenga baches, ni caos en rush hour, ni peajes que frenen todo. Monitoriza el tráfico, detecta problemas antes de que escalen y toma decisiones basadas en datos, no en sensaciones.
Platform Engineer: El puente invisible
Platform Engineering es el rol más reciente de los tres, pero ha crecido como la espuma. La idea es simple pero poderosa: construir una plataforma interna que abstraiga la complejidad de la infraestructura para que los desarrolladores no tengan que pensar en ella.
El Platform Engineer crea herramientas de autoservicio. En lugar de que cada desarrollador tenga que configurar su propio entorno de Kubernetes, escribir sus propios manifiestos de Docker, configurar sus propios servicios de monitoreo, la plataforma lo hace todo automáticamente. El desarrollador solo necesita decir “quiero desplegar este servicio con estas dependencias” y la plataforma se encarga del resto.
Pienso en herramientas como Backstage, Kratix, o las plataformas internas que construyen las empresas grandes. El Platform Engineer diseña la experiencia de desarrollo interna.
┌─────────────────────────────────────────────────────┐
│ Platform Engineer │
├─────────────────────────────────────────────────────┤
│ │
│ Construye plataforma interna de autoservicio │
│ Diseña APIs y herramientas para desarrolladores │
│ Gestiona la experiencia del developer workflow │
│ Integra servicios de CI/CD, monitoreo, seguridad │
│ Evoluciona la plataforma según feedback │
│ │
│ Métricas: tiempo de onboarding, satisfacción dev │
│ │
└─────────────────────────────────────────────────────┘
El Platform Engineer es el que construye la estación de servicio, los semáforos, el GPS y las apps de movilidad para que los desarrolladores solo tengan que decidir a dónde ir.
Lo que tienen en común
A pesar de sus diferencias, los tres roles comparten una base sólida:
Automatización: Los tres odian el trabajo manual. Ya sea automatizar un deploy (DevOps), eliminar toil (SRE) o crear una plataforma de autoservicio (Platform), el objetivo es que los humanos no tengan que hacer tareas repetitivas.
Enfoque en el usuario final: Aunque sus “usuarios” inmediatos pueden ser diferentes (los desarrolladores para Platform, los operadores para DevOps, el servicio completo para SRE), los tres trabajan para que el producto final llegue al usuario de forma fiable y rápida.
Cultura de mejora continua: Los tres buscan medir, aprender y mejorar. DevOps con sus métricas de entrega, SRE con sus postmortems, Platform con el feedback de los desarrolladores.
Colaboración: Ninguno de estos roles funciona en una torre de marfil. Los tres requieren trabajo conjunto con desarrollo, seguridad, producto y otros equipos.
El día a día junto a los desarrolladores
Aquí es donde las diferencias se notan más en la práctica:
DevOps Engineer + Backend: El DevOps trabaja mano a mano con el equipo de backend para diseñar las pipelines de despliegue, configurar los entornos de staging y producción, y asegurar que las migraciones de base de datos se ejecuten de forma segura. Cuando un backend quiere desplegar un microservicio nuevo, el DevOps le dice “aquí tienes tu pipeline, aquí está tu entorno de testing”.
SRE + Backend: El SRE se sienta con los backend para definir los SLOs del servicio, revisar la arquitectura desde el punto de vista de la fiabilidad y participar en los postmortems cuando algo se cae. No le dice “cómo” desplegar, sino “qué” necesita el servicio para ser fiable. Si el backend quiere subir la latencia de una query de base de datos, el SRE le recuerda el Error Budget.
Platform Engineer + Frontend/Backend: El Platform Engineer construye la plataforma que hace que tanto frontend como backend no tengan que pensar en infraestructura. El frontend quiere desplegar su app de React con su API Gateway, el Platform le da un self-service portal donde en 5 minutos tiene todo configurado. El backend quiere escalar un servicio porque viene un pico de tráfico, el Platform le ofrece una herramienta para hacerlo sin abrir un ticket al equipo de infraestructura.
┌──────────────┐
│ Desarrollador│
│ (Frontend │
│ o Backend) │
└──────┬───────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ DevOps │ │ SRE │ │ Platform │
│ "¿Cómo │ │ "¿Es │ │ "¿Cómo │
│ despliego?"│ │ fiable?" │ │ facilito?" │
└─────────────┘ └─────────────┘ └─────────────┘
¿Cuál necesitas?
La respuesta corta: depende de tu organización.
Si eres una startup pequeña, probablemente no necesitas los tres roles separados. Un buen ingeniero de backend con mentalidad DevOps puede cubrir mucho terreno. A medida que creces, empieza a doler la ausencia de alguien que piense en fiabilidad (SRE) y de alguien que facilite la vida a los desarrolladores (Platform).
En mi experiencia, la combinación ganadora es:
- DevOps para construir la base de automatización y CI/CD.
- SRE para proteger la fiabilidad y crear una cultura de datos.
- Platform para escalar la productividad del equipo de desarrollo.
Los tres se complementan. DevOps construye la carretera, SRE se asegura de que no haya accidentes, y Platform construye los coches autónomos para que nadie tenga que preocuparse por conducirlo.
Conclusión
Dejar de mezclar estos roles no es solo una cuestión semántica. Entender las diferencias permite contratar mejor, diseñar equipos más eficientes y, sobre todo, que cada persona sepa qué se espera de ella. El DevOps no debería sentirse culpable por no monitorizar SLOs, el SRE no debería perder tiempo configurando pipelines, y el Platform Engineer no debería estar apagando fuegos en producción.
El futuro, en mi opinión, está en la colaboración entre los tres. Las organizaciones que lo entiendan tendrán equipos más felices, servicios más fiables y desarrolladores que pueden centrarse en lo que mejor saben hacer: construir producto.