Platform engineering: plataformas internas para que los equipos operen solos

Pedirle a un equipo de desarrollo que construya, despliegue y opere su propio servicio tiene mucho sentido: quien escribe el código es quien mejor entiende cómo falla. Pero si ese equipo además tiene que elegir una herramienta de CI/CD, escribir sus pipelines desde cero, configurar la observabilidad, pedir por ticket una base de datos y averiguar cómo se gestionan los secretos, la autonomía se convierte en sobrecarga. Cada equipo resuelve los mismos problemas a su manera, con resultados desiguales en seguridad y en fiabilidad.

Platform engineering es la disciplina que responde a ese problema: construir y operar una plataforma interna que ofrezca esas capacidades en autoservicio, con controles incluidos, para que los equipos de producto se concentren en su servicio. El TAG App Delivery de la CNCF le dedicó dos documentos públicos en 2023: el Platforms White Paper, en abril, y el Platform Engineering Maturity Model, en octubre. Este artículo se apoya en ambos.

Si tu organización está pasando a un modelo operativo orientado a producto, la plataforma es la pieza que hace viable que muchos equipos estables operen sin multiplicar el esfuerzo duplicado.

Qué es una plataforma interna

El white paper de la CNCF describe una plataforma como un conjunto integrado de capacidades, definido y presentado según las necesidades de sus usuarios, que en este caso son los equipos que construyen y operan aplicaciones. La palabra clave es "integrado": un listado de herramientas sueltas no es una plataforma.

El documento enumera atributos que distinguen una plataforma útil:

• Plataforma como producto: se diseña y evoluciona a partir de lo que necesitan sus usuarios, no de lo que el equipo de infraestructura quiere construir.
• Experiencia de usuario consistente a través de portales, APIs, línea de comandos o el propio entorno de desarrollo.
• Documentación e incorporación que permiten empezar sin depender de una persona concreta.
• Autoservicio: las capacidades se obtienen sin intervención manual del equipo de plataforma.
• Menor carga cognitiva: la complejidad de la implementación queda oculta detrás de interfaces simples.
• Opcional y componible: los equipos pueden usar las partes que necesitan.
• Segura por defecto: los controles de la organización vienen incluidos.

El diagrama muestra las capas habituales y quién trabaja en cada una.

Caminos dorados y autoservicio

Un camino dorado es una ruta recomendada y soportada para hacer algo frecuente: crear un servicio nuevo, publicar una API, desplegar un trabajo por lotes, conectar una base de datos. Combina una plantilla, la automatización que la pone en marcha y la documentación que explica las decisiones ya tomadas.

Por ejemplo, un camino dorado para un servicio web podría generar en minutos un repositorio con la estructura del proyecto, un pipeline con pruebas y análisis de seguridad, la instrumentación con OpenTelemetry ya configurada, paneles y alertas básicos, el registro del servicio en el catálogo y un primer despliegue a un entorno de pruebas. El equipo empieza a escribir lógica de negocio el primer día, no después de semanas de configuración.

Tres principios hacen que un camino dorado funcione:

• Es el camino más fácil, no el único. Un equipo con una necesidad distinta puede apartarse, pero asume el costo de operar su variante. Si muchos equipos se apartan, la señal es que el camino no sirve.
• Los controles van dentro. Escaneo de dependencias, gestión de secretos, registro de auditoría y políticas de red vienen en la plantilla. Cumplir es el resultado de seguir el camino, no un paso adicional.
• Se mantiene en el tiempo. Cuando cambia una versión o una política, el equipo de plataforma actualiza el camino y ofrece una forma de migrar los servicios existentes.

Los caminos dorados también simplifican el gobierno de cambios: un despliegue que pasa por un pipeline estándar con pruebas y evidencias automáticas es un buen candidato para un modelo de cambio preaprobado, como explicamos en habilitación de cambios sin burocracia. Y la instrumentación incluida en la plantilla es la base para tener aplicaciones observables, no solo infraestructura observable.

Capacidades mínimas

El white paper de la CNCF enumera trece dominios de capacidades posibles, desde portales hasta almacenamiento de artefactos. Ninguna organización necesita todos desde el principio. La siguiente tabla propone un mínimo razonable para una primera versión, con una señal concreta de que la capacidad está realmente disponible en autoservicio.

Capacidad	Qué ofrece	Señal de que está lista
Aprovisionamiento de entornos e infraestructura	Cómputo, redes, bases de datos y colas desde plantillas declarativas	Un equipo obtiene un entorno sin abrir un ticket
CI/CD	Pipelines estándar de construcción, pruebas y despliegue	Un servicio nuevo despliega a pruebas el primer día
Observabilidad	Logs, métricas y trazas con instrumentación y paneles por defecto	Cada servicio nuevo tiene panel y alertas básicas
Seguridad y políticas	Análisis de código y dependencias, políticas aplicadas en el pipeline	Las políticas se validan automáticamente antes de desplegar
Identidad y secretos	Gestión centralizada de secretos y credenciales de servicio	Ningún secreto vive en el repositorio ni en variables manuales
Portal y catálogo	Inventario de servicios, dueños, documentación y acceso a los caminos dorados	Se sabe quién es dueño de cada servicio sin preguntar

Detrás de muchas de estas capacidades hay automatización de infraestructura y configuración que ya existe en la organización. Reutilizarla con buenas prácticas de versionado y pruebas es más rápido que reconstruirla.

El equipo de plataforma

En el vocabulario de Team Topologies, el equipo de plataforma ofrece servicios internos que los equipos alineados al flujo consumen en modo "X como servicio". Eso tiene implicaciones prácticas:

• Tiene un responsable de producto. Alguien entrevista a los equipos usuarios, prioriza el backlog de la plataforma y decide qué no se construye.
• Publica compromisos de servicio. La plataforma es un servicio crítico: si el pipeline o el gestor de secretos cae, se detienen todos los equipos. Necesita objetivos de nivel de servicio, guardia y gestión de incidentes propios.
• Combina perfiles. Infraestructura, desarrollo, seguridad y experiencia de usuario. Un equipo formado solo por administradores tiende a construir herramientas para administradores.
• Facilita la adopción. Además de construir, acompaña temporalmente a los equipos que migran, en modo de facilitación, y aprende de sus dificultades.

Para muchas áreas de infraestructura y operaciones, este es el destino natural de parte del equipo actual: pasar de atender tickets a construir capacidades reutilizables. Lo tratamos en de administradores a SRE.

Cómo medir adopción y experiencia

Una plataforma que nadie usa no aporta valor, por bien construida que esté. El white paper de la CNCF propone medir en tres frentes:

• Satisfacción y productividad de los usuarios: usuarios activos y retención, encuestas de satisfacción y métricas de productividad.
• Eficiencia organizacional: tiempo desde que se solicita una capacidad hasta que está disponible, tiempo para llevar un servicio nuevo a producción y tiempo para que una persona nueva haga su primer cambio.
• Entrega de producto: las cuatro métricas de DORA (frecuencia de despliegue, tiempo de entrega de cambios, tiempo de restauración y tasa de fallos de los cambios) en los equipos que usan la plataforma.

Recomendamos empezar simple: una encuesta breve y periódica a los equipos usuarios, más datos de uso de cada camino dorado. La pregunta útil no es "¿cuántas herramientas tiene la plataforma?" sino "¿cuántos equipos la eligen y cuánto tiempo les ahorra?".

El Platform Engineering Maturity Model ayuda a ubicar a la organización. Evalúa cinco aspectos (inversión, adopción, interfaces, operaciones y medición) en cuatro niveles: provisional, operacionalizado, escalable y optimizado. En el aspecto de adopción, la progresión es reveladora: de un uso errático, a un empuje externo, a una atracción intrínseca y, finalmente, a la participación de los propios usuarios en la plataforma. El modelo aclara que no todas las organizaciones necesitan llegar al nivel más alto en todos los aspectos.

Errores comunes

Hay patrones que aparecen con frecuencia en iniciativas de plataforma y que conviene evitar desde el diseño:

1. Portal sin capacidades. Se publica un portal atractivo con un catálogo, pero detrás de cada botón sigue habiendo un ticket y una espera. El portal es la cara de la plataforma, no la plataforma.
2. Obligar en lugar de atraer. Imponer la plataforma por mandato genera adopción en el papel y desvíos en la práctica. Es mejor que el camino dorado sea claramente el más fácil y dejar que los resultados convenzan.
3. Construir todo antes de tener usuarios. Una plataforma diseñada durante un año sin equipos reales usándola suele resolver problemas que nadie tiene. Empieza con uno o dos equipos piloto y una sola ruta completa.
4. Tratarla como proyecto. Si el equipo se disuelve tras la primera versión, la plataforma envejece y los equipos vuelven a sus soluciones propias.
5. Dejar fuera a Seguridad y Cumplimiento. Si los controles no están en los caminos dorados, aparecerán después como revisiones manuales que anulan el autoservicio.
6. Automatizar la cola de tickets sin cambiarla. Convertir un procedimiento manual en un formulario que dispara un script es un avance, pero no es autoservicio si sigue requiriendo aprobación manual en cada paso. Para pasar de procedimientos manuales a automatización auditable, ver del runbook al playbook.

Como la plataforma concentra controles de seguridad, acceso a producción y evidencias de cambio, conviene validar su diseño con Arquitectura, Seguridad y Cumplimiento antes de abrirla a todos los equipos.