Skip to content
Fecha límite del CBN, 1 ene 2027: 99d 00h 25m restantes.Hable con nosotros
NuxFamily

Banca · Un banco minorista español del top 5

Trasladar las cargas críticas de un banco minorista de la nube pública a una nube privada, sin interrupción

El banco necesitaba repatriar varios cientos de cargas de trabajo desde un hyperscaler a sus propios datacenters bajo un plazo regulatorio. NuxFamily diseñó la plataforma objetivo, ejecutó la migración por olas y transfirió la operación al equipo del banco.

  • 0

    Minutos de interrupción no planificada en nueve olas de migración

  • −38 %

    Coste de operación de infraestructura frente a la referencia de nube pública

  • 7 meses

    Desde la construcción de la plataforma hasta el corte final, antes del plazo

El reto

El reto

El banco había construido un parque considerable en una nube pública extranjera: canales de cliente, procesamiento batch y varios servicios próximos a pagos. Un requisito supervisor de mantener el procesamiento y las funciones administrativas dentro de su jurisdicción dio al banco catorce meses para repatriar el parque. El equipo interno tenía un gran conocimiento de las aplicaciones, pero no había operado una nube privada a esa escala.

La restricción principal era la disponibilidad. Los canales no podían interrumpirse en horario comercial y los servicios de pago tenían un objetivo de tiempo de recuperación medido en minutos. Cualquier plan de migración debía incluir un rollback probado para cada ola, y cada cambio debía ser trazable para el supervisor.

Una restricción secundaria era el coste. El banco no quería reproducir el gasto de la nube pública en sus instalaciones, así que la plataforma debía ofrecer autoservicio, automatización y planificación de capacidad desde el primer día.

La arquitectura

La arquitectura

La base es una nube privada VMware vSphere en dos datacenters en configuración activo-activo, con NSX para la segmentación de red y almacenamiento de objetos compatible con S3 para backups y datos no estructurados. La capacidad se dimensionó a partir del inventario real y no de las facturas de la nube pública, lo que redujo la huella inicial.

Las cargas contenerizadas se ejecutan en clústeres OpenShift por entorno, desplegados con GitOps e integrados con el proveedor de identidad y la gestión de secretos del banco. Las máquinas virtuales heredadas se migraron tal cual a vSphere y se programaron para una modernización posterior, de modo que el plazo no dependiera de refactorizar.

Los servicios con estado pasaron a clústeres PostgreSQL gestionados con Patroni, con replicación síncrona entre sedes y recuperación a un punto en el tiempo sobre el almacén de objetos. La mensajería pasó de colas gestionadas en la nube a Apache Kafka sobre la misma plataforma.

La migración se ejecutó en nueve olas a lo largo de siete meses. Cada ola tenía un mapa de dependencias, una ventana de sincronización de datos, un runbook de corte y un rollback ensayado. La observabilidad, el parcheo y la gestión del ciclo de vida estaban en marcha antes de la primera ola de producción.

Tecnologías

  • VMware vSphere
  • NSX
  • OpenShift
  • PostgreSQL
  • Patroni
  • Apache Kafka
  • Almacenamiento de objetos compatible con S3
  • GitOps
Los planes de rollback fueron la razón por la que pudimos aprobar cada ola. Los usamos una vez, y funcionaron.
Director de Infraestructura, banco minorista

Su entidad puede ser el próximo caso

Cuéntenos su plataforma y su calendario regulatorio; le mostraremos cuál de estos patrones aplica.

Sin listas de correo ni seguimientos automáticos. Respondemos personalmente en un día laborable.