¿Qué es platform engineering (y en qué se diferencia de DevOps y SRE)?

Respuesta corta. DevOps es una meta y un conjunto de prácticas. SRE es una forma concreta de implementar el trabajo de confiabilidad aplicando disciplina de ingeniería de software. Platform engineering (ingeniería de plataformas) es la disciplina de construir las herramientas e infraestructura internas que los equipos de producto usan para desplegar, operar y observar sus servicios. No son alternativas: necesitas las tres. La confusión nace de tratarlos como sinónimos en los títulos de puesto, los organigramas y el marketing de los proveedores.

Los tres conceptos se solapan en la práctica. La misma persona suele hacer trabajo que abarca a los tres, y el tooling es casi el mismo. Aun así describen cosas distintas, con modelos de responsabilidad distintos, métricas de éxito distintas y diseños de organización distintos. Equivocarse en la distinción produce equipos contratados para una cosa, medidos por otra y confundidos sobre ambas.

Por qué se confunden (y por qué tiene sentido)

La confusión no es un problema de vocabulario. Refleja la historia real de cómo crecieron las organizaciones de ingeniería.

DevOps surgió como movimiento alrededor de 2009, en contra del muro entre los equipos de desarrollo y los de operaciones. Ese muro provocaba entregas lentas, dedos acusadores y releases frágiles. El movimiento propuso lo contrario: derribar el muro, compartir la responsabilidad y automatizar el ciclo de feedback.

SRE ya se practicaba en Google antes de que existiera el término DevOps. El libro Site Reliability Engineering (Beyer, Jones, Petoff y Murphy, O'Reilly, 2016) describió lo que Google había construido: ingenieros de software operando sistemas en producción, con error budgets, SLOs y un trade-off deliberado entre confiabilidad y velocidad.

Platform engineering como disciplina propia es más reciente. Ganó tracción cuando las organizaciones grandes descubrieron que escalar las prácticas de DevOps a decenas de equipos exigía que alguien fuera dueño de la capa de infraestructura compartida, y que "todos son dueños" termina significando "nadie la cuida bien". Tres términos, acuñados en momentos distintos por comunidades distintas, para problemas relacionados pero diferentes. Es lógico que se mezclen.

DevOps: una meta, no un equipo

DevOps es una cultura y un conjunto de prácticas para integrar el trabajo de desarrollo y el de operaciones. La meta es entregar software más rápido y con más seguridad. No es el nombre de un equipo, ni un título de puesto, ni un stack tecnológico.

Cuando una empresa dice que "hace DevOps", quiere decir que desarrollo y operaciones trabajan integrados en lugar de en silos, que los equipos comparten la responsabilidad de producción, que los despliegues son frecuentes y automatizados, que los ciclos de feedback son cortos y que los incidentes se tratan como oportunidades de aprendizaje y no como cacería de culpables.

Las prácticas de DevOps incluyen integración continua, despliegue continuo, infraestructura como código, feature flags, trunk-based development, postmortems sin culpables, y monitoreo y alertas. Ninguna pertenece a un solo equipo: son la cultura operativa de toda la ingeniería.

El modo de fallar más común es crear un "equipo de DevOps". Un equipo llamado DevOps que es dueño del pipeline de CI/CD y del tooling de despliegue mientras los equipos de producto le tiran el código por encima del muro no eliminó el muro: lo reconstruyó con otro nombre. Puede hacer trabajo valioso, pero el rótulo oculta cuál es de verdad su trabajo. La claridad ayuda más que el branding.

SRE: confiabilidad como disciplina de ingeniería

SRE es una implementación concreta de las prácticas de DevOps, creada en Google, que aplica ingeniería de software al trabajo de operaciones. Los SRE escriben código para eliminar trabajo manual, definen objetivos de nivel de servicio (SLOs), administran error budgets y son dueños del proceso que decide cuándo se frena la velocidad de desarrollo de un servicio para proteger su confiabilidad.

Tres mecanismos distinguen a SRE de las operaciones tradicionales:

• Error budgets (presupuesto de error). Un SLO define la confiabilidad aceptable, por ejemplo 99,9% de disponibilidad. El error budget es el margen de caída que implica ese objetivo. Si un servicio se come su error budget, el desarrollo de features nuevas se frena y el trabajo de confiabilidad pasa a tener prioridad. Si el presupuesto está intacto, el equipo puede moverse más rápido con menos cautela. Es un mecanismo basado en datos para equilibrar confiabilidad y velocidad.
• Reducción de toil. Toil es el trabajo operativo manual, repetitivo y automatizable. Se espera que un SRE lo automatice: si una tarea manual se repite, escribe código para eliminarla. El modelo original de Google mantiene el toil por debajo del 50% del tiempo del SRE. Un equipo de SRE que no reduce toil es un equipo de operaciones con mejor nombre.
• Análisis post-incidente. Los SRE corren postmortems estructurados, enfocados en las causas sistémicas y no en culpar a una persona. La salida son acciones concretas que reducen la probabilidad o el impacto de que el incidente se repita.

¿Dónde encaja SRE? En organizaciones con servicios que tienen requisitos de confiabilidad claros y suficiente complejidad como para que la confiabilidad sea un problema de ingeniería de tiempo completo. Un servicio con SLOs estrictos del que dependen millones de usuarios es buen candidato a tener SRE dedicado. Un servicio con exigencias modestas puede estar bien cubierto por su propio equipo de desarrollo siguiendo prácticas de SRE, sin headcount dedicado.

Platform engineering: la plataforma como producto

Platform engineering es la disciplina de construir internal developer platforms (IDP): la infraestructura, el tooling y los golden paths compartidos que los equipos de producto consumen cuando despliegan, operan y observan sus servicios.

Los clientes del equipo de plataforma son internos: los ingenieros de aplicación que necesitan llevar código a producción, los de guardia (on-call) que necesitan diagnosticar incidentes, los nuevos que necesitan volverse productivos rápido. El equipo de plataforma le responde a esos clientes internos igual que un equipo de producto le responde a sus usuarios finales.

Qué entrega un equipo de plataforma: plantillas de CI/CD, tooling de despliegue por golden path, defaults de observabilidad, patrones de manejo de secretos, portales internos para desarrolladores, runbooks y el andamiaje que hace que un servicio nuevo sea desplegable en horas y no en días. Todo eso se trata como producto: diseñado para usuarios, mantenido con cuidado y mejorado con su feedback.

La diferencia crítica frente a SRE: el equipo de plataforma no es dueño de la confiabilidad de un servicio específico. Esa sigue siendo de los equipos de aplicación. La plataforma es dueña del tooling y la infraestructura que hacen que ser dueño de un servicio cueste menos esfuerzo y menos carga mental. Si estás decidiendo entre construir o comprar una de estas plataformas, lo desarrollamos en qué es una internal developer platform.

Cómo se acomodan las tres capas

DevOps es la meta: entrega más rápida y segura mediante desarrollo y operaciones integrados. SRE y platform engineering son dos caminos complementarios para llegar ahí.

SRE resuelve el problema de responsabilidad sobre la confiabilidad: quién responde por la confiabilidad de este servicio, cómo se mide y cómo se hacen explícitos los trade-offs entre confiabilidad y velocidad. Platform engineering resuelve el problema de escala: cómo lograr que las prácticas de DevOps sean consistentes en muchos equipos sin que cada uno reinvente su propia infraestructura.

Una organización puede tener un SRE excelente y un platform engineering pobre: fuerte responsabilidad sobre la confiabilidad de cada servicio, pero tooling de despliegue inconsistente, sin golden paths y con cada equipo rearmando la observabilidad desde cero. También se da el caso inverso: tooling compartido y golden paths excelentes, pero sin SLOs, sin error budgets y sin responsabilidad clara cuando algo se rompe. La mayoría de las empresas a escala real de ingeniería necesitan las dos. Las cuatro métricas DORA aplican a ambas disciplinas; las explicamos para liderazgo en métricas DORA para líderes de ingeniería.

Dónde se solapan y dónde divergen

Se solapan:

• Un equipo de plataforma muchas veces mejora la confiabilidad de los servicios: estandariza defaults de circuit-breaking, hace que el rollback sea rápido y confiable, construye tooling de respuesta a incidentes.
• Los SRE muchas veces aportan al tooling de plataforma: pipelines de observabilidad, plantillas de alertas compartidas, la infraestructura de error budgets.
• A ambas les importan la frecuencia de despliegue, la tasa de fallos por cambio y el tiempo de recuperación: las métricas DORA aplican a las dos.

Divergen:

• A los SRE los llama el pager cuando se cae un servicio. A los platform engineers no los llama la confiabilidad de un servicio de producto: responden por la confiabilidad de la plataforma misma.
• Los SRE tienen responsabilidad directa a nivel de servicio. Los platform engineers tienen responsabilidad ante un cliente interno.
• A los SRE se los mide por cumplimiento de SLOs, ritmo de consumo del error budget y reducción de toil. A los platform engineers se los mide por productividad de los desarrolladores, adopción de la plataforma y reducción de carga cognitiva.

Esa divergencia importa para contratar y para diseñar la organización. Un SRE que no quiere guardia sobre servicios de producto no está siendo difícil: ese es un perfil válido de platform engineering. Un ingeniero de aplicación que quiere ser dueño de la confiabilidad de punta a punta de su servicio no es un perfil de SRE: quiere ingeniería de producto con una cultura de DevOps fuerte.

Qué significa para contratar y diseñar tu organización

La respuesta correcta cambia según la etapa de la empresa.

• Menos de 15 ingenieros. Ningún equipo necesita estos títulos. Lo que necesitas es buena práctica: trunk-based development, despliegue automatizado, responsabilidad compartida sobre los incidentes y retros regulares. Que una persona use los tres sombreros está bien. Los nombres de los sombreros no son el punto.
• 40 a 80 ingenieros, varios equipos de producto. Acá se vuelve visible la inconsistencia de CI/CD entre equipos, el onboarding se alarga y los ingenieros más senior contestan una y otra vez las mismas preguntas de infraestructura. Es la señal de que alguien tiene que ser dueño de la capa de infraestructura compartida. Un equipo de plataforma pequeño, aunque sea una sola persona dedicada, baja la fricción. El SRE en esta etapa suele ser los equipos de aplicación siguiendo la disciplina de SRE, no headcount dedicado.
• 150+ ingenieros. Un equipo de plataforma dedicado suele ser necesario. Si además hace falta SRE dedicado depende de los requisitos de confiabilidad de cada servicio. Las empresas con productos masivos de cara al usuario, o con compromisos contractuales de uptime, tienden a necesitar las dos cosas.

El error más común es contratar a un "DevOps engineer" cuando lo que la empresa necesita es un platform engineer: alguien que construya el producto interno en vez de solo operar infraestructura. El segundo error más común es armar un equipo de SRE antes de que los equipos de aplicación hayan adoptado prácticas de SRE, lo que produce un equipo de confiabilidad que el resto trata como "problema de otro".

Cómo se traduce en un engagement con Clouditive

En Clouditive no vendemos un título de puesto. Ordenamos el trabajo con el Foundations Framework, el método de platform engineering de Mat Caniglia, que organiza cada engagement alrededor de tres principios (las fundaciones antes que los resultados, Cognitive Absorption, y que la medición le gane el ritmo a las herramientas), cinco pilares de capacidad y cinco fases de ciclo de vida (Horizon, Blueprint, Forge, Sustain y Ascend). El principio rector es directo: una plataforma que añade carga cognitiva no es una plataforma. Por eso secuenciamos la infraestructura antes de prometer resultados.

En la práctica eso toma la forma de un Foundations Assessment para mapear dónde estás, la construcción de los golden paths y la IDP que tu equipo va a usar de verdad, un programa de confiabilidad o SRE cuando los servicios lo justifican, y trabajo embebido con tu equipo cuando necesitas capacidad senior adentro. Operamos desde St. Petersburg, Florida, con un hub de entrega nearshore en Punta del Este, Uruguay: mismo huso horario que tus equipos en USA y LATAM, sin la opacidad de un body-shop. Conoce el resto de nuestro enfoque en consultoría de platform engineering y DevOps.

¿Quieres claridad sobre qué capa necesita tu organización antes de contratar? Agenda un Foundations Assessment.