Una plataforma es un producto, no un wiki de enlaces
Una Internal Developer Platform (IDP) reúne herramientas, plantillas y documentación en una única interfaz self-service. La palabra clave es producto: tiene un owner, usuarios — los desarrolladores — y una métrica de éxito: la velocidad con la que un ingeniero lleva una idea a producción. Un portal que nadie gestiona como producto muere en medio año — volveré sobre esto.
El dolor central que elimina una IDP es la carga cognitiva. Hoy un desarrollador de un solo microservicio debe tener en la cabeza, a la vez, manifiestos de Kubernetes, Terraform, ArgoCD, políticas de Vault, reglas de Prometheus y políticas de Kyverno. La plataforma oculta todo eso tras el self-service: pulsa un botón, obtén un entorno.
Por qué ahora: tres impulsores
1. DevOps sin estructura no escala. El modelo «cada equipo es su propio DevOps» funciona con tres equipos y se rompe con treinta: cada uno arma su propio zoológico de herramientas y la organización se ahoga en la fragmentación. Una plataforma restaura la consistencia sin matar la autonomía.
2. El código de IA supera a la governance. Los agentes y Copilot escriben código más rápido de lo que el code review manual puede validarlo. La única respuesta escalable es trasladar el control a guardrails automatizados: policy-as-code como admission control, en lugar de un revisor humano como cuello de botella.
3. La carga cognitiva se ha vuelto insostenible. Esto se deriva de los dos primeros: cuantas más herramientas y más rápido el flujo de cambios, más caro es tenerlo todo en la cabeza. Una IDP devuelve al desarrollador el foco en su propio servicio.
Según CNCF, el 28 % de las organizaciones ya tiene un equipo de plataforma; Gartner pronostica el 80 % de las grandes empresas para finales de 2026. No es hype — es una respuesta estructural a la complejidad.
El stack canónico de seis capas
Una plataforma funcional sobre Kubernetes se compone de seis capas. Me ciño a los defaults CNCF-native — no porque sean la única opción correcta, sino porque encajan: las herramientas están hechas para trabajar juntas.
- 1. Developer Portal — Backstage: UI unificada, catálogo, scaffolder.
- 2. GitOps & Deployment — ArgoCD o Flux: entrega declarativa.
- 3. Infrastructure Provisioning — Crossplane: infraestructura como recursos de K8s.
- 4. Policy & Security — Kyverno y Trivy: guardrails y escaneo.
- 5. Observability — Prometheus, Grafana, OpenTelemetry.
- 6. AI / DevEx — todavía emergente: asistentes y triaje de incidentes con IA.
Seis capas son el mínimo. Las plataformas maduras añaden servicios admin-API propios y triaje asistido por IA. Pero sin las primeras seis, la superestructura no tiene sentido. Una salvedad importante: un portal sin golden paths ni motor de políticas es un catálogo sin contenido. Un Backstage desnudo no aporta valor; el valor está en las plantillas que entregan, con un botón, un repositorio con CI/CD, observability y baseline de seguridad — y en las políticas que impiden que ese baseline se degrade.
Los tres pilares del portal
- Software Catalog — una única fuente de verdad: servicios, owners, dependencias, runbooks, enlaces a dashboards. No una hoja de cálculo a mano, sino discovery automático.
- Scaffolder — golden paths como código: botón → repositorio listo con pipeline, monitorización y baseline de seguridad.
- TechDocs — docs-as-code desde los repositorios de servicios con búsqueda unificada.
Qué medir
Una platform-as-a-product exige métricas de producto:
- Time-to-first-deploy — desde crear el repositorio hasta producción (objetivo: menos de un día).
- Self-service ratio — la proporción de tareas resueltas sin recurrir al equipo de plataforma.
- Template adoption — la proporción de servicios nuevos creados con el scaffolder.
- Internal NPS — una encuesta a desarrolladores cada trimestre.
Si la adopción sube mientras el NPS baja, has construido coerción, no una plataforma.
Cuatro maneras de matar una IDP
- Un portal sin owner-team — nadie lo evoluciona, muere en medio año.
- Un scaffolder sin post-create automation — generó boilerplate pero nunca cableó CI, secretos y monitorización; el desarrollador acaba igualmente en la puerta del equipo de plataforma.
- Un catálogo como hoja de cálculo a mano — sin discovery automático queda obsoleto el día que se crea.
- Adopción forzada — una plataforma debe ser el mejor camino, no el único.
Conclusión
Una IDP es una inversión en velocidad y consistencia que solo rinde con mentalidad de producto: un owner, métricas y un camino que se elige voluntariamente. Las seis capas dan el marco; los tres impulsores explican por qué demorar sale caro; los cuatro anti-patrones muestran dónde mueren las plataformas. No empieces por el portal — empieza por un golden path que de verdad le ahorre un día a un desarrollador. Y las seis capas no tienen que llegar todas a la vez — añádelas de forma incremental, a medida que cada capa previa empieza a rentabilizarse.