Situación del cliente
Entidad de capital markets española con 1.200 empleados gestionaba su plataforma de negociación y liquidación sobre 18 aplicaciones Java monolíticas desplegadas en máquinas virtuales on-premise con un proceso de release trimestral. Las ventanas de despliegue de 6 horas en fin de semana generaban fricción operativa y retrasaban la respuesta a cambios regulatorios, que en el sector de valores españoles llegan con una frecuencia y urgencia creciente (MIFID II, DORA, EMIR Refit).
El equipo de desarrollo tenía capacidad técnica para modernizar pero carecía de una plataforma de contenedores y de los procesos DevSecOps necesarios para hacerlo con las garantías de seguridad y disponibilidad que requiere una entidad supervisada por la CNMV. El CTO quería pasar de releases trimestrales a despliegues continuos sin exponer la plataforma de negociación a riesgos operativos durante la transición.
Retos
- Descomponer 18 aplicaciones monolíticas Java en microservicios sin interrumpir el servicio de negociación, que opera en horario de mercado con SLA de disponibilidad del 99,95%
- Diseñar una plataforma AKS con segregación de entornos (desarrollo, preproducción, producción) que cumpla con los requerimientos de aislamiento y seguridad de la CNMV y DORA
- Implementar un pipeline de CI/CD con controles de seguridad integrados (SAST, DAST, escaneo de imágenes de contenedor, firma de artefactos) sin ralentizar el ritmo de desarrollo
- Migrar el equipo de operaciones de un modelo de gestión de VMs a un modelo de plataforma Kubernetes sin pérdida de capacidad operativa durante la transición
- Gestionar la coexistencia temporal de aplicaciones monolíticas (on-premise) y microservicios (AKS) con comunicación bidireccional durante la fase de migración
Solución implementada
- Azure Kubernetes Service con topología multi-cluster: cluster dedicado de producción (node pools con autoscaling por tipo de carga), cluster de preproducción aislado en suscripción Azure separada, y cluster de desarrollo compartido por equipos. Azure Policy y Azure RBAC para governance centralizada de los tres clusters desde un único control plane
- GitOps con Flux CD: el estado deseado de cada cluster se gestiona desde repositorios Git. Cada cambio en el repositorio dispara la reconciliación automática del cluster. Los rollbacks se hacen con un revert de git — sin scripts manuales, sin coordinación entre equipos, con audit trail completo por commit
- Service mesh con Istio: comunicación segura (mTLS) entre microservicios sin modificar el código de aplicación, traffic management para canary deployments y circuit breaking, y observabilidad de red end-to-end con Kiali y Jaeger para trazas distribuidas
- Pipeline DevSecOps en Azure DevOps: SAST con SonarQube, escaneo de dependencias con Snyk, escaneo de imágenes de contenedor con Defender for Containers, firma de imágenes con Notation y verificación de integridad en el despliegue. Ningun artefacto sin firma llega a producción
- Strangler Fig pattern para la migración: cada aplicación monolítica se descompone incrementalmente. Un API gateway (Azure API Management) enruta el tráfico entre la parte legacy (on-premise) y los nuevos microservicios (AKS) durante la coexistencia. Cuando el 100% de funcionalidad de una aplicación migra, el monolito se desconecta. Sin big bang, sin ventana de migración de fin de semana
Ventajas para el cliente
Patrón de arquitectura
Pipeline DevSecOps completo para modernización de capital markets a AKS: seguridad integrada en cada fase del CI/CD (SAST, imagen scanning, DAST), Istio para mTLS entre microservicios, OPA Gatekeeper para policies runtime y Workload Identity para eliminar secretos en código. 18 aplicaciones monolíticas modernizadas en 14 meses sin downtime.
- Workload Identity en lugar de Service Principals con secretos — en capital markets con auditorías frecuentes, eliminar secretos estáticos del código es un requisito de compliance, no solo una buena práctica de seguridad.
- Istio en modo ambient antes que sidecar en servicios nuevos — el overhead de sidecar proxy consume 15-20% de CPU en microservicios financieros de alta frecuencia. El modo ambient elimina ese coste manteniendo mTLS y observabilidad.
- OPA Gatekeeper: empezar con políticas en modo "warn" antes de "enforce" — aplicar enforcement directo en producción rompe deployments existentes. El modo warn permite medir el impacto antes de bloquear.
- SBOM generado y firmado en cada build — los auditores de capital markets cada vez más exigen Software Bill of Materials como evidencia de supply chain security. Generarlo desde el inicio es trivial; retroactivamente es imposible.
- Canary deployments obligatorios para cambios en servicios de liquidación — en capital markets, un bug en producción durante horas de mercado tiene consecuencias regulatorias. El 10% de tráfico de canary detectó 3 bugs críticos en este proyecto.
- Defender for Containers como capa de detección runtime — los controles de pipeline son necesarios pero no suficientes. Falco + Defender detectaron en este proyecto un intento de exfiltración que pasó todos los gates del CI/CD.