DevOps, SRE y Ingeniería de Plataforma: cuál es la diferencia.
Los tres aparecen en la misma vacante, en la misma propuesta y en la misma diapositiva. Resuelven problemas distintos, y confundir uno con otro cuesta un equipo entero haciendo lo equivocado con competencia.
La respuesta corta.
DevOps es una forma de trabajar. SRE es una disciplina de ingeniería con un número en el medio. La Ingeniería de Plataforma es un producto interno. Uno dice cómo entrega el equipo, otro dice cuánta falla es aceptable, el tercero dice qué ya no tiene que construir el equipo por su cuenta.
La confusión tiene una causa concreta: las tres cosas usan las mismas herramientas. Pipeline, contenedor, infraestructura como código y monitoreo aparecen en las tres. Pero herramienta igual no quiere decir problema igual, y la pregunta que las separa no es "qué herramienta usa": es "qué se le exige mejorar a esa persona".
Los tres, uno por uno.
Cómo entrega el equipo
AWS define DevOps como la combinación de filosofías culturales, prácticas y herramientas que aumenta la capacidad de una organización de entregar aplicaciones y servicios a alta velocidad. El punto central es derribar el muro entre quien desarrolla y quien opera.
Prácticas nombradas: integración continua, entrega continua, microservicios, infraestructura como código, monitoreo y registro, y comunicación entre equipos.
Se le exige: el tiempo entre escribir el código y tenerlo en producción, y cuánto de eso es automático.
Cuánta falla es aceptable
El libro de Google resume el origen en una frase: SRE es lo que pasa cuando le pides a una persona que hace ingeniería de software que diseñe un equipo de operaciones. No es operación con nombre nuevo: es operación escrita como software.
Dos reglas concretas: Google limita en 50% el trabajo operativo agregado de quien hace SRE, y trata el 100% como el objetivo de confiabilidad equivocado para prácticamente todo.
Se le exige: que el sistema se mantenga dentro del objetivo de disponibilidad acordado, y que el presupuesto de error se gaste a propósito.
Lo que nadie tiene que rehacer
La CNCF define una plataforma para computación nativa en la nube como una colección integrada de capacidades, definida y presentada según las necesidades de quien la usa. La cita que la propia CNCF adopta describe el resultado: una base de APIs de autoservicio, herramientas, servicios, conocimiento y soporte, organizada como un producto interno.
Los atributos que nombra incluyen plataforma como producto, autoservicio, documentación y incorporación de personas nuevas, menor carga cognitiva, oferta opcional y componible, y seguridad por defecto.
Se le exige: la adopción interna. Una plataforma que los equipos esquivan es un costo, no un producto.
Lado a lado.
| Pregunta | DevOps | SRE | Plataforma |
|---|---|---|---|
| Qué es | Cultura, prácticas y herramientas | Disciplina de ingeniería | Producto interno |
| Unidad de medida | Frecuencia y tiempo de entrega | Objetivo de disponibilidad y presupuesto de error | Adopción por los equipos internos |
| Cuándo entra | Desde el primer despliegue | Cuando la caída cuesta dinero | Cuando varios equipos repiten el mismo trabajo |
| Señal de que salió mal | Se volvió el nombre del equipo que cuida el pipeline | Se volvió guardia sin objetivo escrito | Los equipos esquivan la plataforma |
Cuál de los tres necesita tu empresa ahora.
Tres preguntas, en orden. La primera que respondas "no" es donde está tu problema.
¿Una corrección de una línea llega a producción el mismo día?
Si no, el problema es DevOps y ninguna contratación de SRE lo resuelve. Pipeline, pruebas automatizadas y infraestructura como código van antes de cualquier discusión sobre confiabilidad.
¿Sabes decir, en número, cuánto puede estar caído el sistema al mes?
Si no, el problema es SRE, y empieza por escribir el objetivo, no por contratar a alguien. Sin objetivo no existe presupuesto de error, y sin presupuesto de error la prioridad entre lanzar y estabilizar se vuelve una discusión de opiniones.
¿Equipos distintos están resolviendo el mismo problema de infraestructura de maneras distintas?
Si sí, y si son varios equipos, ahí tiene sentido la plataforma. Con un solo equipo, una plataforma interna es un producto con un usuario: costo de mantenimiento sin ganancia de escala.
El error que más encontramos.
La empresa contrata plataforma antes de tener DevOps. El resultado es siempre el mismo: un portal interno bonito encima de un proceso de entrega manual. Los equipos siguen abriendo tickets, ahora con una pantalla en el medio, y la plataforma se vuelve una cosa más que mantener.
El segundo más común: llamarle SRE a la guardia que ya existía. Cambia la tarjeta de presentación y no cambia el trabajo, porque no existe un objetivo de disponibilidad escrito, nadie derivó ningún presupuesto de error, y el límite de la mitad del tiempo en trabajo operativo que usa Google nunca se aplicó. La persona apaga incendios con un título mejor.
El orden que funciona es el más aburrido: automatiza la entrega, escribe el objetivo de disponibilidad, mide, y solo después construye un camino listo para lo que ya se repite. Cada una de esas etapas se paga sola, que es exactamente el argumento para no saltarse ninguna.
Preguntas sobre DevOps, SRE y plataforma.
¿Cuál es la diferencia entre DevOps y SRE?
DevOps es una combinación de cultura, prácticas y herramientas para entregar software con velocidad, derribando el muro entre desarrollo y operación. SRE es una disciplina de ingeniería que le pone un número a eso: define un objetivo de disponibilidad, deriva de él un presupuesto de error y usa ese presupuesto para decidir cuándo lanzar y cuándo parar. DevOps dice cómo trabajar; SRE dice cuánta falla es aceptable y qué hacer cuando el límite se pasa.
¿Qué es el presupuesto de error?
Es lo opuesto del objetivo de disponibilidad. El libro de SRE de Google define el presupuesto de error como uno menos el objetivo de disponibilidad: un objetivo de 99,99% deja 0,01% de indisponibilidad para gastar en el período medido. Mientras quede presupuesto, el equipo lanza. Cuando el presupuesto se acaba, la prioridad pasa a ser la confiabilidad hasta que se recomponga.
¿Por qué 100% de disponibilidad es el objetivo equivocado?
Porque Google escribe exactamente eso: 100% es el objetivo de confiabilidad equivocado para prácticamente todo. Cada nueve adicional cuesta mucho más caro que el anterior, y a partir de cierto punto el usuario no nota la diferencia, porque su red, su teléfono y su proveedor ya fallan más que tu sistema.
¿Qué es la Ingeniería de Plataforma?
Es tratar la infraestructura interna como un producto. La CNCF define una plataforma para computación nativa en la nube como una colección integrada de capacidades, definida y presentada según las necesidades de quien la usa. En la práctica: autoservicio, documentación, caminos listos y menor carga cognitiva para quien desarrolla.
¿Mi empresa necesita los tres?
Casi nunca al mismo tiempo. DevOps va primero porque es práctica de trabajo y no exige un equipo nuevo. SRE entra cuando hay algo en producción cuya caída cuesta dinero y alguien tiene que responder por eso con un número. La plataforma entra cuando hay suficientes equipos repitiendo el mismo trabajo de infraestructura como para que valga la pena construir el camino listo una vez.
¿Se puede contratar SRE sin tener un objetivo de disponibilidad definido?
Se puede contratar a la persona, pero se vuelve una guardia con nombre nuevo. Sin objetivo de disponibilidad no existe presupuesto de error, sin presupuesto de error no existe criterio para priorizar confiabilidad frente a funcionalidad, y la disciplina entera se vuelve apagar incendios. El objetivo va antes de la contratación.
¿No sabes en cuál de las tres estás trabado?
El diagnóstico lo responde con evidencia: dónde se detiene la entrega, cuánto se cae el sistema, y qué se repite lo suficiente como para volverse un camino listo. Dos semanas, un documento, una cotización cerrada.
Fuentes
Las definiciones y los dos números citados —el límite de 50% y el presupuesto de error— vienen de estas tres fuentes primarias, abiertas el 9 de agosto de 2026.