Visão geral
Atuação na arquitetura, evolução e operação contínua de uma plataforma baseada em Amazon EKS, utilizada para executar workloads SaaS em ambiente SaaS de alta complexidade. A plataforma operava +15 clusters distribuídos globalmente, sustentando +1.700 containers em operação 24x7.
Contexto
A plataforma SaaS corporativa crescia em volume de workloads, complexidade de deploy e exigências de disponibilidade. Múltiplos clusters Amazon EKS distribuídos geograficamente, cada um com particularidades de capacidade, rede e integração com serviços AWS. A operação precisava suportar releases contínuos, escalabilidade horizontal e troubleshooting em ambientes com camadas interdependentes.
Desafio
Equilibrar capacidade computacional, persistência, networking, observabilidade, automação e custos em uma plataforma com +15 clusters e centenas de workloads, mantendo estabilidade em operação 24x7. Cada decisão arquitetural impactava simultaneamente segurança, performance, custo e capacidade de evolução da plataforma.
Minha atuação
- Arquitetura e evolução de clusters Amazon EKS — node groups, capacidade computacional e scaling
- Desenho e manutenção de networking Kubernetes: VPC, subnets, routing, ingress e load balancing
- Integração com IAM, EFS, serviços AWS e identidade corporativa
- Troubleshooting de problemas atravessando aplicação, Kubernetes, rede, storage e serviços AWS
- Observabilidade com CloudWatch, Grafana, Loki e Datadog — dashboards, alertas e pipelines de logs
- Automação com Terraform, Helm e pipelines CI/CD para mudanças repetíveis e rastreáveis
- Análise de performance, capacidade e custos de compute e storage
Arquitetura
A arquitetura separava infraestrutura cloud dos workloads Kubernetes. Tráfego de aplicações passava por camadas controladas de proteção (WAF), balanceamento de carga e ingress antes de alcançar os serviços nos clusters. Cada cluster operava com node groups segmentados por perfil de carga, permitindo decisões independentes de capacidade e custo. Persistência compartilhada via EFS somente onde a natureza do workload justificava.
Evolução da Arquitetura de Ingress
A camada de ingress da plataforma utilizava Nginx Ingress Controller como componente crítico no caminho de entrada das aplicações. Com a evolução da plataforma e a necessidade de maior flexibilidade no roteamento, controle de tráfego e observabilidade, foi iniciada a migração para uma arquitetura baseada em Envoy.
A migração envolveu análise das regras de roteamento existentes, validação de compatibilidade com aplicações, configuração da nova camada de ingress, testes de regressão, observabilidade comparativa e rollout controlado entre clusters. Cada etapa foi conduzida de forma incremental, com possibilidade de rollback a qualquer momento.
A substituição de um ingress controller em produção exigiu atuação sobre componentes críticos: roteamento HTTP/HTTPS, TLS, load balancing, serviços Kubernetes, health checks, headers, timeouts, logging e segurança. A mudança foi concluída sem impacto na operação da plataforma.
Decisões técnicas
- Separação de responsabilidades entre infraestrutura Kubernetes e workloads de aplicação
- Compute orientado por perfil de carga, disponibilidade e custo — não por convenção
- Persistência compartilhada somente onde a arquitetura do workload justificava
- Exposição controlada de serviços com ingress layer e security groups segmentados
- Observabilidade como parte da plataforma, não como ferramenta posterior
Segurança e governança
Integrações de identidade, segmentação de rede e exposição de serviços foram tratadas como decisões arquiteturais desde o início. Menor privilégio e segurança em profundidade guiaram a definição de security groups, IAM roles por workload e políticas de rede entre clusters e contas AWS.
Automação
Terraform gerenciava a infraestrutura Kubernetes e os serviços AWS dependentes. Helm padronizava a implantação de workloads com valores ambientais. Pipelines CI/CD automatizavam build, teste e deploy, com revisão de mudanças antes da aplicação em produção. Mudanças rastreáveis, auditáveis e repetíveis em ambientes distribuídos.
Desafios de engenharia
Investigações de incidentes exigiam correlacionar comportamento de aplicações, Kubernetes, rede, storage e serviços AWS. Um problema aparentemente de aplicação poderia ser causado por restrição de networking, contenção de storage ou limitação de node group. A capacidade de investigar sem isolar camadas era essencial para resolução eficiente.
Resultados
- +15 clusters operando de forma padronizada e sustentável
- Mudanças de infraestrutura com rastreabilidade completa via IaC e pipelines
- Troubleshooting com capacidade de correlação entre múltiplas camadas
- Base preparada para crescimento de workloads e adição de novos clusters