🏷️ Etiquetas: Platform Engineering, DevOps, SRE, Roles Técnicos, IDP, Developer Experience, Golden Path, Self-Service, Cultura DevOps, Toil Reduction
Platform Engineering vs DevOps vs SRE: Aclarando el Caos de Roles
La industria tech está inundada de términos confusos: DevOps, SRE, Platform Engineering. Empresas creando equipos sin entender la diferencia. Este post aclara qué es cada uno, cuándo necesitas cada rol, y por qué no son excluyentes sino complementarios.
DevOps: Cultura y Prácticas, No un Rol
DevOps nació como cultura: romper silos entre desarrollo y operaciones. Principios: automatización, CI/CD, colaboración, feedback rápido, shift-left en seguridad y calidad. El error más común: crear un ‘equipo DevOps’ que hace deploys. Eso no es DevOps, es Ops rebautizado. DevOps es que developers puedan desplegar sin tickets a Ops. Es Infrastructure as Code, observabilidad compartida, responsabilidad end-to-end.
Si tienes un equipo llamado ‘DevOps’ que es cuello de botella para deploys, no estás haciendo DevOps. Estás haciendo Ops con mejor nombre.
SRE: Operaciones Como Ingeniería
Site Reliability Engineering (Google, 2003): Aplicar principios de ingeniería de software a operaciones. Conceptos clave: SLOs (Service Level Objectives), Error Budgets (presupuesto de fallos permitidos), Toil Reduction (automatizar trabajo manual repetitivo), Blameless Postmortems, Capacity Planning. SRE no es ‘DevOps de Google’. Es una implementación específica con foco en fiabilidad medible. SREs escriben código: automatización, tooling, self-healing systems.
SRE es DevOps con métricas de fiabilidad como ciudadanos de primera clase. Si no tienes SLOs y error budgets, no estás haciendo SRE.
Platform Engineering: Golden Paths y Self-Service
Platform Engineering (tendencia 2023-2026): Construir Internal Developer Platforms (IDP) que habilitan self-service. Golden Paths: caminos predefinidos y recomendados para hacer cosas comunes (desplegar app, crear base datos, exponer API). Objetivo: reducir cognitive load de developers, acelerar delivery, mantener estándares. Ejemplos: Backstage (Spotify), Humanitec, Kratix. Platform Team construye y mantiene la plataforma. Product Teams la consumen.
Platform Engineering no reemplaza DevOps ni SRE. Es la evolución natural: en vez de que cada equipo construya su tooling, la plataforma lo proporciona.
Cuándo Necesitas Cada Uno
DevOps (Cultura): SIEMPRE. Es el fundamento. Si no tienes cultura DevOps, nada más funcionará. | SRE: Cuando fiabilidad es crítica y cuantificable. Servicios 24/7, alta disponibilidad, SLAs estrictos. Típico: fintech, e-commerce, SaaS. | Platform Engineering: Cuando tienes múltiples equipos construyendo servicios similares. Necesitas estandarización con autonomía. Típico: >50 developers, >10 equipos, microservicios.
Pequeñas startups: DevOps cultura + automatización básica. Scaleups: Añadir SRE para servicios críticos. Empresas grandes: Platform Engineering para escalar sin caos.
Antipatrones Comunes
‘Equipo DevOps’ que bloquea deploys: DevOps es cultura, no equipo. Si el equipo DevOps es cuello de botella, has fallado. | ‘SRE como Ops glorificado’: SRE sin SLOs, sin error budgets, sin toil reduction es solo Ops con título fancy. | ‘Plataforma que nadie usa’: Construir IDP sin hablar con developers. Resultado: plataforma hermosa que nadie adopta porque no resuelve problemas reales. | ‘Golden Path que es Golden Cage’: Plataforma tan rígida que developers la evitan y construyen workarounds.
Todos estos antipatrones tienen un denominador común: implementar la forma sin entender el fondo.
Cómo Evolucionar: De DevOps a Platform Engineering
Fase 1 – DevOps Básico: CI/CD, IaC, containerización. Cada equipo construye su tooling. | Fase 2 – Estandarización: Identificar patrones comunes. Crear templates, scripts compartidos, documentación. | Fase 3 – Self-Service Inicial: Portal interno donde equipos pueden provisionar recursos sin tickets. AWS Service Catalog, Terraform modules. | Fase 4 – IDP Completo: Backstage, catálogo de servicios, golden paths, observabilidad integrada, gestión de secretos, compliance automatizado. | Fase 5 – Platform as Product: Platform team trata la plataforma como producto. Roadmap, métricas de adopción, soporte, documentación como código.
No intentes saltar directamente a Fase 5. Es evolutivo, no revolucionario.
El Rol del Arquitecto en Cada Modelo
En DevOps: Define principios y patrones arquitectónicos. Asegura que autonomía no genere caos. | En SRE: Colabora en definición de SLOs. Diseña arquitecturas para fiabilidad (circuit breakers, bulkheads, graceful degradation). | En Platform Engineering: Define arquitectura de referencia. Asegura que golden paths sigan principios arquitectónicos. Evita que plataforma se convierta en monolito.
El arquitecto no desaparece. Evoluciona de dictar soluciones a habilitar decisiones correctas.
Conclusión
DevOps, SRE y Platform Engineering no son competidores. Son capas complementarias. DevOps es la cultura base. SRE añade disciplina de fiabilidad. Platform Engineering escala ambos mediante self-service. El error es pensar que son excluyentes. El acierto es adoptarlos progresivamente según tu madurez organizacional.
¿Te ha resultado útil este contenido? Conecta conmigo en LinkedIn para más insights sobre arquitectura empresarial.