Situación del cliente
El operador postal nacional de España —con más de 50.000 empleados, operaciones logísticas en tiempo real y una red de distribución que cubre todo el territorio nacional— aceleraba su transformación digital para competir con operadores privados de última milla y plataformas de e-commerce. El crecimiento del negocio de paquetería exigía capacidad de lanzamiento de nuevos servicios digitales en días, no en meses.
La infraestructura cloud existente era heterogénea: Azure como nube primaria, algunas cargas en servicios adicionales, sin una plataforma de contenedores unificada y con pipelines de despliegue manuales que tardaban semanas desde el commit hasta producción. El modelo de costes cloud era opaco y sin atribución por servicio, lo que dificultaba las decisiones de inversión en nuevas capacidades digitales.
Retos
- Diseñar un servicio de gestión integral de nube pública (Azure primario + multicloud) que cubriera la operación de la plataforma, el ciclo de vida de las aplicaciones y el gobierno de costes en un único modelo de servicio
- Proponer la arquitectura de la plataforma Kubernetes (AKS) que permitiera a los equipos de desarrollo desplegar nuevos servicios de rastreo, notificación y comercio electrónico en horas, con controles de seguridad integrados
- Definir el modelo DevSecOps para equipos de desarrollo con distintos niveles de madurez técnica, asegurando que los controles de seguridad no frenaran la velocidad de entrega
- Diseñar el ITSM integrado con los sistemas de gestión de incidencias existentes del operador, asegurando continuidad en los procesos de soporte sin romper los flujos operativos ya establecidos
- Construir el marco FinOps que permitiera atribuir el gasto cloud por área de negocio (paquetería, correspondencia, servicios financieros postales) para la toma de decisiones de inversión
Solución implementada
- Plataforma AKS gestionada: Azure Kubernetes Service con node pools diferenciados por criticidad de carga (servicios de rastreo en tiempo real vs. servicios de backoffice), autoscaling horizontal y vertical, y Azure Policy para governance de la plataforma de contenedores
- Pipeline DevSecOps unificado: Azure DevOps como plataforma única de CI/CD con gates de seguridad automatizados (SAST, escaneo de dependencias, análisis de imágenes de contenedor), reducción del proceso de despliegue a menos de 2 horas desde el merge en main hasta producción
- ITSM integrado: conector bidireccional entre el sistema de gestión de incidencias del operador y Azure Monitor, con automatización de creación de tickets para alertas críticas y dashboards de estado de servicio para los equipos de operaciones
- Marco FinOps con showback por área: Azure Cost Management con etiquetado obligatorio vía Policy, dashboards de gasto por área de negocio en Power BI, y alertas de presupuesto con escalado automático a los responsables de cada servicio digital
- Modelo de operación multicloud: capa de abstraccción de gestión que permitía operar la nube primaria Azure y cargas adicionales desde un único panel de control, con procedimientos unificados de incident management y change management
Ventajas para el cliente
Semanas → Horasreducción del time-to-market de nuevos servicios digitales mediante pipelines automatizados, permitiendo responder a cambios del mercado de paquetería en tiempo real
Visibilidad de costesprimer modelo de atribución de gasto cloud por área de negocio, que permitió identificar servicios con ROI negativo y redirigir inversión hacia capacidades digitales prioritarias
Seguridad integradacontroles DevSecOps integrados en el pipeline que redujeron las vulnerabilidades encontradas en producción sin incrementar los tiempos de entrega de los equipos de desarrollo
Operación unificadamodelo de gestión multicloud que eliminó la fragmentación operativa entre equipos, reduciendo el número de herramientas de monitorización de 7 a 2 plataformas integradas
Patrón de arquitectura
// ARCH 20 · Azure + AWS · Multicloud
Multicloud Postal Operations — AKS + EKS + GitOps
Plataforma multicloud para operador postal con 50.000 empleados: AKS en Azure para servicios digitales a empleados y ciudadanos, EKS en AWS para el motor de logística y tracking de envíos, GitOps con Flux como fuente única de verdad para ambos clusters, FinOps integrado en ambas nubes y observabilidad unificada. Reducción del time-to-market de semanas a horas.
AKS (Azure)EKS (AWS)Flux GitOpsDatadogFinOps Multicloud
// Consideraciones de despliegue · Multicloud WAF
- GitOps como fuente única de verdad para los dos clusters — en multicloud, la deriva de configuración entre AKS y EKS es el problema operativo más frecuente. Flux sincronizando desde el mismo repositorio elimina la divergencia que generan los despliegues manuales.
- Separar workloads por cloud según ventaja competitiva, no por comodidad — en este proyecto, el motor de routing postal usa características específicas de AWS (EKS + SQS) porque el equipo logístico ya tenía expertise AWS. Los servicios digitales van a Azure donde reside el Active Directory corporativo.
- Tagging multicloud consistente desde el sprint 0 — la facturación de AKS en Azure y EKS en AWS usa sistemas de etiquetado distintos. Sin un estándar de tagging corporativo aplicado con IaC en ambas nubes, el chargeback por línea de negocio es imposible.
- Observabilidad unificada con Datadog/Dynatrace como capa agnóstica — usar Azure Monitor para AKS y CloudWatch para EKS crea silos de visibilidad que impiden correlacionar incidentes cross-cloud. Una plataforma de observabilidad unificada es cara pero necesaria.
- Network policy en ambos clusters como control de seguridad obligatorio — en AKS, Azure Network Policy o Calico; en EKS, VPC CNI con security groups. Sin network policy, la microsegmentación entre microservicios es inexistente y cualquier pod comprometido puede atacar el cluster completo.
- FinOps unificado: comparar coste real de workloads equivalentes en ambas nubes — en este proyecto, el análisis FinOps unificado reveló que tres servicios que corrían en AWS eran 40% más baratos en Azure. La visibilidad multicloud genera decisiones de migración de workload basadas en datos, no en preferencias.
CosteExcelencia OperacionalFiabilidadRendimiento