Platform engineering: la siguiente evolucion de DevOps

DevOps cumplio su promesa. Y creo un problema nuevo.

DevOps funciono. Rompio los silos entre desarrollo y operaciones, automatizo despliegues, acelero los ciclos de entrega. Pero en el proceso traslado una cantidad enorme de responsabilidad operativa a los equipos de desarrollo. Y la mayoria de esos equipos no estaban preparados para absorberla.

Un desarrollador de backend en 2015 necesitaba saber escribir codigo, tests y quiza algo de SQL. Un desarrollador de backend en 2025 necesita entender Kubernetes, Terraform, pipelines de CI/CD, politicas de red, gestion de secretos, observabilidad, service meshes, y una docena de herramientas mas. La carga cognitiva se ha multiplicado. Y el resultado es predecible: los equipos pasan mas tiempo peleando con infraestructura que construyendo producto.

Gartner estima que en 2026, el 80% de las organizaciones de ingenieria de software tendran 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.

Que es (y que no es) platform engineering

Platform engineering es la disciplina de disenar 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 documentacion que abstrae la complejidad infraestructural y expone capacidades a traves de interfaces simples. El desarrollador dice “necesito un servicio con una base de datos PostgreSQL y un endpoint publico”, 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 monolitica que nadie quiere usar.
• No es centralizar el control para ralentizar a los equipos.
• No es un portal bonito encima de una infraestructura caaotica.

La diferencia clave es el enfoque de producto. Un equipo de plataforma trata a los desarrolladores como clientes internos. Hace discovery, mide adopcion, 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

Despues de disenar 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 documentacion, y ven el estado de sus despliegues. Backstage (de Spotify, ahora CNCF) es el estandar de facto. No porque sea perfecto (tiene una curva de aprendizaje considerable), sino porque su arquitectura de plugins permite integrarlo con practicamente cualquier stack.

En la practica, el portal es el componente que mas valor visible genera y el que mas riesgo tiene de convertirse en shelfware. La clave es que resuelva problemas reales desde el dia uno: “donde esta la documentacion de este servicio?”, “quien es el owner de este API?”, “como creo un nuevo microservicio?”. Si el portal no responde a estas preguntas mejor que preguntarle a un companero en Slack, fracasara.

2. Golden paths

Un golden path es un camino preconfigurado para realizar una tarea comun. No es el unico camino posible, pero es el camino recomendado, testado y soportado. La metafora de “camino dorado” frente a “camino de tierra” es deliberada: puedes salirte del camino, pero si lo haces, estas solo.

Ejemplos concretos:

• Crear un microservicio: un template que genera un repo con estructura de proyecto, Dockerfile, pipeline CI/CD, configuracion 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.
• Anadir una base de datos: un workflow que provisiona una instancia PostgreSQL o MySQL con backups automaticos, monitoring, y credenciales rotadas en el vault de secretos. Sin tickets, sin esperas.
• Desplegar a produccion: un pipeline que ejecuta tests, analisis de seguridad, validacion de configuracion, y despliegue progresivo (canary o blue-green). El desarrollador hace merge a main y el golden path se encarga del resto.

El error mas comun 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 mas segura de no entregar nada util.

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 traves de abstracciones de alto nivel que ocultan la complejidad.

Un desarrollador no deberia escribir 200 lineas de Terraform para crear un bucket S3 con cifrado, versionado, politicas de acceso y lifecycle rules. Deberia escribir algo como:

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

Y la plataforma traduce eso a los 200 lineas de Terraform con todas las best practices incluidas. Crossplane hace esto nativamente con sus Compositions. Terraform puede lograrlo con modulos bien disenados. El punto es que el desarrollador declara la intencion, no la implementacion.

Esta abstraccion 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 abstraccion, lo solicita y el equipo de plataforma decide si lo incorpora al catalogo o si es una excepcion justificada.

4. Orquestacion de configuracion

La configuracion es el aspecto mas subestimado de platform engineering. Un servicio tipico tiene configuracion de aplicacion, secretos, variables de entorno por entorno (dev, staging, produccion), feature flags, y configuracion de infraestructura. Gestionar todo esto de forma coherente, auditable y segura es un problema que crece exponencialmente con el numero de servicios.

Las soluciones que vemos funcionar:

• Secretos: HashiCorp Vault o AWS Secrets Manager, con rotacion automatica e inyeccion en runtime. Nunca en repos, nunca en variables de entorno estáticas.
• Configuracion de aplicacion: ficheros versionados en git (GitOps) procesados por ArgoCD o Flux. El desarrollador hace un PR con el cambio de configuracion, se revisa, se aprueba, y se aplica automaticamente.
• 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 mas transformadores en la velocidad de entrega.

5. Observabilidad integrada

El ultimo componente es la observabilidad “gratis”. Cada servicio creado a traves de la plataforma viene con metricas, logs y trazas configurados automaticamente. El equipo de plataforma mantiene un stack de observabilidad (Prometheus + Grafana + Loki + Tempo es la combinacion mas comun en entornos mid-market) y los golden paths incluyen la instrumentacion por defecto.

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

Los dashboards tambien son producto de la plataforma. Un dashboard generico por servicio que muestra las cuatro metricas doradas (latencia, trafico, errores, saturacion) 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 esta en el modelo operativo. Y ese modelo es, sin ambiguedad, el de un equipo de producto.

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

Metricas de producto: adopcion voluntaria (porcentaje de equipos que usan la plataforma sin que nadie se lo imponga), tiempo de onboarding (cuanto tarda un nuevo desarrollador en desplegar su primer servicio), lead time (tiempo desde commit hasta produccion), y satisfaccion del desarrollador (encuestas trimestrales, NPS interno).

Roadmap: priorizado por impacto en los equipos, no por lo que sea mas interesante tecnicamente. Si los equipos piden mejor gestion de secrets y tu quieres construir un service mesh, haz la gestion de secrets. La confianza se construye resolviendo los problemas que mas duelen.

Documentacion: tratada como parte del producto. Si algo no esta documentado, no existe. La documentacion de la plataforma es la interfaz mas importante, mas que el portal, mas que los CLIs. Porque cuando un desarrollador se atasca a las 2 de la manana, no va a buscar a un companero: va a buscar en la documentacion.

Un equipo de plataforma para una organizacion de 50-100 desarrolladores suele ser de 3-5 personas. Para 200+, puede crecer a 8-12. Mas alla de eso, conviene dividir en squads con responsabilidades especificas (CI/CD, infraestructura, observabilidad, developer experience).

Dimensionando la inversion: cuando 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 documentacion 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 inflexion. Empiezas a notar que los equipos reinventan la rueda, que la configuracion de infraestructura es inconsistente entre servicios, que el onboarding tarda semanas. Es el momento de empezar con golden paths y un portal basico.

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 inversion se amortiza en meses, no en anos.

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

El ROI tipico que observamos en organizaciones mid-market (50-200 developers) es una reduccion del 40-60% en el tiempo de onboarding de nuevos servicios, una reduccion del 30% en incidentes relacionados con configuracion, y un aumento medible en la satisfaccion del desarrollador. En numeros absolutos, para una organizacion de 100 desarrolladores con un coste medio de 70.000 EUR/ano 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 que les duele. Hemos visto equipos de plataforma que pasaron 6 meses construyendo un sistema de despliegue sofisticado cuando el problema principal era que nadie sabia donde estaban los secretos de produccion.

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 como desplegar, el portal no esta resolviendo nada. Un portal minimo que funcione es infinitamente mejor que uno completo que nadie use.

No medir adopcion. Si no mides cuantos equipos usan tu plataforma voluntariamente, no sabes si estas aportando valor. Hemos visto plataformas “exitosas” segun el equipo que las construyo, pero con una adopcion real del 30%. Si el 70% de tus usuarios potenciales no te usa, no tienes un producto exitoso.

Abstracciones demasiado hermeticas. Ocultar toda la complejidad es tentador, pero cuando algo falla (y fallara), los desarrolladores necesitan poder mirar debajo del capo. Las buenas abstracciones tienen “escape hatches” que permiten acceder a la capa inferior cuando es necesario. La plataforma de Heroku era fantastica hasta que necesitabas algo que no estaba en el menu.

Ignorar la seguridad desde el inicio. La plataforma es el lugar perfecto para implementar security by default: escaneo de imagenes, politicas de red, gestion de secretos, compliance de configuracion. Si la seguridad se anade despues, es una capa de friccion. Si viene incluida en el golden path, es invisible. Hemos ayudado a clientes a reducir hallazgos de auditoria 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 tecnologica que hemos validado:

Componente	Herramienta	Alternativa
Portal	Backstage	Port
IaC	Terraform + modulos 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 mayoria son open source), una comunidad activa, y esta lo suficientemente maduro para produccion. No es la unica opcion valida. Si tu organizacion ya usa Datadog, no cambies a Prometheus por purismo. Si estas en AWS puro, Secrets Manager tiene mas sentido que Vault. La coherencia dentro de tu stack importa mas que elegir la herramienta “perfecta” en cada categoria.

Como empezar manana

Si estas considerando platform engineering para tu organizacion, este es el plan de 90 dias que recomendamos:

Semanas 1-2: discovery. Entrevista a 5-8 desarrolladores de equipos diferentes. Pregunta: que te frustra mas del proceso de desarrollo y despliegue? Cuanto tiempo dedicas a tareas que no son escribir codigo de producto? Si pudieras cambiar una sola cosa, cual seria? Las respuestas van a sorprenderte. Siempre sorprenden.

Semanas 3-4: primer golden path. Elige el problema mas mencionado en las entrevistas y construye un golden path minimo que lo resuelva. Tipicamente es “crear un nuevo servicio” o “desplegar a produccion”. No uses Backstage todavia. 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 solucion resuelve el problema real o el problema que tu creias que existia.

Semanas 9-12: escala incremental. Si el piloto funciona, extiende a 2-3 equipos mas. Empieza a montar el portal (ahora si, Backstage o Port). Anade el segundo golden path. Mide adopcion. Presenta resultados a liderazgo con numeros concretos: tiempo ahorrado, incidentes evitados, satisfaccion del equipo piloto.

Este enfoque incremental es radicalmente diferente del “gran proyecto de plataforma” de 12 meses que hemos visto fracasar multiples veces. Entrega valor pronto, itera rapido, y deja que la adopcion guie las prioridades.

El futuro inmediato: IA en la plataforma

El proximo salto en platform engineering es la integracion de agentes de IA en las plataformas internas. No hablamos de chatbots que responden preguntas sobre la documentacion (aunque eso tambien tiene valor). Hablamos de agentes que pueden ejecutar tareas operativas.

Un desarrollador dice “necesito escalar el servicio de pagos a 10 replicas durante el Black Friday” y un agente de la plataforma valida la solicitud contra las politicas, verifica que hay capacidad, genera el cambio de configuracion, abre un PR, y lo asigna al reviewer apropiado. El desarrollador aprueba el PR y el cambio se aplica.

Esto no es ciencia ficcion. Los componentes tecnicos existen. Lo que falta es la integracion: 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 produccion a cero replicas por un error de interpretacion.

Estamos trabajando con clientes en prototipos de esta integracion, y los resultados iniciales son prometedores. El tiempo de operaciones rutinarias se reduce en un 50-70%, y los errores de configuracion (que son la primera causa de incidentes en la mayoria de organizaciones) bajan drasticamente porque el agente aplica las politicas automaticamente.

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.