Modernizzazione dell'infrastruttura con Kubernetes
Un grande istituto bancario spagnolo doveva modernizzare la sua infrastruttura critica verso un'architettura ibrida a container, senza interrompere i servizi in produzione.
Sfida
Infrastruttura legacy con servizi critici che non potevano essere fermati. Necessità di modernizzare verso container e cloud mantenendo operativa la piattaforma bancaria in ogni momento.
Soluzione
Deployment a fasi con RKE2 e Rancher on-premise, estensione ad AWS EKS, adozione di GitOps con Rancher Fleet e osservabilità completa con Prometheus, Grafana e Loki.
Tecnologie
- Kubernetes / RKE2 / Rancher
- AWS EKS, ALB, RDS, S3
- GitOps / Helm / Kustomize
- Prometheus / Grafana / Loki
Contesto
Un grande istituto bancario spagnolo partiva da un ambiente infrastrutturale frammentato, con processi manuali che limitavano l'agilità operativa, la capacità di scalare su domanda e la resilienza dei suoi servizi critici. Con carichi HPC e sistemi essenziali per il business, aveva bisogno di una base tecnologica robusta, più flessibile e automatizzata.
Gli obiettivi concordati con il cliente erano cinque: modernizzare l'infrastruttura con una piattaforma di orchestrazione unificata, garantire alta disponibilità per i sistemi critici, consentire la scalabilità automatica senza sovradimensionamento, migliorare l'osservabilità e la tracciabilità end-to-end, e aumentare la sicurezza dell'ambiente riducendo gli errori operativi.
La sfida
Prima di avviare la modernizzazione, l'organizzazione affrontava tre limitazioni tecniche e operative:
- Ambiente frammentato e poco scalabile: difficoltà a operare in modo unificato tra on-premise e cloud, con limiti nello scalare i servizi in modo dinamico.
- Processi manuali con alta dipendenza operativa: deployment lenti (fino a 45 minuti), soggetti a errori e con bassa tracciabilità, che generavano colli di bottiglia e un consumo di risorse non necessario.
- Mancanza di visibilità e resilienza nei servizi critici: assenza di strumenti di osservabilità e un'architettura esposta ai guasti che compromettevano la stabilità dei sistemi chiave.
Approccio per fasi
La modernizzazione è stata affrontata con un approccio progressivo, pensato per non interrompere i servizi critici del business. La piattaforma è stata costruita su Kubernetes come asse centrale di orchestrazione, in sei tappe chiaramente definite.
-
01
Analisi e progettazione
Valutazione dei workload, definizione dell'architettura, selezione delle tecnologie e dimensionamento iniziale.
-
02
Proof of concept
Deployment iniziale on-premise con RKE2 e Rancher, validando ambienti HPC e servizi essenziali.
-
03
Estensione ad AWS
Implementazione di cluster su AWS (EKS e RKE2 su EC2), integrando servizi come ALB, RDS e S3 con connettività ibrida.
-
04
Automazione e CI/CD
Adozione di GitOps con Rancher Fleet e deployment dichiarativi tramite Helm e Kustomize.
-
05
Osservabilità e tracciabilità
Introduzione di Prometheus, Grafana e Loki per monitoraggio, alert e log centralizzati.
-
06
Produzione e supporto
Migrazione completa dei servizi, validazione funzionale, messa in esercizio e supporto operativo continuo.
Architettura e strategia
La strategia è stata progettata per rispondere alle tre esigenze del settore: continuità, scalabilità e controllo. Si è optato per un'architettura ibrida che combina ambienti on-premise e cloud, orchestrata da un'unica console di gestione, il che ha permesso di mantenere il controllo senza sacrificare la capacità di scalare dinamicamente.
L'adozione di GitOps e di strumenti di CI/CD ha eliminato le attività manuali, ridotto gli errori e favorito cicli di deployment più rapidi e prevedibili. Il monitoraggio continuo e gli alert in tempo reale sono stati fondamentali per garantire tracciabilità, prestazioni e conformità.
Risultati misurabili
La scelta di Kubernetes come base tecnologica non è stata casuale: la sua capacità di orchestrare container in modo efficiente, scalare automaticamente in base al carico e adattarsi ad ambienti ibridi lo ha reso la soluzione per le sfide del progetto. Sintesi dei principali risultati dopo l'implementazione:
| Indicatore | Prima | Dopo |
|---|---|---|
| Tempo di deployment | ~45 minuti | ~3-5 minuti (≈ −90 %) |
| Disponibilità dei servizi | 95 % | > 99,99 % (+4,95 punti) |
| Scalabilità | Manuale | Automatica, dinamica |
| Costo operativo | Elevato | Ottimizzato (≈ −30 %) |
| Tempo di risposta (web/API) | 200-300 ms | 50-120 ms (≈ −60 %) |
Cifre aggregate e anonimizzate in base a un accordo di riservatezza. Fonte: progetti di Vermont Solutions.
Lezioni applicabili
- È stata eliminata la dipendenza dai processi manuali, riducendo gli errori e aumentando la velocità di rilascio.
- È migliorata la visibilità operativa, con maggiore controllo, sicurezza e ottimizzazione delle risorse.
- È stata abilitata una piattaforma agile, resiliente e pronta per carichi variabili, inclusi i progetti di ricerca HPC.
- È stata facilitata l'adozione delle buone pratiche DevSecOps e Cloud Native, una base adattabile per scalare l'innovazione, ridurre i costi operativi e rispondere con agilità alle nuove esigenze di business.
Quadro normativo
In banca, resilienza e osservabilità non sono un extra: sono un requisito normativo. La piattaforma è stata progettata tenendo presente questo quadro.
- DORA (art. 28): l'estensione ad AWS è governata come rischio di terze parti ICT, con tracciabilità dei deployment, capacità di rollback e osservabilità end-to-end.
- NIS2: sicurezza delle reti e dei sistemi in un settore essenziale; segmentazione, controllo degli accessi e alert in tempo reale.
- Continuità operativa: disponibilità > 99,99 % e deployment dichiarativi riproducibili come evidenza davanti all'autorità di vigilanza.
Domande frequenti
I servizi bancari sono stati interrotti durante la migrazione?
No. La migrazione è stata realizzata per fasi, partendo da un proof of concept on-premise ed estendendo poi ad AWS, con validazione funzionale in ogni tappa. I sei ambienti sono stati migrati mantenendo il 99,9 % di disponibilità durante la transizione.
Perché una piattaforma ibrida (RKE2 on-premise + EKS) e non solo cloud?
Perché la banca doveva mantenere il controllo dei sistemi critici on-premise e, allo stesso tempo, scalare su AWS per i carichi variabili. Un'unica console di gestione orchestra entrambi gli ambienti.
Che ruolo ha GitOps in un ambiente regolamentato?
Ogni modifica resta versionata, revisionata e verificabile. I deployment dichiarativi con Rancher Fleet, Helm e Kustomize sono passati da 45 minuti manuali a 3-5 minuti riproducibili, con tracciabilità completa.
Posso conoscere l'istituto e le cifre complete?
Il caso è anonimizzato in base a un accordo di riservatezza. Il dettaglio dell'architettura e le cifre complete vengono condivisi previa firma di un NDA.
Contenuti correlati
Ultimo aggiornamento: 2026-09-12