01
Qué debería resolver platform engineering
Platform engineering es la disciplina de diseñar y operar un producto interno que ayuda a los desarrolladores a entregar software de forma segura. La plataforma no es solo un clúster de Kubernetes ni una colección de módulos Terraform: es el camino soportado desde un repositorio hasta un servicio fiable en producción.
Una plataforma útil elimina decisiones repetidas, conserva vías de escape y convierte el camino seguro en el más sencillo. Su éxito se mide por los resultados de los equipos y la calidad operativa, no por la cantidad de herramientas instaladas.
- Reducir el tiempo y la carga cognitiva necesarios para crear, desplegar y operar un servicio.
- Codificar una vez los valores por defecto de seguridad, identidad, red y observabilidad.
- Dar a los equipos ownership, feedback y caminos de recuperación claros ante cambios en producción.
02
Un modelo operativo de cinco capas
Tratar la plataforma como una pila de responsabilidades mantiene las herramientas subordinadas a la experiencia que se quiere ofrecer.
-
01
AWS Organizations · IAM · VPC · KMS
Base cloud
Cuentas, identidad, redes, cifrado, presupuestos y auditoría forman el límite que hereda cada carga.
-
02
Terraform · políticas · estado remoto
Aprovisionamiento
Módulos Terraform versionados exponen entradas deliberadas y generan entornos revisables y reproducibles.
-
03
GitHub Actions · OIDC · ECR
Entrega
Un pipeline estándar construye una vez, demuestra procedencia y promociona un artefacto inmutable.
-
04
EKS o K3s · ECS · servicios gestionados
Runtime
El runtime se adapta a la carga. Kubernetes aporta valor cuando su modelo operativo compensa el coste; ECS o servicios gestionados pueden ser mejores por defecto.
-
05
Golden paths · runbooks · scorecards
Interfaz para desarrollo
Plantillas, documentación, metadatos y acciones self-service convierten capacidades de infraestructura en un producto útil.
03
Un camino de referencia en AWS
Una plataforma pequeña puede empezar con un único camino pavimentado y crecer solo donde aparezca demanda real.
- 1
Repositorio
El servicio nace desde una plantilla mantenida con ownership, health checks y metadatos de despliegue.
- 2
Identidad
GitHub Actions intercambia claims OIDC por un rol IAM limitado; las claves AWS de larga duración quedan fuera de CI.
- 3
Artefacto
El pipeline prueba, escanea y publica una imagen inmutable en ECR, etiquetada con release y commit SHA.
- 4
Estado deseado
Un cambio separado registra la versión de imagen, la política de recursos y los valores del entorno.
- 5
Reconciliación
Argo CD compara Git con el clúster, aplica el estado declarado y muestra drift o health checks fallidos.
- 6
Operación
Métricas, logs, alertas, backups y un rollback probado cierran el ciclo tras el despliegue.
04
El ciclo de entrega GitOps
GitOps aporta valor cuando crea un plano de control legible, no cuando solo añade otra herramienta de despliegue.
- Git registra la versión deseada y la revisión que la aprobó.
- El reconciliador informa del drift e impide que cambios manuales silenciosos se vuelvan permanentes.
- El rollback revierte el estado deseado a una imagen conocida; la recuperación de datos sigue siendo un procedimiento separado y probado.
- Los secretos se referencian desde un almacén externo y se materializan con límites explícitos de ownership y rotación.
05
Checklist del golden path
Un golden path debe ser suficientemente opinado para resultar útil y suficientemente pequeño para que un equipo pueda mantenerlo.
- Plantilla de repositorio con convenciones de build, pruebas, ownership y actualización de dependencias.
- Acceso cloud mediante OIDC y un rol por responsabilidad de despliegue.
- Módulos de infraestructura reutilizables con ejemplos, versionado y validación de políticas.
- Health, readiness y apagado ordenado definidos antes de producción.
- Métricas, logs estructurados, dashboards y alertas accionables por defecto.
- Requests, limits, comportamiento ante interrupciones y expectativas de escalado.
- Backups automáticos junto a un ejercicio de restore, no solo una subida correcta.
- Runbook de rollback que diferencia aplicación, configuración y recuperación de datos.
06
Señales que importan
La adopción de plataforma no es una métrica de vanidad. Hay que combinar entrega, fiabilidad y experiencia de desarrollo.
- Lead time
- Tiempo desde que se aprueba un cambio hasta que el despliegue está sano en producción.
- Recuperación
- Tiempo necesario para restaurar el servicio tras una release fallida o un incidente.
- Adopción
- Porcentaje de servicios elegibles que usan el camino soportado sin una migración forzada.
- Fricción
- Pasos manuales, peticiones de soporte y excepciones repetidas para entregar un cambio normal.
07
Errores habituales
La mayoría de problemas de plataforma son problemas de producto y ownership expresados mediante infraestructura.
Empezar por un portal
Un catálogo pulido no compensa un aprovisionamiento poco fiable ni un ownership operativo confuso.
Convertir Kubernetes en el objetivo
Un clúster es una opción de runtime; por sí solo no crea self-service, estándares ni soporte.
Ocultar todos los detalles
Las abstracciones deben reducir repetición y conservar visibilidad suficiente para diagnosticar producción.
Ignorar la migración
Una plataforma elegante sin una estrategia incremental de adopción termina sin usuarios.
Medir actividad de herramientas
El número de pipelines o módulos dice poco sobre si la entrega es más rápida o segura.
08
Preguntas prácticas
¿Necesita toda empresa un equipo de plataforma?
No. Se puede empezar con convenciones compartidas y un owner claro. Un equipo dedicado tiene sentido cuando el trabajo repetido frena materialmente a varios equipos de producto.
¿Debe Kubernetes ser el runtime por defecto?
Solo cuando la diversidad de cargas, las necesidades de scheduling y la capacidad de la organización justifican operarlo.
¿Por dónde empieza un equipo pequeño?
Por un recorrido frecuente, normalmente desplegar un servicio web, y hacerlo fiable de extremo a extremo. Las siguientes capacidades deben responder a fricción observada.
¿Qué hace que una plataforma esté lista para producción?
Ownership definido, identidad segura, entrega observable, límites de capacidad, backups, restores probados y procedimientos de recuperación que funcionen bajo presión.
