Modernització d'infraestructura amb Kubernetes
Una gran entitat bancària espanyola necessitava modernitzar la seva infraestructura crítica cap a una arquitectura de contenidors híbrida, sense interrompre els serveis en producció.
Repte
Infraestructura legacy amb serveis crítics que no podien aturar-se. Necessitat de modernitzar cap a contenidors i cloud mantenint operativa la plataforma bancària en tot moment.
Solució
Desplegament per fases amb RKE2 i Rancher on-premise, extensió a AWS EKS, adopció de GitOps amb Rancher Fleet i observabilitat completa amb Prometheus, Grafana i Loki.
Tecnologies
- Kubernetes / RKE2 / Rancher
- AWS EKS, ALB, RDS, S3
- GitOps / Helm / Kustomize
- Prometheus / Grafana / Loki
Contexto
Una gran entidad bancaria española partía de un entorno de infraestructura fragmentado, con procesos manuales que limitaban la agilidad operativa, la capacidad de escalar bajo demanda y la resiliencia de sus servicios críticos. Con cargas HPC y sistemas esenciales para el negocio, necesitaba una base tecnológica robusta, más flexible y automatizada.
Los objetivos fijados con el cliente fueron cinco: modernizar la infraestructura con una plataforma de orquestación unificada, garantizar alta disponibilidad para los sistemas críticos, permitir escalabilidad automática sin sobredimensionamiento, mejorar la observabilidad y la trazabilidad de extremo a extremo, y aumentar la seguridad del entorno reduciendo los errores operativos.
El reto
Antes de iniciar la modernización, la organización se enfrentaba a tres limitaciones técnicas y operativas:
- Entorno fragmentado y poco escalable: dificultad para operar de forma unificada entre on-premise y cloud, con limitaciones para escalar servicios de forma dinámica.
- Procesos manuales con alta dependencia operativa: despliegues lentos (hasta 45 minutos), propensos a errores y con baja trazabilidad, que generaban cuellos de botella y consumo de recursos innecesario.
- Falta de visibilidad y resiliencia en servicios críticos: ausencia de herramientas de observabilidad y una arquitectura con riesgo ante fallos que comprometía la estabilidad de sistemas clave.
Enfoque por fases
La modernización se abordó con un enfoque progresivo, diseñado para no interrumpir los servicios críticos del negocio. La plataforma se construyó sobre Kubernetes como eje central de orquestación, en seis etapas claramente definidas.
-
01
Análisis y diseño
Evaluación de workloads, definición de la arquitectura, selección de tecnologías y dimensionamiento inicial.
-
02
Prueba de concepto
Despliegue inicial on-premise con RKE2 y Rancher, validando entornos HPC y servicios esenciales.
-
03
Extensión a AWS
Implementación de clústeres en AWS (EKS y RKE2 sobre EC2), integrando servicios como ALB, RDS y S3 con conectividad híbrida.
-
04
Automatización y CI/CD
Adopción de GitOps con Rancher Fleet y despliegues declarativos mediante Helm y Kustomize.
-
05
Observabilidad y trazabilidad
Incorporación de Prometheus, Grafana y Loki para monitorización, alertas y logs centralizados.
-
06
Producción y soporte
Migración completa de servicios, validación funcional, puesta en marcha y soporte operativo continuo.
Arquitectura y estrategia
La estrategia se diseñó para responder a las tres necesidades del sector: continuidad, escalabilidad y control. Se optó por una arquitectura híbrida que combina entornos on-premise y cloud, orquestada desde una única consola de gestión, lo que permitió mantener el control sin sacrificar la capacidad de escalar dinámicamente.
La adopción de GitOps y de herramientas de CI/CD eliminó tareas manuales, redujo errores y facilitó ciclos de despliegue más rápidos y predecibles. La monitorización continua y las alertas en tiempo real fueron fundamentales para garantizar trazabilidad, rendimiento y cumplimiento.
Resultados medibles
La elección de Kubernetes como base tecnológica no fue casual: su capacidad para orquestar contenedores de forma eficiente, escalar automáticamente según la carga y adaptarse a entornos híbridos lo convirtió en la solución para los retos del proyecto. Resumen de los principales resultados tras la implementación:
| Indicador | Antes | Después |
|---|---|---|
| Tiempo de despliegue | ~45 minutos | ~3-5 minutos (≈ −90 %) |
| Disponibilidad de servicios | 95 % | > 99,99 % (+4,95 puntos) |
| Escalabilidad | Manual | Automática, dinámica |
| Coste operativo | Alto | Optimizado (≈ −30 %) |
| Tiempo de respuesta (web/API) | 200-300 ms | 50-120 ms (≈ −60 %) |
Cifras agregadas y anonimizadas por acuerdo de confidencialidad. Fuente: proyectos de Vermont Solutions.
Lecciones aplicables
- Se eliminó la dependencia de procesos manuales, reduciendo errores y aumentando la velocidad de entrega.
- Se mejoró la visibilidad operativa, con mayor control, seguridad y optimización de recursos.
- Se habilitó una plataforma ágil, resiliente y preparada para cargas variables, incluyendo proyectos de investigación HPC.
- Se facilitó el cumplimiento de buenas prácticas DevSecOps y Cloud Native, una base adaptable para escalar innovación, reducir costes operativos y responder con agilidad a nuevas necesidades de negocio.
Marco regulatorio
En banca, la resiliencia y la observabilidad no son un extra: son un requisito regulatorio. La plataforma se diseñó con ese marco en mente.
- DORA (Art. 28): la extensión a AWS se gobierna como riesgo de tercero tecnológico, con trazabilidad de despliegues, capacidad de reversión y observabilidad de extremo a extremo.
- NIS2: seguridad de redes y sistemas en un sector esencial; segmentación, control de accesos y alertas en tiempo real.
- Continuidad de negocio: disponibilidad > 99,99 % y despliegues declarativos reproducibles como evidencia ante el supervisor.
Preguntas frecuentes
¿Se interrumpieron los servicios bancarios durante la migración?
No. La migración se hizo por fases, empezando por una prueba de concepto on-premise y extendiendo después a AWS, con validación funcional en cada etapa. Los seis entornos se migraron manteniendo un 99,9 % de disponibilidad durante la transición.
¿Por qué una plataforma híbrida (RKE2 on-premise + EKS) y no solo cloud?
Porque el banco necesitaba mantener el control de los sistemas críticos on-premise y, al mismo tiempo, escalar en AWS para cargas variables. Una única consola de gestión orquesta ambos entornos.
¿Qué papel juega GitOps en un entorno regulado?
Cada cambio queda versionado, revisado y auditable. Los despliegues declarativos con Rancher Fleet, Helm y Kustomize pasaron de 45 minutos manuales a 3-5 minutos reproducibles, con trazabilidad completa.
¿Puedo conocer la entidad y las cifras completas?
El caso está anonimizado por acuerdo de confidencialidad. El detalle de arquitectura y las cifras completas se comparten previa firma de NDA.
Contenido relacionado
Última actualización: 2026-09-12