Platform Engineering: Cómo Construir una Plataforma Interna de Desarrollo (IDP)

De DevOps a Platform Engineering: por qué el cambio

El 'shift left' de DevOps le dio a los equipos autonomía sobre su infraestructura, pero a escala esa autonomía tiene un costo: carga cognitiva. Un desarrollador que quiere lanzar un servicio nuevo termina tomando decisiones sobre Kubernetes, Terraform, CI/CD, secretos, observabilidad y redes — ninguna de las cuales aporta valor directo al producto. Platform Engineering reconoce que la mayoría de esas decisiones ya se tomaron bien una vez, y que repetirlas en cada equipo es desperdicio.

La idea central: un equipo de plataforma trata la plataforma interna como un producto, con los desarrolladores de la organización como usuarios. En lugar de tickets y wikis, ofrece self-service; en lugar de documentar cómo hacer algo, hace que la forma correcta sea la más fácil. El resultado se mide en tiempo: cuánto tarda un desarrollador desde 'quiero un servicio nuevo' hasta 'está en producción con logs, métricas y CI/CD'.

Qué es un Internal Developer Platform (IDP)

Un IDP es la capa que se sienta entre los desarrolladores y la complejidad de la infraestructura. No es una sola herramienta — es un conjunto de capacidades integradas que un desarrollador consume sin necesitar entender lo que hay debajo:

• Self-service: el desarrollador aprovisiona lo que necesita (un servicio, una base de datos, un entorno) sin abrir un ticket ni esperar a otro equipo.
• Golden paths: caminos pavimentados y opinados para las tareas comunes — crear un servicio, añadir una base de datos, exponer una API — con las decisiones correctas ya integradas.
• Catálogo de software: un inventario vivo de todos los servicios, sus dueños, dependencias y estado. Responde '¿qué existe y quién lo mantiene?' sin arqueología.
• Plantillas (scaffolding): generación de nuevos servicios ya cableados con CI/CD, observabilidad, seguridad y estándares de la organización desde el primer commit.

Golden Paths: el corazón del IDP

Un golden path es la forma recomendada y soportada de hacer algo común, empaquetada para que sea la ruta de menor resistencia. No prohíbe alternativas — hace que el camino correcto sea tan fácil que la mayoría lo elige por defecto. El ejemplo canónico: crear un servicio nuevo.

Sin golden path, un servicio nuevo implica copiar otro repo, ajustar el pipeline, configurar secretos, añadir dashboards y esperar no olvidar nada. Con un golden path, es un comando o un formulario que genera todo eso correcto desde el inicio:

# Backstage Scaffolder — plantilla de "servicio nuevo" (golden path)
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: nodejs-service
  title: Servicio Node.js (con CI/CD y observabilidad)
  description: Crea un servicio con pipeline, dashboards y estándares de IQS
spec:
  parameters:
    - title: Datos del servicio
      required: [name, owner]
      properties:
        name:  { type: string, description: Nombre del servicio }
        owner: { type: string, description: Equipo dueño }
  steps:
    - id: fetch
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      action: publish:gitlab
      input:
        repoUrl: gitlab.com?repo=${{ parameters.name }}
    - id: register
      action: catalog:register        # se registra solo en el catálogo
      input:
        catalogInfoUrl: /catalog-info.yaml

El esqueleto (skeleton) que genera esta plantilla ya incluye el pipeline de CI/CD, el Dockerfile, los manifiestos de Kubernetes, la configuración de logs y métricas, y el archivo de catálogo. El desarrollador no toma ninguna de esas decisiones — las tomó el equipo de plataforma una vez, bien, y las codificó.

El catálogo de software con Backstage

El catálogo responde la pregunta que se vuelve imposible a escala: '¿qué servicios existen, quién los mantiene y de qué dependen?'. Cada componente se describe con un archivo declarativo que vive junto al código, de modo que el catálogo nunca se desactualiza:

# catalog-info.yaml — vive en la raíz del repositorio del servicio
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout-api
  description: API de checkout y órdenes
  annotations:
    gitlab.com/project-slug: iqs/checkout-api
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: team-payments
  dependsOn:
    - resource:postgres-orders
    - component:pricing-service

Con esta información declarada por cada servicio, el portal construye automáticamente el grafo de dependencias, las páginas de propiedad por equipo y la documentación técnica. Cuando algo falla, el catálogo responde en segundos quién es el dueño y qué más se ve afectado.

Self-service sin perder gobernanza

El miedo legítimo al self-service es el caos: si cualquiera puede aprovisionar lo que quiera, la seguridad y los costos se descontrolan. La solución no es volver a los tickets — es codificar la gobernanza dentro del propio camino de self-service. El desarrollador pide en términos de aplicación; la plataforma traduce a infraestructura conforme a las políticas.

# El desarrollador declara la intención; la plataforma impone el estándar.
# Recurso de alto nivel (Crossplane) — no toca Terraform ni IAM directamente
apiVersion: platform.iqs.io/v1alpha1
kind: PostgresInstance
metadata:
  name: orders-db
spec:
  size: small          # small | medium | large -> tamaños aprobados
  environment: prod
  team: team-payments  # deriva permisos, tags de costo y backups por política

Detrás de ese recurso simple, la plataforma aplica cifrado, backups, tags de costo, reglas de red y permisos mínimos — todo sin que el desarrollador los configure ni pueda saltárselos. La gobernanza deja de ser una revisión manual y se vuelve parte de la definición.

Métricas: cómo saber si tu plataforma funciona

Un IDP es un producto interno, y como todo producto se mide por adopción y por el resultado que produce, no por las features que tiene. Las métricas que importan:

• Tiempo al primer deploy: cuánto tarda un desarrollador nuevo desde cero hasta su primer cambio en producción. Es el indicador más honesto de la fricción real de tu plataforma.
• Adopción de golden paths: qué porcentaje de servicios nuevos usan las plantillas de la plataforma frente a los que se crean por fuera. Baja adopción significa que el camino no es lo bastante fácil.
• Métricas DORA: frecuencia de despliegue, lead time, tasa de fallo de cambios y tiempo de recuperación. Una buena plataforma las mejora de forma transversal a todos los equipos.
• Satisfacción del desarrollador (DevEx): encuestas cortas y periódicas. La plataforma existe para servir a los desarrolladores; si la odian, no importa qué tan elegante sea por dentro.

Errores comunes al adoptar Platform Engineering

• Construir la plataforma sin tratar a los desarrolladores como clientes: si el equipo de plataforma decide en aislamiento qué necesitan los demás, construye algo que nadie pidió. Habla con tus usuarios internos como hablarías con clientes externos.
• Empezar por el portal en vez de por los golden paths: un Backstage instalado sin automatización detrás es un catálogo bonito y vacío. El valor está en los caminos pavimentados, no en la interfaz.
• Imponer en lugar de pavimentar: forzar la plataforma con prohibiciones genera atajos clandestinos. Gana adopción haciendo que el camino correcto sea el más cómodo.
• Adoptar Platform Engineering demasiado pronto: con 2-3 equipos, el overhead de una plataforma formal no se justifica. Tiene sentido cuando la duplicación entre equipos y la carga cognitiva empiezan a costar más que la plataforma.