Platform Engineering — Plataformas de Desarrollo Internas

Overview

Platform engineering es la disciplina de construir y mantener Internal Developer Platforms (IDPs): capas de self-service que abstraen la complejidad de infraestructura y permiten a los desarrolladores desplegar, operar y observar sus aplicaciones sin experiencia profunda en plataforma. En lugar de que cada equipo reinvente CI/CD, observabilidad y patrones de seguridad, un equipo de plataforma cura “golden paths” — caminos pavimentados con guardrails que hacen que lo correcto sea lo fácil. El objetivo no es restringir a los desarrolladores sino acelerarlos removiendo carga cognitiva.

Un IDP bien construido trata la plataforma como un producto. El equipo de plataforma tiene un roadmap, recopila feedback de los desarrolladores internos e itera. Cuando funciona, un desarrollador puede crear un scaffold de un servicio nuevo, conectar CI/CD, provisionar una base de datos y desplegar a producción en menos de una hora — sin abrir un solo ticket.

When to Use

Deberías considerar platform engineering cuando:

• Tienes 10+ equipos de ingeniería con esfuerzo duplicado en infraestructura
• El onboarding de desarrolladores toma días porque los entornos son artesanales
• Los equipos pasan más tiempo en YAML que en lógica de negocio
• Los requerimientos de seguridad y compliance se aplican inconsistentemente
• Quieres escalar la adopción de Kubernetes sin que cada equipo sea admin de cluster

Probablemente no necesites un IDP aún si tienes menos de 5 equipos, un único destino de despliegue, o una arquitectura monolítica sin planes de dividir. En esos casos, un pipeline CI/CD compartido y un buen README te llevarán más lejos que un equipo de plataforma completo.

El punto de inflexión es cuando el coste del esfuerzo duplicado supera el coste de mantener un equipo de plataforma. Si tres equipos dedican dos días a la semana a configurar infraestructura, un equipo de plataforma que elimine esa duplicación se paga solo en el primer trimestre.

Para alternativas de infraestructura como código, consulta la Guía Completa de Módulos de Terraform.

Componentes Core de IDP

Componente	Propósito	Herramientas ejemplo
Portal de desarrollador	Catálogo de servicios, docs, scaffolds	Backstage, Port, Cortex
Infraestructura self-service	Entornos on-demand, bases de datos	Crossplane, Terraform Cloud, Pulumi
Golden path CI/CD	Pipelines de despliegue estandarizadas	ArgoCD, GitHub Actions, Tekton
Stack de observabilidad	Métricas, logs, traces por servicio	Prometheus, Grafana, Tempo, Loki
Guardrails de seguridad	Policy-as-code, gestión de secretos	OPA, Kyverno, Vault

El Golden Path

Un golden path es un workflow bien soportado, documentado y templatizado para una tarea común:

┌─────────────────────────────────────────────────────────┐
│  Desarrollador quiere: "Desplegar una nueva REST API"    │
│                                                         │
│  → Backstage scaffold: template de API                   │
│  → Auto-generado: pipeline CI/CD, monitoreo, TLS         │
│  → ArgoCD despliega en staging con policy checks         │
│  → PR a main → canary a producción                      │
│  → Dashboard Grafana y alertas auto-provisionadas        │
└─────────────────────────────────────────────────────────┘

El desarrollador no elige el controlador de ingress, el formato de logs, ni la convención de nombres de métricas. La plataforma tomó esas decisiones — y las hace cumplir.

Cómo Funciona

Un IDP se sitúa entre el desarrollador y la infraestructura cruda. El equipo de plataforma construye abstracciones (templates, CRDs, pipelines) que ocultan la complejidad específica del cloud. Los desarrolladores interactúan con la plataforma a través de un portal (Backstage), un CLI, o GitOps — nunca directamente con las consolas de AWS, GCP o Azure.

La arquitectura tiene tres capas:

Capa	Quién la construye	Quién la usa	Ejemplo
Portal	Equipo de plataforma	Desarrolladores, managers	Catálogo de servicios Backstage, scaffolder
API de plataforma	Equipo de plataforma	CI/CD, GitOps	Crossplane CRDs, módulos Terraform, Helm charts
Infraestructura	Proveedor cloud	Equipo de plataforma (no desarrolladores)	RDS, EKS, S3, VPC

La clave: los desarrolladores nunca tocan la capa de infraestructura. Declaran lo que necesitan (una base de datos, una cola, un caché) a través de la API de plataforma, y la automatización del equipo lo provisiona. Esta separación es lo que hace posible el self-service a escala.

GitOps es el tejido conectivo entre el portal y la infraestructura. Los templates de Backstage generan un repo con un catalog-info.yaml y un Helm chart. ArgoCD vigila el repo y sincroniza el Helm chart al cluster. Cuando un desarrollador necesita una base de datos, no ejecuta aws rds create-db-instance — commitea un manifiesto DatabaseClaim y Crossplane se encarga del resto. Todo el workflow es auditable a través del historial de Git.

Para la observabilidad de la propia plataforma — métricas, logs, traces de los componentes del IDP — consulta la Guía de Observabilidad. Para prácticas SRE que el equipo de plataforma debería adoptar, consulta la Guía de Prácticas SRE.

Configuración de Backstage

Backstage es el portal de desarrollador open-source más adoptado — Spotify lo construyó y luego lo donó a la CNCF. Te da un catálogo de servicios, un scaffolder para templates de golden path, TechDocs para documentación, y un ecosistema de plugins.

Aquí hay un app-config.yaml mínimo que registra un catálogo externo y un template de scaffolder:

# app-config.yaml
app:
  title: Internal Developer Portal
  baseUrl: http://localhost:3000

backend:
  baseUrl: http://localhost:7007
  listen:
    port: 7007

catalog:
  rules:
    - allow: [Component, System, API, Resource, Location]
  locations:
    - type: url
      target: https://github.com/acme/catalog-info.yaml

scaffolder:
  locations:
    - type: url
      target: https://github.com/acme/backstage-templates/nodejs-api/template.yaml

techdocs:
  builder: 'local'
  generator:
    runIn: 'docker'

La sección catalog le dice a Backstage dónde encontrar los metadatos de servicios. Cada repo de servicio contiene un catalog-info.yaml que declara el tipo de componente, el owner y las dependencias. La sección scaffolder apunta a los repos de templates — esos son los golden paths. Cuando un desarrollador hace clic en “Create component” en Backstage, el scaffolder ejecuta el template, que puede generar un repo, un pipeline CI/CD, Helm charts y dashboards de monitoreo.

Para las prácticas de seguridad CI/CD que el equipo de plataforma debería aplicar en estos pipelines, consulta la Guía de Seguridad CI/CD.

Crossplane para Infraestructura Self-Service

Crossplane es un control plane nativo de Kubernetes que permite al equipo de plataforma definir recursos personalizados (CRDs) que representan infraestructura. Los desarrolladores solicitan recursos a través de manifiestos Kubernetes — sin consola de AWS, sin Terraform CLI, sin tickets.

apiVersion: platform.example.com/v1alpha1
kind: DatabaseClaim
metadata:
  name: payment-db
  namespace: payments
spec:
  engine: postgres
  version: "15"
  size: small
  backupRetentionDays: 7

El equipo de plataforma define este CRD. Crossplane lo compone en instancias RDS, grupos de seguridad VPC y políticas de backup. El desarrollador solicita una base de datos sin saber que AWS existe.

La potencia aquí es que el equipo de plataforma controla la composición. Si la empresa migra de RDS a Aurora, o de AWS a GCP, el manifiesto DatabaseClaim del desarrollador no cambia — solo cambia la composición Crossplane detrás. Esto es lo que hace la abstracción real en lugar de cosmética.

Comparando Portales IDP: Backstage vs Port vs Cortex

Característica	Backstage	Port	Cortex
Licencia	Open source (CNCF)	SaaS	SaaS
Catálogo de servicios	Sí (built-in)	Sí	Sí
Scaffolder	Sí (built-in)	Sí (builder no-code)	No
Ecosistema de plugins	200+ plugins	API-first	API-first
Self-host vs gestionado	Self-host	Gestionado	Gestionado
Curva de aprendizaje	Pronunciada (React, YAML)	Baja (UI no-code)	Baja
Mejor para	Equipos con platform engineers	Equipos que quieren setup rápido	Equipos enfocados en scorecards

Backstage te da la máxima flexibilidad y el ecosistema más grande, pero necesitas platform engineers para mantenerlo. Port y Cortex son SaaS gestionados — más rápidos de adoptar, pero pagas por seat y tienes menos control sobre el scaffolder. La mayoría de equipos empieza con Backstage porque es gratis y la comunidad CNCF detrás está activa. Si no tienes el ancho de banda para mantener una app React, Port es la elección pragmática.

Midiendo el Éxito de la Plataforma

Un equipo de plataforma que no mide la adopción está volando a ciegas. Estas son las métricas que importan:

Métrica	Cómo medir	Target
Tiempo para provisionar entorno	Analytics de Backstage	< 10 minutos
Tiempo de onboarding de desarrollador	Encuestas HR + plataforma	< 1 día
Frecuencia de despliegue	Métricas DORA	2+ por desarrollador por día
NPS de plataforma	Encuesta trimestral de desarrolladores	> 50
Volumen de tickets al equipo de plataforma	Datos ITSM	Tendencia decreciente

Trackea esto en un dashboard de Grafana. El equipo de plataforma debería revisarlo mensualmente y reportar a liderazgo de ingeniería trimestralmente. Si el volumen de tickets no está bajando después de 6 meses, la capa de self-service no está funcionando — los desarrolladores siguen pidiendo ayuda manual al equipo de plataforma.

Un error común es trackear solo el uptime de plataforma. Una plataforma con 99.99% de disponibilidad pero que tarda 2 semanas en provisionar una base de datos es una plataforma fallida. Las métricas correctas miden productividad del desarrollador, no salud de infraestructura.

Anti-Patrones de Equipo de Plataforma

Anti-patrón	Fix
Equipo de plataforma como ticket ops	Construir APIs self-service, no colas de tickets
Mandatos one-size-fits-all	Los golden paths deben ser defaults, no requerimientos. Permitir escape hatches.
Plataforma sin usuarios	Tratar equipos internos como clientes. Hacer user research.
Sobre-abstraer	Si la plataforma es más difícil que la herramienta subyacente, ha fallado.
Sin product management	Los equipos de plataforma necesitan roadmaps, OKRs y loops de feedback como cualquier equipo de producto.

Errores Comunes

• Construir antes de entender el dolor — entrevista equipos antes de escribir cualquier código de plataforma. El fallo más común es una plataforma construida para un problema que nadie tiene.
• Reconstruir la plataforma cada año — los plugins de Backstage se quedan obsoletos, las composiciones Crossplane drift, los templates de golden path se pudren. Presupuesta 20-30% de la capacidad del equipo de plataforma para mantenimiento, no solo nuevas features.
• Bloquear en lugar de pavimentar caminos — una plataforma que fuerza a cada equipo a través del mismo pipeline sin escape hatches crea plataformas sombra. Los equipos te rodearán.
• Sin documentación — una plataforma sin docs es una caja negra que genera tickets. Cada golden path necesita un README, una sección de troubleshooting, y al menos un ejemplo funcional.
• Tratar la plataforma como cost center — mide ganancias de productividad del desarrollador, no solo uptime de plataforma. Si no puedes mostrar una métrica antes/después, no puedes justificar el equipo.
• Ignorando la cola larga — el caso del 80% es fácil; la plataforma debe manejar el 20% sin romper. Un equipo con un monorepo Rust o un pipeline de ML training no debería tener que abandonar la plataforma por completo.
• Sin path de migración — los servicios existentes necesitan un path hacia la plataforma, no solo templates greenfield. Migrar 200 servicios legacy es la parte difícil; hacer scaffold de uno nuevo es fácil.

Solución de Problemas

• Template de scaffolder de Backstage falla silenciosamente: revisa los logs de tareas del scaffolder en el backend de Backstage (/api/scaffolder/tasks). La mayoría de fallos son parámetros de template faltantes o una ubicación catalog mal configurada en app-config.yaml.
• Composición Crossplane atascada en SyncError: ejecuta kubectl describe composition para ver qué recurso gestionado falló. La causa más común es un rol IAM sin permiso para crear el recurso cloud subyacente.
• Pipeline de golden path genera Helm chart roto: valida los templates generados con helm template y helm lint en CI antes de mergear cambios de template. Un template malo empuja charts rotos a todos los servicios que lo usan.
• ArgoCD sync loop en un servicio nuevo: verifica que el catalog-info.yaml generado no conflicte con un nombre de componente existente. Las entidades de catálogo duplicadas hacen que ArgoCD oscile entre estados deseados.
• Desarrollador se queja de que la plataforma es más lenta que manual: mide el tiempo end-to-end desde scaffold hasta primer deploy. Si supera la hora, el problema suele ser un paso de aprobación manual escondido en el pipeline — elimínalo o automatízalo con policy-as-code.

Referencia Rápida

• Hacer scaffold de un servicio: npx @backstage/cli create-app para el portal; en producción, los desarrolladores usan el scaffolder de la UI de Backstage.
• Registrar un componente: añade un catalog-info.yaml en la raíz del repo con kind: Component, luego registra la URL en Backstage.
• Provisionar infraestructura: kubectl apply -f database-claim.yaml — Crossplane compone el claim en recursos cloud.
• Comprobar salud de golden path: argocd app list para el estado de deploy; catálogo de Backstage para salud del servicio.
• Rollback: argocd app rollback <app> o revierte el commit de Git que disparó el sync.

Lectura Adicional

• Documentación de Backstage — setup del portal, plugins y authoring de scaffolder.
• Documentación de Crossplane — composiciones, recursos gestionados y configuración de providers.
• Lenguaje de políticas OPA — referencia de Rego para escribir guardrails policy-as-code.
• Informes DORA State of DevOps — datos de benchmark para frecuencia de despliegue y lead time.
• Team Topologies — el libro que definió el modelo operativo platform-as-product.

Notas de Producción

• Versiona tus golden paths — un cambio que rompe un template de scaffolder afecta a todos los servicios que lo usan. Etiqueta releases de templates y pruébalos contra un catálogo de staging antes de desplegar.
• Trackea el drift de Crossplane — un kubectl get managed que muestra recursos fuera de sync suele significar que alguien cambió recursos cloud manualmente. Fuerza cambios solo vía GitOps con políticas IAM.
• Alerta sobre SLOs de plataforma, no solo de servicio — si el scaffolder o el catálogo caen, todos los desarrolladores quedan bloqueados. Monitorea el uptime de Backstage y la latencia de reconciliación de Crossplane como cualquier servicio de producción.
• Rota los secretos usados por templates — los templates de scaffolder a menudo embeben tokens para creación de repos y provisioning de CI/CD. Guárdalos en Vault o External Secrets, nunca en el repo del template.

Puntos Clave

• Los golden paths vencen a los mandatos — haz que lo correcto sea fácil en lugar de hacer que lo incorrecto sea imposible.
• Los equipos de plataforma son equipos de producto — necesitan un PM, un roadmap, user research y métricas de adopción.
• Self-service es la única estrategia de escalado — cada paso manual en un golden path es un cuello de botella esperando a ocurrir.
• Mide adopción, no uptime — una plataforma que nadie usa es peor que no tener plataforma.

Temas Avanzados

Escenario: Plataforma Interna para 50 Equipos

Sistema: Empresa con 50 equipos de producto, 200 servicios
Problema: Cada equipo construye su propio CI/CD, monitoring, auth
Solución: Platform team provee golden paths y tooling compartido

Modelo: Platform as a Product (PaaP)
  | Componente | Herramienta | Consumidores |
  |-----------|------------|--------------|
  | CI/CD | GitHub Actions + templates | 50 equipos |
  | Deploy | ArgoCD + Helm charts | 50 equipos |
  | Monitoring | Prometheus + Grafana | 50 equipos |
  | Logging | Loki + Promtail | 50 equipos |
  | Tracing | Jaeger + OpenTelemetry | 50 equipos |
  | Auth | OAuth2 + SPIFFE | 50 equipos |
  | Secrets | External Secrets Operator | 50 equipos |
  | Service catalog | Backstage | 50 equipos |

Golden paths (plantillas opinionadas):
  1. Nuevo microservicio:
     - Template: npm create @platform/microservice
     - Genera: Dockerfile, Helm chart, CI/CD pipeline,
       monitoring dashboards, alert rules, service catalog entry
     - Tiempo: de 2 días a 15 minutos

  2. Nuevo endpoint API:
     - Template genera: OpenAPI spec, handler, tests,
       documentación, client SDK
     - Validación automática: linter, schema, tests

  3. Onboarding de nuevo equipo:
     - Backstage plugin: provisiona repos, namespaces,
       dashboards, permisos
     - Tiempo: de 1 semana a 1 hora

Métricas de plataforma (SLOs internos):
  | SLO | Objetivo | Métrica |
  |-----|----------|---------|
  | Tiempo de build | < 5 min | p50 pipeline duration |
  | Disponibilidad de deploy | 99.9% | ArgoCD uptime |
  | Adopción de golden paths | > 80% | % servicios con template |
  | Tiempo de onboarding | < 1 día | Horas de provisión |
  | Satisfacción del equipo | > 4/5 | Encuesta trimestral |

Organización:
  Platform team (8 personas):
    - 3 platform engineers (CI/CD, deploy)
    - 2 observability engineers (monitoring, tracing)
    - 2 developer experience (Backstage, templates)
    - 1 product manager (prioriza roadmap)

  Engagement model:
    - Office hours semanales (consultoría)
    - Slack channel #platform-help
    - Roadmap trimestral (feedback -> prioridades)
    - RFCs abiertos para cambios mayores

Lecciones:
  - Trata la plataforma como un producto, no como infraestructura
  - Mide adopción y satisfacción, no solo uptime
  - Golden paths reducen tiempo de onboarding dramáticamente
  - El platform team necesita un PM para priorizar
  - Documentación y ejemplos > soporte 1:1

Escalando Self-Service Más Allá de 50 Equipos

Cuando la plataforma sirve a 50+ equipos, el cuello de botella pasa de provisioning a soporte. Los templates generan todo automáticamente, Backstage te da el catálogo y el scaffolding, y la documentación es detallada. Los office hours son para consultoría, no para tickets. Si los equipos esperan a la plataforma para algo, automatízalo. Mide el tiempo de espera y redúcelo.

Errores Comunes en Producción

• Tratar la plataforma como infraestructura, no como producto — la plataforma necesita un PM, un roadmap y métricas de adopción como cualquier producto.
• Desplegar a todos los equipos de golpe — empieza con 2-3 equipos dispuestos, arregla su feedback, luego expande.
• Dejar que los golden paths se queden obsoletos — los plugins de Backstage y las composiciones Crossplane necesitan mantenimiento. Presupuesta 20-30% de la capacidad para ello.
• Ignorar la cola larga del 20% — los equipos con necesidades inusuales (ML training, monorepos, sistemas legacy) rodearán la plataforma si no puede acomodarlos.
• Sin escape hatches — forzar a cada equipo por el mismo pipeline sin alternativas crea plataformas sombra.
• Medir uptime en lugar de adopción — una plataforma que nadie usa es un cost center, no un acelerador.