Platform engineering: la siguiente evolución de DevOps

DevOps cumplió su promesa. Y creó un problema nuevo.

DevOps funcionó. Rompió los silos entre desarrollo y operaciones, automatizó despliegues, aceleró los ciclos de entrega. Pero en el proceso trasladó una cantidad enorme de responsabilidad operativa a los equipos de desarrollo. Y la mayoría de esos equipos no estaban preparados para absorberla.

Un desarrollador de backend en 2015 necesitaba saber escribir código, tests y quizá algo de SQL. Un desarrollador de backend en 2025 necesita entender Kubernetes, Terraform, pipelines de CI/CD, políticas de red, gestión de secretos, observabilidad, service meshes, y una docena de herramientas más. La carga cognitiva se ha multiplicado. Y el resultado es predecible: los equipos pasan más tiempo peleando con infraestructura que construyendo producto.

Gartner estima que en 2026, el 80% de las organizaciones de ingeniería de software tendrán equipos de plataforma. No porque sea la moda, sino porque el modelo actual no escala. Cuando tienes 5 desarrolladores, cada uno puede configurar su propia infraestructura. Cuando tienes 50, necesitas estandarizar. Cuando tienes 200, necesitas una plataforma.

Qué es (y qué no es) platform engineering

Platform engineering es la disciplina de diseñar y construir toolchains y workflows de autoservicio que permitan a los equipos de desarrollo entregar software sin depender de tickets a operaciones ni convertirse en expertos en infraestructura.

El producto de un equipo de plataforma es una Internal Developer Platform (IDP): un conjunto de herramientas, APIs, templates y documentación que abstrae la complejidad infraestructural y expone capacidades a través de interfaces simples. El desarrollador dice “necesito un servicio con una base de datos PostgreSQL y un endpoint público”, y la plataforma lo provisiona con todas las configuraciones de seguridad, networking, observabilidad y compliance incluidas.

Lo que platform engineering no es:

• No es renombrar al equipo de operaciones como “equipo de plataforma”.
• No es construir una herramienta interna monolítica que nadie quiere usar.
• No es centralizar el control para ralentizar a los equipos.
• No es un portal bonito encima de una infraestructura caótica.

La diferencia clave es el enfoque de producto. Un equipo de plataforma trata a los desarrolladores como clientes internos. Hace discovery, mide adopción, itera sobre feedback, y depreca lo que no funciona. Si nadie usa tu plataforma voluntariamente, no tienes una plataforma. Tienes un mandato que los equipos esquivan con workarounds.

Los cinco componentes de una IDP

Después de diseñar y operar plataformas internas para empresas de entre 40 y 300 ingenieros, hemos identificado cinco componentes que aparecen en toda IDP funcional.

1. Portal de desarrollador

El punto de entrada. Un portal web donde los desarrolladores descubren servicios disponibles, crean nuevos proyectos, consultan documentación, y ven el estado de sus despliegues. Backstage (de Spotify, ahora CNCF) es el estándar de facto. No porque sea perfecto (tiene una curva de aprendizaje considerable), sino porque su arquitectura de plugins permite integrarlo con prácticamente cualquier stack.

En la práctica, el portal es el componente que más valor visible genera y el que más riesgo tiene de convertirse en shelfware. La clave es que resuelva problemas reales desde el día uno: “dónde está la documentación de este servicio?”, “quién es el owner de este API?”, “cómo creo un nuevo microservicio?”. Si el portal no responde a estas preguntas mejor que preguntarle a un compañero en Slack, fracasará.

2. Golden paths

Un golden path es un camino preconfigurado para realizar una tarea común. No es el único camino posible, pero es el camino recomendado, testado y soportado. La metáfora de “camino dorado” frente a “camino de tierra” es deliberada: puedes salirte del camino, pero si lo haces, estás solo.

Ejemplos concretos:

• Crear un microservicio: un template que genera un repo con estructura de proyecto, Dockerfile, pipeline CI/CD, configuración de observabilidad, y manifiesto de Kubernetes. El desarrollador ejecuta un comando, responde cuatro preguntas (nombre, lenguaje, necesita base de datos, necesita cola), y tiene un servicio desplegable en 15 minutos.
• Añadir una base de datos: un workflow que provisiona una instancia PostgreSQL o MySQL con backups automáticos, monitoring, y credenciales rotadas en el vault de secretos. Sin tickets, sin esperas.
• Desplegar a producción: un pipeline que ejecuta tests, análisis de seguridad, validación de configuración, y despliegue progresivo (canary o blue-green). El desarrollador hace merge a main y el golden path se encarga del resto.

El error más común con los golden paths es intentar cubrir el 100% de los casos de uso. Cubre el 80%. El 20% restante son excepciones que el equipo de plataforma atiende manualmente o que requieren paths especializados. Intentar automatizar todo desde el principio es la forma más segura de no entregar nada útil.

3. Infrastructure as Code con abstracciones

El tercer componente es la capa que realmente provisiona recursos. Terraform, Pulumi o Crossplane por debajo, pero expuestos a través de abstracciones de alto nivel que ocultan la complejidad.

Un desarrollador no debería escribir 200 líneas de Terraform para crear un bucket S3 con cifrado, versionado, políticas de acceso y lifecycle rules. Debería escribir algo como:

kind: StorageBucket
metadata:
  name: user-uploads
spec:
  access: private
  retention: 90d
  encryption: true

Y la plataforma traduce eso a los 200 líneas de Terraform con todas las best practices incluidas. Crossplane hace esto nativamente con sus Compositions. Terraform puede lograrlo con módulos bien diseñados. El punto es que el desarrollador declara la intención, no la implementación.

Esta abstracción tiene un coste: flexibilidad. Y eso es exactamente lo que quieres. Limitar las opciones reduce la superficie de error, facilita el mantenimiento y permite al equipo de plataforma garantizar compliance y seguridad. Si un equipo necesita algo fuera de la abstracción, lo solicita y el equipo de plataforma decide si lo incorpora al catálogo o si es una excepción justificada.

4. Orquestación de configuración

La configuración es el aspecto más subestimado de platform engineering. Un servicio típico tiene configuración de aplicación, secretos, variables de entorno por entorno (dev, staging, producción), feature flags, y configuración de infraestructura. Gestionar todo esto de forma coherente, auditable y segura es un problema que crece exponencialmente con el número de servicios.

Las soluciones que vemos funcionar:

• Secretos: HashiCorp Vault o AWS Secrets Manager, con rotación automática e inyección en runtime. Nunca en repos, nunca en variables de entorno estáticas.
• Configuración de aplicación: ficheros versionados en git (GitOps) procesados por ArgoCD o Flux. El desarrollador hace un PR con el cambio de configuración, se revisa, se aprueba, y se aplica automáticamente.
• Feature flags: un sistema centralizado (LaunchDarkly, Unleash, Flagsmith) que permite activar y desactivar funcionalidades sin redesplegar. Esto desacopla el despliegue del release, que es uno de los cambios más transformadores en la velocidad de entrega.

5. Observabilidad integrada

El último componente es la observabilidad “gratis”. Cada servicio creado a través de la plataforma viene con métricas, logs y trazas configurados automáticamente. El equipo de plataforma mantiene un stack de observabilidad (Prometheus + Grafana + Loki + Tempo es la combinación más común en entornos mid-market) y los golden paths incluyen la instrumentación por defecto.

Esto elimina uno de los problemas más persistentes que vemos: equipos que no implementan observabilidad porque “no tienen tiempo”. Si la observabilidad es el default, no hay decisión que tomar. El servicio nace observable.

Los dashboards también son producto de la plataforma. Un dashboard genérico por servicio que muestra las cuatro métricas doradas (latencia, tráfico, errores, saturación) cubre el 80% de las necesidades operativas. Los equipos pueden customizarlos, pero parten de una base funcional.

El modelo operativo: equipo de plataforma como equipo de producto

La diferencia entre un equipo de plataforma que funciona y uno que se convierte en un cuello de botella está en el modelo operativo. Y ese modelo es, sin ambigüedad, el de un equipo de producto.

Usuarios: los desarrolladores de la organización. No todos. Empieza con un equipo piloto, recoge feedback, itera, y escala.

Métricas de producto: adopción voluntaria (porcentaje de equipos que usan la plataforma sin que nadie se lo imponga), tiempo de onboarding (cuánto tarda un nuevo desarrollador en desplegar su primer servicio), lead time (tiempo desde commit hasta producción), y satisfacción del desarrollador (encuestas trimestrales, NPS interno).

Roadmap: priorizado por impacto en los equipos, no por lo que sea más interesante técnicamente. Si los equipos piden mejor gestión de secrets y tú quieres construir un service mesh, haz la gestión de secrets. La confianza se construye resolviendo los problemas que más duelen.

Documentación: tratada como parte del producto. Si algo no está documentado, no existe. La documentación de la plataforma es la interfaz más importante, más que el portal, más que los CLIs. Porque cuando un desarrollador se atasca a las 2 de la mañana, no va a buscar a un compañero: va a buscar en la documentación.

Un equipo de plataforma para una organización de 50-100 desarrolladores suele ser de 3-5 personas. Para 200+, puede crecer a 8-12. Más allá de eso, conviene dividir en squads con responsabilidades específicas (CI/CD, infraestructura, observabilidad, developer experience).

Dimensionando la inversión: cuándo tiene sentido

No todas las organizaciones necesitan platform engineering. Y empezar demasiado pronto es tan perjudicial como empezar demasiado tarde.

Menos de 20 desarrolladores: probablemente no necesitas una plataforma formal. Un buen conjunto de scripts, templates y documentación mantenido por un SRE o un devops engineer senior es suficiente. La sobrecarga de construir y mantener una IDP no se justifica.

20-50 desarrolladores: el punto de inflexión. Empiezas a notar que los equipos reinventan la rueda, que la configuración de infraestructura es inconsistente entre servicios, que el onboarding tarda semanas. Es el momento de empezar con golden paths y un portal básico.

50-200 desarrolladores: platform engineering es casi obligatorio. Sin una plataforma, la velocidad de entrega se degrada, los incidentes aumentan por inconsistencia, y los mejores ingenieros se frustran con la complejidad operativa. La inversión se amortiza en meses, no en años.

200+ desarrolladores: la plataforma es infraestructura crítica, tan importante como el producto que vende la empresa.

El ROI típico que observamos en organizaciones mid-market (50-200 developers) es una reducción del 40-60% en el tiempo de onboarding de nuevos servicios, una reducción del 30% en incidentes relacionados con configuración, y un aumento medible en la satisfacción del desarrollador. En números absolutos, para una organización de 100 desarrolladores con un coste medio de 70.000 EUR/año por ingeniero, recuperar un 10% de tiempo productivo equivale a 700.000 EUR anuales. Un equipo de plataforma de 4 personas cuesta considerablemente menos.

Errores que hemos visto (y cometido)

Construir antes de entender. El primer impulso es empezar a construir herramientas. El primer paso correcto es sentarse con los equipos y entender qué les duele. Hemos visto equipos de plataforma que pasaron 6 meses construyendo un sistema de despliegue sofisticado cuando el problema principal era que nadie sabía dónde estaban los secretos de producción.

El portal como proyecto de prestigio. Backstage es atractivo. Tiene plugins, tiene una comunidad activa, queda bien en una demo. Pero si tu portal tiene 15 plugins y los desarrolladores siguen preguntando en Slack cómo desplegar, el portal no está resolviendo nada. Un portal mínimo que funcione es infinitamente mejor que uno completo que nadie use.

No medir adopción. Si no mides cuántos equipos usan tu plataforma voluntariamente, no sabes si estás aportando valor. Hemos visto plataformas “exitosas” según el equipo que las construyó, pero con una adopción real del 30%. Si el 70% de tus usuarios potenciales no te usa, no tienes un producto exitoso.

Abstracciones demasiado herméticas. Ocultar toda la complejidad es tentador, pero cuando algo falla (y fallará), los desarrolladores necesitan poder mirar debajo del capó. Las buenas abstracciones tienen “escape hatches” que permiten acceder a la capa inferior cuando es necesario. La plataforma de Heroku era fantástica hasta que necesitabas algo que no estaba en el menú.

Ignorar la seguridad desde el inicio. La plataforma es el lugar perfecto para implementar security by default: escaneo de imágenes, políticas de red, gestión de secretos, compliance de configuración. Si la seguridad se añade después, es una capa de fricción. Si viene incluida en el golden path, es invisible. Hemos ayudado a clientes a reducir hallazgos de auditoría en un 70% simplemente moviendo controles de seguridad al nivel de plataforma.

El stack que recomendamos para mid-market

Para organizaciones de 50-200 ingenieros que no quieren construir todo desde cero, esta es la pila tecnológica que hemos validado:

Componente	Herramienta	Alternativa
Portal	Backstage	Port
IaC	Terraform + módulos internos	Crossplane
GitOps	ArgoCD	Flux
CI/CD	GitHub Actions	GitLab CI
Secretos	HashiCorp Vault	AWS Secrets Manager
Observabilidad	Prometheus + Grafana + Loki	Datadog
Feature flags	Unleash	LaunchDarkly
Templates	Backstage scaffolder	Cookiecutter + CLI
Policy	OPA/Gatekeeper	Kyverno
Service catalog	Backstage catalog	Port catalog

Este stack tiene un coste operativo asumible (la mayoría son open source), una comunidad activa, y está lo suficientemente maduro para producción. No es la única opción válida. Si tu organización ya usa Datadog, no cambies a Prometheus por purismo. Si estás en AWS puro, Secrets Manager tiene más sentido que Vault. La coherencia dentro de tu stack importa más que elegir la herramienta “perfecta” en cada categoría.

Cómo empezar mañana

Si estás considerando platform engineering para tu organización, este es el plan de 90 días que recomendamos:

Semanas 1-2: discovery. Entrevista a 5-8 desarrolladores de equipos diferentes. Pregunta: qué te frustra más del proceso de desarrollo y despliegue? Cuánto tiempo dedicas a tareas que no son escribir código de producto? Si pudieras cambiar una sola cosa, cuál sería? Las respuestas van a sorprenderte. Siempre sorprenden.

Semanas 3-4: primer golden path. Elige el problema más mencionado en las entrevistas y construye un golden path mínimo que lo resuelva. Típicamente es “crear un nuevo servicio” o “desplegar a producción”. No uses Backstage todavía. Un script bien documentado es suficiente.

Semanas 5-8: piloto con un equipo. Pon el golden path en manos de un equipo real. Observa como lo usan. Recoge feedback semanalmente. Itera. Esta fase es la que te va a decir si tu solución resuelve el problema real o el problema que tú creías que existía.

Semanas 9-12: escala incremental. Si el piloto funciona, extiende a 2-3 equipos más. Empieza a montar el portal (ahora sí, Backstage o Port). Añade el segundo golden path. Mide adopción. Presenta resultados a liderazgo con números concretos: tiempo ahorrado, incidentes evitados, satisfacción del equipo piloto.

Este enfoque incremental es radicalmente diferente del “gran proyecto de plataforma” de 12 meses que hemos visto fracasar múltiples veces. Entrega valor pronto, itera rápido, y deja que la adopción guíe las prioridades.

El futuro inmediato: IA en la plataforma

El próximo salto en platform engineering es la integración de agentes de IA en las plataformas internas. No hablamos de chatbots que responden preguntas sobre la documentación (aunque eso también tiene valor). Hablamos de agentes que pueden ejecutar tareas operativas.

Un desarrollador dice “necesito escalar el servicio de pagos a 10 réplicas durante el Black Friday” y un agente de la plataforma valida la solicitud contra las políticas, verifica que hay capacidad, genera el cambio de configuración, abre un PR, y lo asigna al reviewer apropiado. El desarrollador aprueba el PR y el cambio se aplica.

Esto no es ciencia ficción. Los componentes técnicos existen. Lo que falta es la integración: conectar los modelos de lenguaje con las APIs de la plataforma, definir los guardrails de seguridad, y construir la confianza de los equipos en que el agente no va a escalar producción a cero réplicas por un error de interpretación.

Estamos trabajando con clientes en prototipos de esta integración, y los resultados iniciales son prometedores. El tiempo de operaciones rutinarias se reduce en un 50-70%, y los errores de configuración (que son la primera causa de incidentes en la mayoría de organizaciones) bajan drásticamente porque el agente aplica las políticas automáticamente.

Platform engineering es, en esencia, un problema de experiencia de desarrollador y eficiencia operativa. Resolver ese problema no solo acelera la entrega de software: libera a los ingenieros para que hagan lo que realmente saben hacer. Construir producto.