--- title: "Cloud-Native Kubernetes Platform" description: "Enterprise-grade Kubernetes infrastructure hosting 10+ critical applications for a major real estate group - from on-premise clusters to AWS EKS, spanning 5 years of continuous operations, incident management, and cloud migration." locale: "en" canonical: "https://portfolio.josedacosta.info/en/achievements/infrastructure-kubernetes-aws" source: "https://portfolio.josedacosta.info/en/achievements/infrastructure-kubernetes-aws.md" html_source: "https://portfolio.josedacosta.info/en/achievements/infrastructure-kubernetes-aws" author: "José DA COSTA" date: "2019" type: "achievement" slug: "infrastructure-kubernetes-aws" tags: ["Kubernetes", "AWS EKS", "Docker", "Helm", "GitLab CI", "Nginx Ingress", "Varnish", "Memcached", "Tyk", "Cert-Manager", "Centreon", "New Relic", "AWS S3"] generated_at: "2026-04-23T15:45:12.287Z" --- # Cloud-Native Kubernetes Platform Enterprise-grade Kubernetes infrastructure hosting 10+ critical applications for a major real estate group - from on-premise clusters to AWS EKS, spanning 5 years of continuous operations, incident management, and cloud migration. **Date:** 2019 - 2024 **Duration:** ~5 years **Role:** Technical Lead then Engineering Manager - Cloud Infrastructure **Technologies:** Kubernetes, AWS EKS, Docker, Helm, GitLab CI, Nginx Ingress, Varnish, Memcached, Tyk, Cert-Manager, Centreon, New Relic, AWS S3 ### Key Metrics - Applications Hosted: **-** - Websites, PIM, APIs, batch jobs, gateways - Incidents Managed: **-** - INC/SRQ/ISS tracked & resolved - Cluster Generations: **-** - On-premise K8s then AWS EKS - Infrastructure Lifecycle: **-** - Jan 2019 to Mar 2024 ## Presentation _An enterprise Kubernetes platform for the digital transformation of real estate_ ### Nature Multi-application Kubernetes infrastructure - 10+ containerized applications deployed across 2 cluster generations (on-premise then AWS EKS), with industrialized CI/CD pipelines, proactive monitoring, and managed hosting through Claranet. ### Domain Real Estate - the Pichet Group websites (pichet.fr, pichet-immobilier.fr, stock-invest.pichet.com, monespace.pichet.com) are the commercial front doors of the group. Any downtime directly impacts business revenue and brand reputation. **Nature:** Project Nature **Domain:** Business Domain **Scope:** Functional Scope **Intro:** The Kubernetes infrastructure of a major French real estate group hosted the entire portfolio of digital applications: PIM Akeneo for product data management, the Export Ligneurs batch processing pipeline, all corporate websites (branded as PWR - Pichet Web Resources), the company Intranet, the PSR partner leads API, the Tyk API Gateway, and various microservices including a connected housing IoT platform. The project spanned two major phases: on-premise Kubernetes clusters managed by Claranet (formerly Oxalide) from 2019 to 2021, followed by a full migration to AWS EKS (Elastic Kubernetes Service) on the eu-west-3 region from 2022 to 2024. ## Objectives, Context, Stakes & Risks _Understanding the strategic vision behind the infrastructure_ **Context:** The organization's entire digital presence depended on this infrastructure. With 5+ commercial websites serving thousands of daily visitors, a PIM system feeding product data to all channels, and batch processes synchronizing data with external partners, the stakes were considerable. The infrastructure team operated in a managed hosting model with Claranet, requiring close coordination between internal development teams and external operations engineers. ## The Steps - What I Did _A concrete, phase-by-phase journey through the infrastructure lifecycle_ ## The Actors - Interactions _A complex ecosystem of internal teams and external providers_ **Team Description:** The infrastructure management required constant coordination between the internal development team at Groupe Pichet and the managed hosting team at Claranet (formerly Oxalide). As the primary consumer of the Kubernetes platform (PIM, Export Ligneurs) and deployment supervisor, I served as the bridge between development needs and infrastructure operations, receiving all monitoring alerts and participating directly in incident resolution. ## Results _Measurable impact for the organization and personal growth_ ## Project Aftermath _Beyond migration - the long-term évolution of the platform_ **Immédiate:** After the AWS EKS migration was fully stabilized, the infrastructure entered a mature operational phase. The monitoring setup with Centreon and New Relic provided proactive alerting, and the Helm-based deployment pipeline enabled teams to deploy with confidence. The bastion access management, while initially challenging (ISS-423267 remained open for months), eventually provided a secure and auditable access path to production systems. **Long Term:** The Kubernetes platform continued operating beyond my departure from the group in March 2024. The architectural décisions made during the initial setup - standardized Helm charts, automated cert-manager for SSL/TLS, clear namespace séparation between environments - proved durable and enabled the infrastructure to scale with the organization's growing digital needs. The migration from on-premise to AWS EKS validated the cloud-first strategy and set the foundation for future cloud-native initiatives. **Today:** Today, the infrastructure principles established during this project - containerization, orchestration, automated deployments, proactive monitoring - are industry standards. The experience of managing a 5-year infrastructure lifecycle, from initial setup through a major cloud migration, provides a unique perspective on the long-term implications of infrastructure décisions. The lessons learned directly inform my current approach to infrastructure-as-code and cloud architecture. ## Critical Reflection _Honest retrospective on 5 years of infrastructure management_ **Would Do Differently:** With hindsight, I would have pushed for the AWS EKS migration earlier. The on-premise phase, while educational, consumed significant operational effort that managed Kubernetes would have eliminated. I would also have implemented GitOps practices (ArgoCD or Flux) from the start, and established infrastructure-as-code with Terraform for all cloud resources rather than relying on manual Claranet requests. Finally, I would have invested more in automated testing of Helm charts and Kubernetes manifests before deployment, catching configuration errors in CI rather than in production.