A infraestrutura Kubernetes de um grande grupo imobiliário francês hospedava todo o portfólio de aplicações digitais: PIM Akeneo para gestão de dados de produtos, o pipeline de processamento batch Export Ligneurs, todos os sites corporativos (identificados como PWR - Pichet Web Resources), a Intranet da empresa, a API de leads de parceiros PSR, o Tyk API Gateway e vários microsserviços, incluindo uma plataforma IoT de moradia conectada. O projeto abrangeu duas fases principais: clusters Kubernetes on-premise gerenciados pela Claranet (antiga Oxalide) de 2019 a 2021, seguido de uma migração completa para AWS EKS (Elastic Kubernetes Service) na região eu-west-3 de 2022 a 2024.

• Garantir alta disponibilidade de todas as aplicações críticas (sites, PIM, APIs) com zero tempo de inatividade não planejado durante o horário comercial
• Industrializar implantações via GitLab CI + Helm, reduzindo o tempo de implantação de horas para minutos
• Migrar para AWS EKS para melhor escalabilidade, resiliência e benefícios do Kubernetes gerenciado
• Monitorar proativamente os recursos (CPU, memória, disco, certificados SSL) para prevenir incidentes
• Gerenciar acesso seguro por bastions SSH, túneis VPN e gestão de certificados

Toda a presença digital da organização dependia dessa infraestrutura. Com mais de 5 sites comerciais servindo milhares de visitantes diários, um sistema PIM alimentando dados de produtos para todos os canais e processos batch sincronizando dados com parceiros externos, os desafios eram consideráveis. A equipe de infraestrutura operava em um modelo de hospedagem gerenciada com a Claranet, exigindo coordenação próxima entre equipes de desenvolvimento internas e engenheiros de operações externos.

A gestão da infraestrutura exigia coordenação constante entre a equipe de desenvolvimento interna do Groupe Pichet e a equipe de hospedagem gerenciada na Claranet (antiga Oxalide). Como principal consumidor da plataforma Kubernetes (PIM, Export Ligneurs) e supervisor de implantações, servi como ponte entre as necessidades de desenvolvimento e as operacoes de infraestrutura, recebendo todos os alertas de monitoramento e participando diretamente na resolução de incidentes.

• Expertise profunda em operações Kubernetes: gestão do ciclo de vida de pods, limites de recursos, autoscaling horizontal de pods, persistent volume claims e ingress controllers
• Habilidades práticas em cloud AWS: gestão de clusters EKS, configuração S3, políticas IAM, NLB load balancers e arquitetura de bastions
• Maturidade em gestao de incidentes: desenvolvi abordagens sistematicas para triagem, escalonamento e resolução de incidentes de infraestrutura sob pressao
• Design de pipelines CI/CD: automacao de implantacao GitLab CI + Helm Charts, configurações específicas por ambiente e proteções de implantação
• Evolução de desenvolvedor para supervisor de infraestrutura: este projeto mudou fundamentalmente minha compreensão do ciclo completo de entrega de software

Após a migração para AWS EKS estar totalmente estabilizada, a infraestrutura entrou em uma fase operacional madura. A configuração de monitoramento com Centreon e New Relic fornecia alertas proativos, e o pipeline de implantação baseado em Helm permitia que as équipes implantassem com confiança. A gestão de acesso por bastions, embora inicialmente desafiadora (ISS-423267 permaneceu aberto por meses), eventualmente forneceu um caminho de acesso seguro e auditável aos sistemas de produção.

A plataforma Kubernetes continuou operando após minha saída do grupo em março de 2024. As decisões arquiteturais tomadas durante a configuração inicial - Helm charts padronizados, cert-manager automatizado para SSL/TLS, separação clara de namespaces entre ambientes - se mostraram duráveis e permitiram que a infraestrutura escalasse com as crescentes necessidades digitais da organização. A migração de on-premise para AWS EKS validou a estratégia cloud-first e estabeleceu a base para futuras iniciativas cloud-native.

Hoje, os princípios de infraestrutura estabelecidos durante este projeto - containerização, orquestração, implantações automatizadas, monitoramento proativo - são padrões da indústria. A experiência de gerenciar um ciclo de vida de infraestrutura de 5 anos, desde a configuração inicial até uma grande migração para a nuvem, fornece uma perspectiva única sobre as implicações a longo prazo das decisões de infraestrutura. As lições aprendidas informam diretamente minha abordagem atual de infrastructure-as-code e arquitetura cloud.

• A industrialização GitLab CI + Helm foi um grande sucesso. Pipelines de implantação padronizados em todas as aplicações trouxeram consistência e confiabilidade que reduziram drasticamente os incidentes relacionados à implantação após o período de configuração inicial.
• A estratégia de cluster duplo (pré-produção + produção) com separação clara de ambientes preveniu muitos problemas potenciais de producao. O incidente em que a config de produção foi implantada em pré-produção (SRQ0389097) na verdade reforçou a importância das proteções de ambiente.
• O monitoramento proativo com Centreon + New Relic detectou muitos problemas antes de impactarem os usuários finais, transformando a gestão de infraestrutura de combate a incêndio reativo para prevenção proativa.

• O planejamento de recursos durante a Fase 1 foi insuficiente. A crise de Jul-Out 2019 com alertas recorrentes de memória/carga/swap dos nodes poderia ter sido evitada com melhor planejamento de capacidade e requests/limits de recursos nos pods.
• A gestão de acesso por bastions (ISS-423267) se arrastou por muito tempo. Um processo de gestão de acesso mais estruturado com chaves SSH pré-provisionadas e rotação automatizada teria economizado uma sobrecarga significativa de coordenação.
• A documentação das decisões de infraestrutura e runbooks era inconsistente. Criar runbooks abrangentes para padrões comuns de incidentes mais cedo teria acelerado a integração e reduzido os tempos de resolução.

Em retrospecto, eu teria insistido na migração para AWS EKS mais cedo. A fase on-premise, embora educacional, consumiu esforço operacional significativo que o Kubernetes gerenciado teria eliminado. Eu também teria implementado práticas GitOps (ArgoCD ou Flux) desde o início, e estabelecido infrastructure-as-code com Terraform para todos os recursos cloud em vez de depender de solicitações manuais à Claranet. Finalmente, eu teria investido mais em testes automatizados de Helm charts e manifestos Kubernetes antes da implantação, detectando erros de configuração no CI em vez de em produção.

• Infraestrutura nunca está "pronta" - requer atenção contínua, monitoramento e evolução. O ciclo de vida de 5 anos me ensinou que as decisões arquiteturais iniciais têm efeitos compostos ao longo do tempo.
• O modelo de hospedagem gerenciada (Claranet) tem tanto vantagens (expertise, suporte 24/7) quanto limitações (dependência, iteração mais lenta. Entender onde traçar a linha entre gerenciado e autogerenciado é uma habilidade crítica.
• Gestão de incidentes é uma habilidade que so pode ser desenvolvida com prática real. A pressão de incidentes em produção com impacto nos negócios me ensinou compostura, pensamento sistemático e comunicação clara sob estresse.