¿Qué es una IDP?
Una Internal Developer Platform (IDP) es la capa de abstracción entre los equipos de producto y la infraestructura. En teoría, suena bien. En la práctica, la mayoría de las IDPs que he visto son o bien demasiado rígidas para que alguien las adopte voluntariamente, o bien tan flexibles que nadie sabe cómo usarlas.
Este artículo recoge lo que aprendí construyendo una IDP para 40 equipos de ingeniería en una fintech: qué funcionó, qué descartamos y por qué la experiencia del desarrollador es el único KPI que importa al final.
Una IDP es buena cuando los equipos la usan sin que nadie se lo pida. Si necesitas evangelizarla internamente, algo está mal en el diseño.
El problema real
El síntoma era siempre el mismo: los equipos de producto abrían un ticket para pedir un deploy. El equipo de plataforma respondía cuando podía. En horas valle, eso significaba esperas de un día.
- Scaffolding de nuevos servicios: proceso manual de 2–3 días con documentación desactualizada.
- Secretos de producción: acceso directo a la consola de AWS, sin rotación automática ni auditoría.
- Estado real de los servicios: imposible saberlo sin hablar con alguien del equipo de plataforma.
El equipo de plataforma no era ineficiente. Era un cuello de botella estructural: cuatro personas dando soporte a 200 ingenieros sin ninguna capa de self-service.
Golden paths
La solución no era escribir más automatización. Era cambiar el modelo mental: de "equipo de plataforma como servicio" a "plataforma como producto interno".
La plataforma no es para el equipo de plataforma. Es para los equipos de producto. Si ellos no la adoptan sin que se lo pidas, has fallado.
El concepto de golden path es central: una forma opinionada y bien documentada de hacer las cosas que funciona para el 80% de los casos, con capacidad de escape para el 20% restante. Tres decisiones de diseño que lo cambiaron todo: Backstage como portal, ArgoCD para GitOps y Terraform modules como contrato de infraestructura.
La implementación
El corazón del self-service era un plugin de Backstage que generaba el Application manifest de ArgoCD y creaba el PR directamente en el repositorio de GitOps:
// Scaffolding action: crea Application en ArgoCD via GitOps PR
export const createArgoApplication = createTemplateAction({
id: "argocd:create-application",
async handler(ctx) {
const { serviceName, namespace } = ctx.input;
const manifest = renderAppManifest(serviceName, namespace);
await gitopsClient.createPR(manifest);
ctx.logger.info(`PR creado para ${serviceName}`);
},
});
Conclusiones
Seis meses después del lanzamiento, el 80% de los deploys no requerían intervención del equipo de plataforma. El onboarding de un servicio pasó de tres días a cuatro horas. Pero la métrica que más me importaba era otra: los equipos de producto dejaron de abrir tickets. Empezaron a abrir PRs.
Una IDP buena no se nota. Es como una buena infraestructura de ciudad: la usas todos los días sin pensar en ella. Eso es lo que hay que construir.