Parte VII: Parte 7 — Patrones, principios y casos de estudio: las recetas que sobreviven al tiempo

Al terminar este capítulo vas a poder:

* Conocer los 8 patrones que la comunidad ha validado para implementar IDPs.
* Diferenciar entre MVP, plataforma completa y wrapper de UI.
* Aplicar "Platform as a Product" como mindset antes que como tecnología.
* Diseñar golden paths que se midan, no que se acumulen.
* Evitar el patrón "Field of Dreams" (construir y esperar que vengan).
====

// evidence: cl-spotify-200-plugins (Spotify webinar Oct 2025), cl-team-topologies (4 tipos de equipo)

=== Por qué importan los patrones

Construir una IDP no es un proyecto: es un **producto vivo** que sirve a developers. Y como cualquier producto, hay formas que sobreviven al tiempo y formas que mueren en 18 meses.

humor::
Un patrón es como una receta de cocina con cinco estrellas. La han probado cien cocineros, la han ajustado, y todos sobreviven al hacerla. Un anti-patrón es la receta que tu cuñado encontró en YouTube y que ha salido mal en cada familia que la prueba.

La diferencia entre un proyecto IDP que dura 5 años y uno que se abandona al año no es la tecnología. Es **cómo se pensó, cómo se vendió, cómo se mantuvo**. Los patrones que verás aquí vienen de:

* Spotify, Dynatrace, JPMorgan, American Airlines, LinkedIn, Twilio, Unity, Splunk, IKEA, HP — los casos públicos de empresas con Backstage en producción.
* Los principios del libro https://teamtopologies.com/[Team Topologies] de Skelton y Pais.
* Las 8 anti-patterns documentadas por https://www.infoworld.com/article/4064273/8-platform-engineering-anti-patterns.html[InfoWorld] y https://jellyfish.co/library/platform-engineering/anti-patterns[Jellyfish].
* La experiencia de campo del equipo de Backstage de Spotify en 200+ plugins internos.

=== Patrón 1: Platform as a Product (PaaP)

El patrón más importante. No es una tecnología, es una **postura mental**: la plataforma es un producto, los developers son clientes, y el equipo de plataforma es un equipo de producto.

humor::
"Platform as a Product" es lo que pasa cuando el equipo de plataforma deja de medir su éxito en "tickets cerrados" y empieza a medirlo en "developers auto-servidos". Es el cambio de "somos un help desk" a "somos un negocio que vende un servicio interno".

==== Lo que implica

[cols="1,3", options="header"]
|===
| Práctica | Qué significa

| Roadmap público
| El equipo de plataforma publica su roadmap trimestral. Los stream-aligned teams votan features.

| User research
| Antes de construir una feature, el equipo hace 5-10 entrevistas con developers. No asumen qué necesitan.

| Onboarding
| Cada nuevo developer tiene un "first day experience" con la plataforma. Onboarding medido en horas, no en semanas.

| Métricas de uso
| DAU/MAU, tiempo de onboarding, % de equipos usando la plataforma. No tickets cerrados.

| Marketing interno
| Demos en all-hands, newsletters, "what's new". Como cualquier producto.

| Versioning
| La plataforma tiene versión. Los breaking changes se anuncian. Hay LTS.
|===

==== Lo que NO es

* No es tener un `app-config.yaml` bonito.
* No es instalar Backstage y decir "ya está".
* No es tener un equipo grande de SREs contestando tickets.

NOTE::
**Test definitivo**: si un developer necesita ayuda humana para usar la plataforma, **la plataforma ha fallado**. El self-service no es un nice-to-have; es la definición misma de plataforma. Si la quitas y todo se rompe, tienes un help desk glorificado, no una plataforma.

=== Patrón 2: Minimum Viable Platform (MVP)

NOTE::
El error #1 de platform engineering es construir un sistema "completo" antes de tener usuarios. Es exactamente lo que el patrón **Field of Dreams** describe: "if you build it, they will come". Casi nunca vienen.

==== Cómo construir un MVP que sobreviva

[source,typescript]
----
// Antes: "voy a construir la plataforma completa"
// pipeline = "construir todo"
// coste = 6-12 meses sin feedback

// Después: "voy a resolver UN problema"
// pipeline = "resolver el dolor #1 de 5 equipos"
// coste = 6-8 semanas
----

**Pasos del MVP**:

. **Lista 20 fricciones de developers** (no plataformas, fricciones: "tarda 3 días en provisionar un bucket S3", "no encuentro el dueño del servicio X").
. **Ranking por severidad × frecuencia**. Elige la fricción top.
. **Construye solo el camino feliz** para esa fricción. Sin generalizar, sin frameworks, sin abstracciones prematuras.
. **Mide uso real**. ¿Cuántos developers la usaron esta semana? Si < 30%, vuelve al paso 1.
. **Pregunta a esos 30%** qué fricción resolver después. Vuelve al paso 1.

humor::
Construir un MVP es como servir el primer plato de un menú. Si nadie lo pide, no es que el menú esté mal diseñado: es que el primer plato no resuelve un hambre real. El error es seguir cocinando en lugar de preguntar al cliente qué tiene hambre.

==== Caso real: Spotify

Spotify no lanzó Backstage como "plataforma completa" en 2020. Lanzó el Software Catalog con tres features: ver servicios, ver owners, ver docs. Los developers lo usaron porque resolvía el problema #1 (¿quién es el dueño del servicio X?). Las features vinieron después, basadas en uso real.

Hoy tienen 200+ plugins, pero empezaron con **tres páginas web**.

=== Patrón 3: Self-Service First

Si un developer necesita pedir un ticket, abrir un Slack, o esperar a alguien para hacer algo, **no es self-service**. Es un help desk con mejor branding.

==== El test del café

NOTE::
**Analogía**: en una cafetería moderna, pides tu café en una tablet, lo pagas con tarjeta, y te lo llevas. Nadie te cobra en una ventanilla después. Si tu plataforma tiene una "ventanilla de tickets" para provisionar un namespace de Kubernetes, **es una cafetería con ventanilla**. No es moderna.

==== Self-service real vs. aparente

[cols="1,3", options="header"]
|===
| Tarea | Apparent self-service | Real self-service

| Crear servicio
| "Pulsa este botón y rellena el form" → ticket
| Pulsa el botón y 30 segundos después tienes repo + CI + namespace + catalog entity

| Provisionar bucket
| "Solicita en el portal" → ticket → espera 2 días
| `aws s3 mb` + IAM + monitoreo automáticos, sin tickets

| Rotar secreto
| "Abre ticket" → ticket → espera
| Script diario automatizado que rota y notifica
|===

WARNING::
**Red flag**: si tus métricas incluyen "tiempo medio de respuesta a tickets de plataforma", tienes un help desk. La métrica debería ser "tiempo medio de self-service" y debería tenderer a cero.

=== Patrón 4: Golden Path, no Golden Cage

Un **golden path** es el camino recomendado para una tarea común. Una **golden cage** es cuando solo existe ese camino y los developers no pueden salir.

==== Diseño correcto

[source,yaml]
----
# Golden path: crear un servicio
- Repo con plantilla (Scaffolder)
- CI configurada (GitHub Actions)
- Catalog entity registrada
- Namespace de Kubernetes
- Secrets provisionados
- Alertas configuradas

# Pero el developer PUEDE:
- Crear el repo manualmente sin pasar por el template
- Usar un nombre de namespace no estándar (con un PR que lo justifique)
- Modificar el Dockerfile generado
- No usar la plantilla CI si su equipo tiene una propia
----

==== Diseño incorrecto (cage)

[source,yaml]
----
# "Golden cage": el developer NO PUEDE
- Crear un servicio sin pasar por el Scaffolder (política enforced)
- Usar un namespace no listado en el catálogo
- Modificar el Dockerfile sin un PR aprobado por security
- No usar la plantilla CI (la build falla)
----

TIP::
**Regla de oro**: golden path es la recomendación. Si un developer elige un camino distinto, el equipo de plataforma debe preguntar **por qué** y mejorar el path. Si el golden path es realmente el mejor, los developers lo eligen voluntariamente. Si hay que forzarlo, el path no es bueno.

=== Patrón 5: Cognitive Load Reduction

El argumento más fuerte a favor de una IDP: **reduce la carga cognitiva** de un developer. No le hagas memorizar 20 pasos; dale una pantalla y un botón.

==== Las 5 cosas que un developer NO debería tener que recordar

NOTE::
.5 preguntas que un developer hace cada día (y que la plataforma debería responder)

==== Métricas concretas

[source,typescript]
----
// ¿Cómo medirlo?
const metrics = {
  'time_to_find_service': {
    description: 'Tiempo desde "¿dónde está X?" hasta el link del repo',
    target: '< 5 segundos',
    measurement: 'analytics desde el search del catalog',
  },
  'time_to_find_owner': {
    description: 'Tiempo desde "¿quién es el dueño?" hasta el contacto',
    target: '< 10 segundos',
    measurement: 'click en el nombre del owner → Slack/email',
  },
  'time_to_first_deploy': {
    description: 'Tiempo desde "necesito deployar" hasta deploy exitoso',
    target: '< 30 minutos',
    measurement: 'Scaffolder task duration + deploy duration',
  },
};
----

=== Patrón 6: Feedback Loops Continuos

Una plataforma sin feedback loop es como cocinar sin probar la comida: puedes seguir años sin saber si está buena.

==== Los 4 feedback loops que necesitas

[cols="1,3", options="header"]
|===
| Loop | Qué mide | Cómo actuar

| **User research**
| ¿Qué fricción tienen los developers AHORA?
| Monthly: 5 entrevistas + survey

| **Adoption metrics**
| ¿Cuántos developers usan la plataforma?
| Weekly: DAU, MAU, % de equipos activos

| **Quality metrics**
| ¿Funciona bien? ¿Es rápida? ¿Tiene bugs?
| Daily: MTTR de incidencias, latencia p95

| **Value metrics**
| ¿Está cumpliendo los objetivos de negocio?
| Quarterly: onboarding time, deploy frequency, MTTR global
|===
| ¿Está cumpliendo los objetivos de negocio?
| Quarterly: onboarding time, deploy frequency, MTTR global
|===

==== Caso real: Spotify

Spotify reporta que **50% de sus empleados usan Backstage mensualmente**, y la mayoría de engineers lo usan diariamente. Esa es la métrica de adopción que justifica la inversión.

(Ver :xref:cap-23-buenas-practicas-platform-engineering[cap-23] para más sobre métricas.)

=== Patrón 7: Treating Plugins as Products

Cada plugin de Backstage debería tratarse como un **producto independiente** con:
* Un owner claro
* Una definición de "done"
* Una definición de "users" (¿quién lo usa?)
* Una versión con semver
* Documentación y onboarding

humor::
Un plugin sin owner es como una receta sin cocinero: la escribió alguien que ya no está, nadie la mantiene, y la primera vez que falla, todo el restaurante se para. Si tu plugin no tiene un humano responsable, **no es un plugin**: es un archivo huérfano.

==== Patrón Spotify: "Contributing teams own their plugins"

NOTE::
El caso Spotify (de :xref:cap-22-casos-de-estudio-famosos[cap-22]):

> "Inside Spotify we have a team that owns our CI platform. They not only maintain the pipelines and build servers, but also expose their product in Backstage through a plugin. Since they also maintain their own API, they can improve their product by iterating on API and UI in lockstep."

Cada equipo dueño de su **propio producto** (CI, monitoring, secrets) crea y mantiene **su propio plugin**. El equipo de plataforma solo provee el "shell" (la app, el catalog, los mecanismos comunes).

**Lección**: no centralices la creación de plugins en el equipo de plataforma. Empodera a cada equipo de producto a crear el suyo. El equipo de plataforma solo provee guías, lint, y herramientas comunes.

=== Patrón 8: Embedded Rotations (no Skill Concentration Trap)

WARNING::
**Anti-pattern (Skill Concentration Trap)**: el equipo de plataforma recluta a todos los senior engineers. Los product teams pierden expertise. Resultado: el equipo de plataforma se convierte en cuello de botella y los product teams se vuelven "consumidores pasivos".

**Patrón (Embedded Rotations)**: rotar developers de product teams al equipo de plataforma, y de plataforma a product teams. 1 sprint cada 6 meses.

Beneficios:
* Los platform engineers entienden el dolor real de los developers.
* Los product teams conocen la plataforma por dentro, no la temen.
* Se distribuye el conocimiento: si un platform engineer se va, hay 5 personas que pueden mantener su código.

TIP::
Spotify practica esto: cada nuevo Backstage engineer pasa su primer mes en un product team, y cada platform engineer rota 1 sprint al año a un product team. El resultado: cuando un developer reporta un bug, el platform engineer que lo recibe ya sabe qué hace ese equipo.

=== Resumen

* **Platform as a Product**: la plataforma es un producto, los developers son clientes.
* **MVP primero**: resuelve UNA fricción real, mide uso, itera.
* **Self-Service First**: si requiere un ticket, no es plataforma.
* **Golden Path, no Golden Cage**: recomienda, no fuerces.
* **Cognitive Load Reduction**: 5 preguntas que la plataforma debe responder en segundos.
* **Feedback Loops**: user research, adopción, calidad, valor.
* **Plugins as Products**: cada plugin con owner, versión, y "users" definidos.
* **Embedded Rotations**: distribuir conocimiento, evitar el skill concentration trap.

=== Glosario del capítulo

[glossary]
Platform as a Product (PaaP):: Mentalidad de tratar la plataforma como un producto con clientes, métricas y roadmap.
Minimum Viable Platform (MVP):: La fricción más dolorosa resuelta en 6-8 semanas, no la plataforma completa.
Self-service:: Capacidad de un developer de hacer una tarea sin intervención humana.
Golden path:: Camino recomendado para una tarea común. Recomendado, no forzado.
Golden cage:: Anti-pattern donde solo existe un camino y se fuerza a los developers.
Cognitive load:: Esfuerzo mental requerido para usar una herramienta. La plataforma debe minimizarlo.
Embedded rotation:: Práctica de rotar developers entre platform team y product teams.
Skill concentration trap:: Anti-pattern: todos los senior engineers en platform team, los product teams pierden expertise.

=== Próximo capítulo

xref:cap-22-casos-de-estudio-famosos[Capítulo 22 — Casos de estudio: lo que aprendimos de Spotify, Netflix, American Airlines y más] — qué hicieron bien, qué hicieron mal, y qué puedes copiar directamente.

:leveloffset!:

:leveloffset: +1

== Casos de estudio: lo que aprendimos de los que ya lo hicieron
:chapter: cap-22
:part: parte-7-patrones
:order: 22

[chapter-meta]
====
*Tiempo de lectura*: 22 min · *Itinerarios*: cocinero jefe, CTO, consultor. Lee :xref:cap-21-patrones-de-implementacion[cap-21] antes.
====

NOTE::
.Objetivos del capítulo