Imagínate que organizas la boda de un amigo en un restaurante que no tiene carta. Hay cocina, hay cocineros, pero no sabes si pedir el pollo o el solomillo. Eso es lo que vive un developer cuando aterriza en una empresa con 40 servicios y nadie le ha dicho dónde está cada cosa.

Cuando una organización pasa de 10 servicios a 40, la pregunta "¿dónde está el código del cálculo de impuestos?" deja de tener una respuesta evidente. Los READMEs están desactualizados, los wikis tienen tres versiones contradictorias y las URLs de los servicios viven en Notion, Slack o la cabeza de tres personas.

Una IDP (Internal Developer Platform) existe para resolver ese problema. Es la cocina del restaurante: un sitio donde todo está en su sitio, donde un cocinero nuevo encuentra cada utensilio y cada receta, y donde el plato que llega al comensal es consistente porque la cocina tiene standards.

Una IDP es una plataforma interna, propiedad del equipo de plataforma, que sirve a los developers de la organización. Tiene cuatro características:

Lo que NO es una IDP:

Una IDP no es un proyecto. Es un producto interno, con users que son developers, con métricas de adopción, con un ciclo de feedback. El equipo que la mantiene (el equipo de plataforma) tiene una cultura concreta: se preocupa por la experiencia de otros equipos tanto como por la suya.

Eso es platform thinking, y la diferencia entre hacerlo bien y hacerlo mal es enorme:

El platform thinking se aprende. La segunda parte del libro, a partir del :cap-15, se ocupa de cómo sostener esta cultura con métricas, equipos y procesos.

Backstage nació en Spotify en 2016 como una herramienta interna para resolver un problema concreto: su catálogo de microservicios había crecido hasta un punto en el que nadie sabía dónde estaba cada cosa. En 2020, Spotify lo donó a la Cloud Native Computing Foundation (CNCF) bajo la licencia Apache 2.0. En 2022 entró en incubación. A fecha de hoy (mediados de 2026), Backstage 1.31+ es la línea estable, y la New Backend System está consolidada como la arquitectura por defecto desde la 1.20.

La cadencia de releases es la del semver estricto: una release menor cada cuatro a seis semanas, con breaking changes documentados y, desde 2024, codemods oficiales para automatizar migraciones. Esto importa a un libro: cualquier afirmación de versión lleva fecha. La versión objetivo de este libro, fijada en la :Macro-fase R, es Backstage 1.31+, y la comida se prepara con esa versión como referencia.

A veces la respuesta correcta es no montar una IDP. No es una herejía: es ingeniería honesta.

Una IDP es un producto interno. Tiene coste (tiempo, людей, mantenimiento). Si tu organización tiene menos de 10 developers, ese coste probablemente supera al beneficio. Heurística:

Existen además contextos en los que, aun a esa escala, no encaja: una empresa con un único producto monolítico, una organización con restricciones air-gapped extremas, o un equipo que ya tiene un portal propietario y no quiere cambiar. El :cap-16 baja a tierra la decisión.

No todos los lectores necesitan todo. El libro define cuatro itinerarios declarados en el audience-profile.yml:

El :apéndice J condensa las métricas de éxito para el último itinerario.

Anatomía de Backstage: dos mitades y un plugin —entramos a la cocina: frontend, backend, New Backend System, modelo de plugins.