Platform Engineering vs DevOps: qué cambió realmente (y qué no)

El cambio de DevOps a Platform Engineering

DevOps dijo "tú lo construyes, tú lo operas." Cada desarrollador gestiona su propia infraestructura, despliega sus propios servicios, configura su propio monitoring. En teoría, esto crea sentido de propiedad. En la práctica, crea 15 formas diferentes de desplegar un servicio, 8 configuraciones de monitoring diferentes, y cada equipo reinventando el mismo pipeline CI/CD.

Platform engineering es la corrección. En lugar de que cada equipo construya infraestructura desde cero, un equipo de plataforma proporciona herramientas con opinión definida y de autoservicio que hacen que lo correcto sea fácil y lo incorrecto sea difícil.

El cambio es real pero sobrevendido. Para equipos de menos de 30 ingenieros, platform engineering suele ser sobrecarga. Para equipos de más de 50, es necesario. Este artículo cubre los patrones prácticos. Para ver cómo desplegamos infraestructura, consulta nuestra guía de IaC y la guía de Kubernetes.

Qué es realmente Platform Engineering

Platform engineering no es una herramienta. No es Backstage. No es Kubernetes. Es un enfoque: construir herramientas internas que hagan a los desarrolladores productivos sin requerir que se conviertan en expertos en infraestructura.

La métrica clave: tiempo hasta el primer deploy de un nuevo servicio. Si un desarrollador necesita 2 días para ir de "necesito un nuevo servicio" a "está corriendo en staging", tu plataforma tiene un problema. Si toma 15 minutos, tu plataforma funciona.

Golden Paths

Un golden path es un template con opinión definida para crear un nuevo servicio. Incluye todo lo que un desarrollador necesita: estructura del proyecto, pipeline CI/CD, Dockerfile, manifiestos de Kubernetes, configuración de monitoring y documentación.

golden-path-typescript-api/
├── src/
│   ├── index.ts                    # Punto de entrada con health check
│   ├── routes/                     # Definiciones de rutas
│   └── services/                   # Lógica de negocio
├── test/
│   ├── unit/
│   └── integration/
├── Dockerfile                      # Build multi-stage optimizado
├── .github/workflows/
│   └── ci-cd.yaml                  # Build, test, push, deploy
├── kubernetes/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── kustomization.yaml
│   └── overlay/
│       ├── staging/
│       └── production/
├── monitoring/
│   ├── alerts.yaml                 # Reglas de alerta estándar
│   └── dashboard.json              # Template de dashboard Grafana
├── docs/
│   └── runbook.md                  # Template de runbook operacional
├── .env.example
├── package.json
├── tsconfig.json
└── README.md

Un desarrollador ejecuta platform create-service --name my-api --template typescript-api, responde 5 preguntas (nombre del servicio, equipo, si necesita base de datos, público o interno), y obtiene un proyecto completamente funcional con CI/CD, monitoring y manifiestos de despliegue. Primer deploy en 15 minutos.

Principios del Golden Path

Qué hace un buen vs mal Golden Path

Infraestructura de autoservicio

Los desarrolladores no deberían necesitar crear un ticket para obtener una base de datos, una instancia Redis o un nuevo namespace de Kubernetes. Autoservicio significa que pueden provisionar lo que necesitan a través de una UI, CLI o API.

// Platform CLI: provisionar una base de datos PostgreSQL
// $ platform db create --name my-api-db --size small --env staging
interface DatabaseRequest {
    name: string;
    size: 'small' | 'medium' | 'large';  // Con opinión: 3 tamaños, no specs arbitrarios
    environment: 'dev' | 'staging' | 'production';
    team: string;
    backupRetention: number;  // Por defecto: 7 días staging, 30 días production
}

// Detrás de escena: Terraform se ejecuta, crea la instancia RDS,
// almacena credentials en Secrets Manager, crea un K8s secret,
// agrega dashboard de monitoring, notifica al equipo

Qué ofrecer en autoservicio

El límite: autoservicio para recursos con alcance de equipo. Basado en solicitud para recursos que afectan a toda la organización.

Portales internos para desarrolladores

Un portal interno para desarrolladores es un catálogo de todos los servicios, sus propietarios, sus APIs, sus runbooks y su estado de salud. Backstage (de Spotify) es el más conocido, pero no es la única opción.

Qué debe mostrar un portal

Backstage vs Alternativas

Para equipos de menos de 30 ingenieros, Backstage es overkill. Un repositorio Git bien organizado con archivos README, un wiki Notion compartido y una hoja de cálculo simple de catálogo de servicios cubre el 80% de la necesidad.

Para equipos de más de 50 ingenieros, el problema del catálogo se vuelve real. Se crean servicios y se olvidan. Los propietarios se van y nadie sabe quién mantiene qué. Un portal con seguimiento de propiedad y dashboards de salud se vuelve esencial.

El problema de la documentación

Nadie lee tu wiki. No es un problema de personas. Es un problema de ubicación. La documentación que vive separada del código que describe se vuelve obsoleta en semanas.

Documentación que funciona

Architecture Decision Records (ADRs)

Cada decisión técnica significativa recibe un ADR:

# ADR-003: Usar PostgreSQL como base de datos principal

## Estado: Aceptado

## Contexto
Necesitamos una base de datos para el nuevo servicio. Opciones consideradas: PostgreSQL, MySQL, DynamoDB.

## Decisión
PostgreSQL 15 a través del provisioning de base de datos de autoservicio de la plataforma.

## Consecuencias
- Las herramientas estándar (backups, monitoring, migraciones) funcionan directamente
- El equipo no necesita experiencia en DynamoDB
- Latencia ligeramente mayor que DynamoDB para patrones de acceso clave-valor (aceptable)

Los ADRs previenen re-debatir las mismas decisiones. Cuando un nuevo miembro del equipo pregunta "por qué PostgreSQL?", la respuesta está en el repo, no en la memoria de alguien.

Medir la experiencia del desarrollador

Si estás invirtiendo en una plataforma, mide si realmente está ayudando:

Las primeras cuatro son métricas DORA. Las últimas tres son específicas de plataforma. Haz seguimiento de todas. Si el time-to-first-deploy mejora pero la satisfacción del desarrollador baja, la plataforma está agregando complejidad sin valor.

Cuándo Platform Engineering es sobrecarga

Platform engineering no es gratis. Un equipo de plataforma cuesta 2-5 ingenieros a tiempo completo. Los golden paths necesitan mantenimiento. Las herramientas de autoservicio necesitan desarrollo y soporte. Un portal necesita contenido.

No construyas una plataforma cuando

• Tu equipo tiene menos de 20 ingenieros (la sobrecarga excede el beneficio)
• Tienes menos de 5 servicios (no hay suficiente oportunidad de estandarización)
• Eres una startup que podría pivotar (la plataforma se desperdiciará)
• Tu proceso de ingeniería ya es rápido (si el time-to-deploy ya es de 30 minutos, no necesitas un equipo de plataforma para mejorarlo)

Construye una plataforma cuando

• Tienes 50+ ingenieros desplegando 10+ servicios
• La creación de un nuevo servicio toma más de un día
• Los equipos reinventan los mismos patrones de infraestructura
• La guardia es dolorosa porque cada servicio tiene monitoring diferente
• La satisfacción del desarrollador es baja por fricción de infraestructura

La plataforma mínima viable para un equipo de 30-50 personas:

1. Un template golden path (el tipo de servicio más común)
2. Template de pipeline CI/CD (compartido, parametrizado)
3. Monitoring estándar (dashboards Grafana auto-provisionados)
4. Catálogo de servicios (aunque solo sea una hoja de cálculo)
5. Una guía de plataforma de una página ("cómo crear un nuevo servicio")

Eso es todo. Sin Backstage, sin portal custom, sin infraestructura de autoservicio. Solo templates y estándares. Agrega complejidad cuando el equipo supere el enfoque simple.

Errores comunes

1. Construir una plataforma antes de tener estandarización. Si cada servicio usa un lenguaje, framework y método de despliegue diferentes, una plataforma no puede ayudar. Estandariza primero, luego construye la plataforma.

2. Backstage antes de 50 ingenieros. Backstage es poderoso pero complejo. Para equipos más pequeños, el costo de setup y mantenimiento excede el beneficio.

3. Golden paths que nunca se actualizan. Un template de hace 2 años con dependencias obsoletas y patrones deprecados hace más daño que bien. Mantenlo como un producto.

4. Todo en autoservicio. Los roles IAM y los cambios de red no deberían ser autoservicio. El blast radius de un error es demasiado grande.

5. Medir actividad, no resultados. "Construimos 15 funcionalidades de plataforma" no es éxito. "El time-to-first-deploy bajó de 2 días a 30 minutos" es éxito.

6. Ignorar la satisfacción del desarrollador. Una plataforma que fuerza a los desarrolladores en patrones que odian será evitada. Habla con tus usuarios (los desarrolladores) regularmente.

7. Sin documentación. Una plataforma de autoservicio sin documentación es solo otro tipo de caja negra.

Puntos clave

• Platform engineering no es una herramienta, es un enfoque. Construye herramientas internas que hagan a los desarrolladores productivos sin requerir experiencia en infraestructura. El golden path es el producto central.

• El time to first deploy es la métrica clave. Si un desarrollador puede ir de una idea a un servicio funcional en 15 minutos, la plataforma funciona. Si toma 2 días, no.

• Empieza simple. Un golden path, un template CI/CD, monitoring estándar. Agrega complejidad cuando el enfoque simple no sea suficiente. La mayoría de los equipos de menos de 30 ingenieros no necesitan Backstage.

• La documentación vive con el código. Docs de API auto-generadas, runbooks en el repo, ADRs para decisiones. Las páginas wiki se vuelven obsoletas. Los docs en el repo se mantienen actualizados.

• Mide resultados, no actividad. Métricas DORA más satisfacción del desarrollador. Si los números no mejoran, la inversión en plataforma no está funcionando.

• El equipo de plataforma es un equipo de producto. Sus usuarios son los desarrolladores. Su producto es la plataforma interna. Necesitan bucles de feedback, investigación de usuarios e iteración, igual que cualquier equipo de producto.

Construimos plataformas internas y herramientas para desarrolladores como parte de nuestros servicios cloud y nuestra práctica de consultoría. Si necesitas ayuda con tu estrategia de platform engineering, habla con nuestro equipo o solicita un presupuesto. Consulta también nuestra página de metodología para ver cómo abordamos la cultura de ingeniería.