Modernização de infraestrutura com Kubernetes
Uma grande instituição bancária espanhola precisava modernizar sua infraestrutura crítica para uma arquitetura híbrida de contêineres, sem interromper os serviços em produção.
Desafio
Infraestrutura legada com serviços críticos que não podiam ser interrompidos. Necessidade de modernizar para contêineres e cloud mantendo a plataforma bancária operacional em todos os momentos.
Solução
Implantação por fases com RKE2 e Rancher on-premise, extensão para AWS EKS, adoção de GitOps com Rancher Fleet e observabilidade completa com Prometheus, Grafana e Loki.
Tecnologias
- Kubernetes / RKE2 / Rancher
- AWS EKS, ALB, RDS, S3
- GitOps / Helm / Kustomize
- Prometheus / Grafana / Loki
Contexto
Uma grande instituição bancária espanhola partia de um ambiente de infraestrutura fragmentado, com processos manuais que limitavam a agilidade operacional, a capacidade de escalar a pedido e a resiliência dos seus serviços críticos. Com cargas HPC e sistemas essenciais para o negócio, precisava de uma base tecnológica robusta, mais flexível e automatizada.
Os objetivos fixados com o cliente foram cinco: modernizar a infraestrutura com uma plataforma de orquestração unificada, garantir alta disponibilidade para os sistemas críticos, permitir escalabilidade automática sem sobredimensionamento, melhorar a observabilidade e a rastreabilidade de ponta a ponta, e aumentar a segurança do ambiente reduzindo os erros operacionais.
O desafio
Antes de iniciar a modernização, a organização enfrentava três limitações técnicas e operacionais:
- Ambiente fragmentado e pouco escalável: dificuldade em operar de forma unificada entre on-premise e cloud, com limitações para escalar serviços de forma dinâmica.
- Processos manuais com elevada dependência operacional: deploys lentos (até 45 minutos), propensos a erros e com baixa rastreabilidade, que geravam gargalos e consumo desnecessário de recursos.
- Falta de visibilidade e de resiliência nos serviços críticos: ausência de ferramentas de observabilidade e uma arquitetura exposta a falhas que comprometia a estabilidade de sistemas-chave.
Abordagem por fases
A modernização foi abordada com uma metodologia progressiva, desenhada para não interromper os serviços críticos do negócio. A plataforma foi construída sobre Kubernetes como eixo central de orquestração, em seis etapas claramente definidas.
-
01
Análise e desenho
Avaliação dos workloads, definição da arquitetura, seleção de tecnologias e dimensionamento inicial.
-
02
Prova de conceito
Deploy inicial on-premise com RKE2 e Rancher, validando ambientes HPC e serviços essenciais.
-
03
Extensão para a AWS
Implementação de clusters na AWS (EKS e RKE2 sobre EC2), integrando serviços como ALB, RDS e S3 com conectividade híbrida.
-
04
Automatização e CI/CD
Adoção de GitOps com Rancher Fleet e deploys declarativos através de Helm e Kustomize.
-
05
Observabilidade e rastreabilidade
Incorporação de Prometheus, Grafana e Loki para monitorização, alertas e logs centralizados.
-
06
Produção e suporte
Migração completa dos serviços, validação funcional, entrada em produção e suporte operacional contínuo.
Arquitetura e estratégia
A estratégia foi desenhada para responder às três necessidades do setor: continuidade, escalabilidade e controlo. Optou-se por uma arquitetura híbrida que combina ambientes on-premise e cloud, orquestrada a partir de uma única consola de gestão, o que permitiu manter o controlo sem sacrificar a capacidade de escalar dinamicamente.
A adoção de GitOps e de ferramentas de CI/CD eliminou tarefas manuais, reduziu erros e facilitou ciclos de deploy mais rápidos e previsíveis. A monitorização contínua e os alertas em tempo real foram fundamentais para garantir rastreabilidade, desempenho e conformidade.
Resultados mensuráveis
A escolha do Kubernetes como base tecnológica não foi casual: a sua capacidade para orquestrar contentores de forma eficiente, escalar automaticamente consoante a carga e adaptar-se a ambientes híbridos tornou-o a solução para os desafios do projeto. Resumo dos principais resultados após a implementação:
| Indicador | Antes | Depois |
|---|---|---|
| Tempo de deploy | ~45 minutos | ~3-5 minutos (≈ −90 %) |
| Disponibilidade dos serviços | 95 % | > 99,99 % (+4,95 pontos) |
| Escalabilidade | Manual | Automática, dinâmica |
| Custo operacional | Elevado | Otimizado (≈ −30 %) |
| Tempo de resposta (web/API) | 200-300 ms | 50-120 ms (≈ −60 %) |
Números agregados e anonimizados por acordo de confidencialidade. Fonte: projetos da Vermont Solutions.
Lições aplicáveis
- Eliminou-se a dependência de processos manuais, reduzindo erros e aumentando a velocidade de entrega.
- Melhorou-se a visibilidade operacional, com maior controlo, segurança e otimização de recursos.
- Disponibilizou-se uma plataforma ágil, resiliente e preparada para cargas variáveis, incluindo projetos de investigação HPC.
- Facilitou-se o cumprimento de boas práticas DevSecOps e Cloud Native, uma base adaptável para escalar a inovação, reduzir custos operacionais e responder com agilidade a novas necessidades de negócio.
Enquadramento regulatório
Na banca, a resiliência e a observabilidade não são um extra: são um requisito regulatório. A plataforma foi desenhada com esse enquadramento em mente.
- DORA (art. 28.º): a extensão para a AWS é governada como risco de terceiros TIC, com rastreabilidade dos deploys, capacidade de reversão e observabilidade de ponta a ponta.
- NIS2: segurança das redes e dos sistemas de informação num setor essencial; segmentação, controlo de acessos e alertas em tempo real.
- Continuidade de negócio: disponibilidade > 99,99 % e deploys declarativos reproduzíveis como evidência perante o supervisor.
Perguntas frequentes
Os serviços bancários foram interrompidos durante a migração?
Não. A migração foi feita por fases, começando por uma prova de conceito on-premise e estendendo-se depois à AWS, com validação funcional em cada etapa. Os seis ambientes foram migrados mantendo 99,9 % de disponibilidade durante a transição.
Porquê uma plataforma híbrida (RKE2 on-premise + EKS) e não apenas cloud?
Porque o banco precisava de manter o controlo dos sistemas críticos on-premise e, ao mesmo tempo, escalar na AWS para cargas variáveis. Uma única consola de gestão orquestra ambos os ambientes.
Que papel desempenha o GitOps num ambiente regulado?
Cada alteração fica versionada, revista e auditável. Os deploys declarativos com Rancher Fleet, Helm e Kustomize passaram de 45 minutos manuais para 3-5 minutos reproduzíveis, com rastreabilidade completa.
Posso conhecer a instituição e os números completos?
O caso está anonimizado por acordo de confidencialidade. O detalhe da arquitetura e os números completos são partilhados após assinatura de um NDA.
Conteúdo relacionado
Última atualização: 2026-09-12