El platform engineering es la práctica de construir herramientas internas e infraestructura de autoservicio que hacen productivos a los desarrolladores. Bien hecho, elimina el cuello de botella de "abre un ticket y espera 3 semanas" entre desarrollo y operaciones. Mal hecho, crea otra capa de burocracia que nadie usa.
Por qué platform engineering, por qué ahora
La promesa de DevOps era "you build it, you run it". La realidad es que la mayoría de los desarrolladores no quieren gestionar manifiestos de Kubernetes, módulos de Terraform y pipelines de CI/CD. Quieren entregar funcionalidades.
El platform engineering cubre ese hueco: un equipo dedicado construye los golden paths que siguen los desarrolladores, abstrayendo la complejidad de la infraestructura y preservando la flexibilidad para los equipos que la necesitan.
El detonante suele ser la escala. Con 5 ingenieros, todo el mundo puede entrar al servidor por SSH. Con 50 ingenieros, necesitas entornos estandarizados. Con 200, necesitas autoservicio.
Qué hace un equipo de plataforma
Un equipo de plataforma suele ser responsable de:
Portal de autoservicio para desarrolladores — Una UI o CLI donde los desarrolladores pueden aprovisionar entornos, bases de datos, colas de mensajes y monitorización sin abrir tickets. "Necesito un entorno de staging" debería llevar 5 minutos, no 5 días.
Plantillas de golden path — Plantillas de proyecto con convenciones ya decididas que incluyen CI/CD, monitorización, logging y valores de seguridad por defecto. Los servicios nuevos nacen con las buenas prácticas integradas, no añadidas después.
Plataforma Interna para Desarrolladores (IDP) — La capa que une Git, CI/CD, el registro de contenedores, Kubernetes, la monitorización y la gestión de secretos en un flujo de trabajo coherente. Backstage (de Spotify) es el framework open source más popular para esto.
Abstracción de la infraestructura — En lugar de exponer Terraform en bruto a los desarrolladores, el equipo de plataforma ofrece abstracciones de más alto nivel: "dame una base de datos PostgreSQL" en lugar de "aprovisiona una instancia RDS con estos 47 parámetros".
Base de observabilidad — Logging, métricas y tracing centralizados que cada servicio obtiene automáticamente. Los desarrolladores no deberían tener que configurar el scraping de Prometheus ni la recogida de logs de Loki para cada servicio.
Cómo empezar: los primeros 90 días
Días 1-30: Descubrimiento - Entrevista a 10-15 desarrolladores: ¿qué les frena? ¿Qué desearían que existiera? - Mapea el recorrido actual del desarrollador: del commit a producción. ¿Dónde están los cuellos de botella? - Audita las herramientas existentes: ¿qué herramientas usan ya los equipos? ¿Qué está duplicado? - Identifica los 3 principales puntos de dolor por frecuencia e impacto
Días 31-60: Victorias rápidas - Resuelve el punto de dolor #1 con la solución más sencilla posible - Estandariza las plantillas de CI/CD para los 3 tipos de servicio más comunes - Monta un entorno de desarrollo compartido que los desarrolladores puedan aprovisionar por sí mismos - Documéntalo todo en un portal para desarrolladores (aunque al principio sea solo una wiki en Notion)
Días 61-90: Cimientos - Despliega Backstage (o equivalente) como portal central para desarrolladores - Construye la primera plantilla de golden path (p. ej., "nuevo microservicio" con CI/CD, monitorización y despliegue) - Implementa el aprovisionamiento de bases de datos en autoservicio - Mide: encuesta de satisfacción de los desarrolladores + tiempo hasta el primer deploy de los servicios nuevos
Composición del equipo
Un equipo de plataforma inicial (4-6 personas) debería incluir:
- 1 Tech Lead de plataforma — Marca la dirección técnica, toma las decisiones de arquitectura y protege al equipo del ruido organizativo
- 2 ingenieros de backend/infraestructura — Construyen los componentes de la plataforma (módulos de Terraform, operadores de Kubernetes, capa de API)
- 1 ingeniero DevOps/SRE — Gestiona el CI/CD, la observabilidad y la infraestructura de la propia plataforma
- 1 ingeniero de frontend (opcional) — Construye la UI del portal de autoservicio si vas más allá de las herramientas CLI
No empieces con 1 persona. Un "platform engineer" en solitario se convierte en un cuello de botella, no en una plataforma. Necesitas al menos 3 personas para mantener el ritmo mientras atiendes interrupciones.
Errores comunes
Construir antes de escuchar. Si construyes un portal de autoservicio que nadie ha pedido, nadie lo usará. Empieza por entrevistas con los desarrolladores, no por diagramas de arquitectura.
Imponer la adopción. Las mejores plataformas se adoptan porque facilitan la vida a los desarrolladores, no porque la dirección las haya impuesto. Si los desarrolladores esquivan tu plataforma, el problema es la plataforma.
Abstraer de más. No intentes abstraerlo todo. Empieza por los 3 flujos de trabajo más comunes y hazlos excepcionalmente bien. Siempre puedes añadir más después.
Ignorar la operación. Una plataforma difícil de depurar, actualizar o escalar es un pasivo. Trata tu plataforma con el mismo rigor que los servicios de producción: monitorización, SLO, respuesta a incidentes.
Sin ciclo de feedback. Programa sesiones mensuales de feedback con tus usuarios (los desarrolladores). Mide el NPS. Prioriza según el dolor real, no según funcionalidades imaginadas.
Cómo medir el éxito
Haz seguimiento de estas métricas cada trimestre:
- Tiempo hasta el primer deploy — ¿Cuánto pasa desde "proyecto nuevo" hasta "funcionando en producción"? Objetivo: menos de 1 día.
- Satisfacción de los desarrolladores (NPS) — Haz encuestas a tus desarrolladores. Una puntuación superior a 30 significa que lo estás haciendo bien.
- Tasa de adopción del autoservicio — ¿Qué porcentaje del aprovisionamiento de entornos pasa por la plataforma frente a tickets manuales?
- Volumen de tickets — ¿Disminuyen los tickets de infraestructura a medida que aumenta el autoservicio?
- Lead time de los cambios — ¿Está entregando más rápido la organización de ingeniería en su conjunto?
Conclusión
El platform engineering no es una elección tecnológica — es una inversión organizativa en la productividad de los desarrolladores. Las empresas que lo hacen bien ven mejoras drásticas en la frecuencia de despliegue, la satisfacción de los desarrolladores y la retención de ingenieros. Empieza en pequeño, escucha a tus usuarios, mídelo todo e itera rápido. El objetivo no es una plataforma perfecta — es una plataforma 10x mejor que lo que los desarrolladores tenían ayer.