[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fW61jAchHU5IT5gXYIORVVeZDamU4Mp6x1Emoy2GQ3C0":3,"$ffCkrYr_xg_ip2gM27AKi8SvRuaVTt3UIzv-yPOYpnYc":23},{"id":4,"slug":5,"titleFr":6,"titleEn":7,"titleKm":8,"contentFr":9,"contentEn":10,"contentKm":11,"excerptFr":12,"excerptEn":13,"excerptKm":14,"tags":15,"createdAt":22,"updatedAt":22},112,"aws-gcp-migration-startup-b2b","Quand Google Cloud vous courtise : pourquoi on est resté sur AWS (et ce qu'on y a perdu)","When Google Cloud courts you: why we stayed on AWS (and what we lost)","នៅពេល Google Cloud អញ្ជើញអ្នក៖ ហេតុអ្វីយើងនៅលើ AWS (និងអ្វីដែលយើងបានបាត់)","## Introduction\n\nEn 2024, Google Cloud nous a invités, mon équipe et moi chez DJUST, à une série d'événements exclusifs. Le pitch était clair : **\"Vous êtes sur AWS depuis 4 ans. Venez chez nous, on vous accompagne dans la migration, et on vous offre des crédits cloud conséquents.\"**\n\nGoogle ne faisait pas ça par charité. DJUST est une plateforme e-commerce B2B SaaS qui gère des commandes pour des clients dans la grande distribution, la construction et la mode. C'est exactement le type de workload que GCP veut attirer : du Java/Spring Boot, du Kubernetes, du PostgreSQL, de l'Elasticsearch — tout ce que Google Cloud sait faire.\n\nMoi, j'étais totalement pour. Je voyais dans cette migration une opportunité unique : non seulement économiser sur les coûts cloud, mais surtout **moderniser notre codebase** en travaillant main dans la main avec des ingénieurs Google et un cabinet cloud partenaire. C'était l'occasion rêvée de rembourser de la dette technique tout en étant accompagné par des experts.\n\nMais la direction de DJUST a dit non. Et avec le recul, je comprends pourquoi — même si une part de moi regrette encore l'opportunité manquée.\n\nVoici l'histoire complète, les analyses techniques, et les leçons que j'en tire.\n\n## Chapitre 1 : Le contexte — DJUST sur AWS\n\n### Comment on a atterri sur AWS\n\nDJUST a été créé en 2021. Comme 90% des startups tech, le choix initial du cloud s'est fait de manière pragmatique :\n\n- **Les crédits AWS Activate** : Amazon offre jusqu'à 100 000$ de crédits aux startups via son programme Activate. Pour une boîte qui démarre, c'est un argument massif\n- **La familiarité** : les premiers développeurs (dont moi, en tant que Lead Software Engineer) connaissaient AWS. EC2, RDS, S3, SQS — c'est la lingua franca du cloud\n- **L'écosystème** : plus de documentation, plus de tutorials, plus de réponses StackOverflow pour AWS que pour n'importe quel autre cloud\n\nLe choix n'a pas fait l'objet d'un benchmark détaillé. C'était : \"On connaît AWS, on a des crédits, on y va.\" Et c'est **normal** pour une startup en phase de construction. L'enjeu à ce stade, c'est de livrer le produit, pas d'optimiser l'infra.\n\n### Notre stack AWS en 2024\n\nAprès 3 ans de développement, voici à quoi ressemblait notre infrastructure :\n\n- **EKS** (Elastic Kubernetes Service) : notre cluster Kubernetes managé, hébergeant ~15 microservices Spring Boot\n- **RDS PostgreSQL** : notre base de données principale (multi-AZ pour la haute disponibilité)\n- **ElastiCache Redis** : cache et sessions\n- **Amazon Elasticsearch Service** : moteur de recherche produit\n- **SQS** : messaging entre microservices (commandes, paiements, notifications)\n- **S3** : stockage d'assets (images produits, documents)\n- **ECR** : registry Docker pour nos images\n- **CloudFront** : CDN pour le frontend\n- **Route 53** : DNS\n- **IAM** : gestion des accès\n- **CloudWatch** : monitoring et logs\n\nLe tout géré par **2 DevOps**. Deux personnes. Pour une plateforme qui sert des clients enterprise avec des SLA exigeants.\n\n### Les douleurs\n\nAprès 3 ans sur AWS, on avait accumulé des frustrations :\n\n**1. Les coûts qui explosent**\n\nLes crédits Activate s'étaient épuisés. Et la facture AWS avait une tendance claire : **elle montait chaque mois**. EKS seul coûte ~$75/mois juste pour le control plane, avant même d'ajouter des nodes. RDS multi-AZ, c'est cher. ElastiCache, c'est cher. Et surtout : AWS est **notoirement opaque** sur ses tarifs. Comprendre sa facture AWS est un métier à part entière.\n\n**2. La complexité opérationnelle**\n\nAvec 2 DevOps pour gérer tout ça, on était en permanence en mode pompier. Un upgrade EKS ? Ça prend une semaine de préparation. Un incident RDS ? Tout le monde est en alerte. La charge opérationnelle était disproportionnée par rapport à la taille de l'équipe.\n\n**3. La dette technique liée à AWS**\n\nOn avait fait des choix rapides au début (normal pour une startup) qui devenaient des boulets :\n- Des instances EC2 surdimensionnées \"par sécurité\"\n- Des services non optimisés (Reserved Instances non utilisées, GP2 au lieu de GP3)\n- Un monitoring CloudWatch partiel et coûteux\n- Pas de FinOps structuré\n\n## Chapitre 2 : L'offre de Google\n\n### Les événements Google Cloud\n\nGoogle Cloud a une stratégie agressive pour attirer les clients AWS. Ils identifient des entreprises en croissance qui utilisent AWS et leur proposent un accompagnement personnalisé.\n\nPour DJUST, ça s'est concrétisé par :\n\n- **Invitations à des événements Google Cloud** : workshops techniques, présentations de cas clients, networking avec des décideurs tech. J'y ai assisté avec d'autres membres de l'équipe\n- **Engagement technique** : des ingénieurs Google Cloud prêts à travailler avec nous sur un plan de migration détaillé\n- **Partenariat avec un cabinet cloud partenaire** : spécialisé dans les migrations cloud, qui aurait assuré l'accompagnement opérationnel de la migration\n- **Crédits GCP** : des crédits cloud conséquents pour couvrir la période de migration et au-delà (souvent 100K-300K$ sur 1-2 ans pour ce type de deal)\n\n### Ce que GCP mettait sur la table\n\nConcrètement, voici ce que la migration aurait impliqué et les avantages associés :\n\n**GKE (Google Kubernetes Engine) vs EKS**\n\nC'est LE point fort de Google. GKE est unanimement reconnu comme le **meilleur Kubernetes managé du marché** :\n- **Autopilot** : GKE gère les nodes automatiquement, pas besoin de dimensionner. Avec EKS, nos DevOps passaient du temps à gérer les node groups\n- **Cluster autoscaler natif** : plus réactif et mieux intégré que celui d'EKS\n- **Coût du control plane** : GKE Autopilot = $0 pour le control plane (facturé à l'usage des pods). EKS = $73/mois fixe\n- **Mises à jour** : GKE se met à jour quasi-automatiquement. EKS nécessite des mises à jour manuelles planifiées (et stressantes)\n- **Multi-cluster** : Anthos pour la gestion multi-cluster, bien au-delà de ce qu'EKS propose\n\nPour notre équipe de 2 DevOps, GKE Autopilot aurait été un **game changer**. Moins d'ops, plus de temps pour améliorer l'infra.\n\n**Cloud SQL vs RDS PostgreSQL**\n\nRelativement similaires en features, mais :\n- Cloud SQL a un meilleur support natif des connexions poolées (via PgBouncer intégré ou AlloyDB pour PostgreSQL)\n- **AlloyDB** : le PostgreSQL compatible de Google, qui promet des performances 4x supérieures à RDS PostgreSQL pour les workloads transactionnels. Pour notre OMS, ça aurait été intéressant\n- Les prix sont comparables, avec un léger avantage GCP sur les instances committées\n\n**BigQuery vs... rien chez nous**\n\nOn n'avait pas de data warehouse. BigQuery aurait ouvert la porte à de l'analytics avancé sur nos données de commandes, paiements, comportements clients. C'est le **meilleur produit de Google Cloud**, et il n'a pas d'équivalent direct chez AWS (Redshift existe, mais c'est moins intégré et plus cher).\n\n**Pub/Sub vs SQS**\n\nGoogle Pub/Sub est plus flexible que SQS :\n- Support natif du pattern pub/sub (un message, plusieurs consommateurs) vs SQS qui est uniquement point-à-point\n- Ordering guarantees plus souples\n- Dead letter queues intégrées\n- Pricing plus simple\n\n**Cloud Monitoring vs CloudWatch**\n\nCloudWatch est cher et limité. Google Cloud Monitoring + Cloud Logging sont inclus et plus généreux dans le free tier.\n\n### L'opportunité cachée : moderniser la codebase\n\nC'est ce point qui m'excitait le plus. Une migration cloud, c'est l'occasion de **tout revoir** :\n\n- **Revoir l'architecture des microservices** : est-ce qu'on a vraiment besoin de 15 services ? Peut-on en consolider certains ?\n- **Adopter GKE Autopilot** : simplifier radicalement l'ops\n- **Implémenter du FinOps dès le départ** : labels, budgets, alertes, rightsizing\n- **Moderniser le CI/CD** : passer de notre pipeline GitLab custom à quelque chose de plus streamlined\n- **Rembourser de la dette technique** : profiter du \"mouvement\" pour nettoyer ce qui traîne depuis 3 ans\n\nEt on n'aurait pas été seuls. Les ingénieurs Google + le cabinet partenaire auraient apporté leur expertise. C'est rare d'avoir accès à ce niveau d'accompagnement technique.\n\n## Chapitre 3 : Pourquoi la direction a dit non\n\n### L'argument du risque client\n\nDJUST sert des clients enterprise dans la distribution, la construction et la mode. Ces clients ont des **SLA contractuels**. Un downtime de 2 heures, c'est pas juste un incident technique — c'est une pénalité financière et une perte de confiance.\n\nLa direction a posé la question fondamentale : **\"Quel est le risque d'une migration cloud pour nos clients ?\"**\n\nEt la réponse honnête est : **le risque est réel et significatif**.\n\nUne migration AWS → GCP pour une plateforme de notre taille, c'est :\n\n- **3 à 6 mois** de travail minimum (estimation optimiste)\n- Un risque de **downtime** pendant la bascule (même avec une migration progressive)\n- Une période de **double run** (les deux clouds en parallèle) coûteuse\n- Des **bugs inattendus** liés aux différences subtiles entre services (SQS vs Pub/Sub, RDS vs Cloud SQL)\n- Une **courbe d'apprentissage** pour les 2 DevOps qui connaissent AWS par cœur mais pas GCP\n\nPour une startup B2B qui cherche à gagner la confiance de clients enterprise, prendre ce risque est **difficile à justifier** auprès du board.\n\n### L'argument de l'équipe\n\nAvec **2 DevOps**, on n'avait pas le bandwidth pour :\n1. Maintenir la plateforme AWS en production (le quotidien)\n2. ET piloter une migration vers GCP (le projet)\n\nIl aurait fallu soit embaucher des DevOps supplémentaires (coût), soit dégrader temporairement le support de la production (risque). Le cabinet partenaire aurait aidé, mais la connaissance de notre stack spécifique restait chez nos 2 DevOps.\n\n### L'argument du coût à court terme\n\nParadoxalement, migrer pour économiser coûte cher à court terme :\n- **Double run** pendant la migration : on paie AWS ET GCP pendant 3-6 mois\n- **Temps humain** : les DevOps travaillent sur la migration au lieu d'améliorer la prod\n- **Le cabinet cloud partenaire** : même avec des crédits Google, le consulting a un coût\n- **Formation** : toute l'équipe (pas juste les DevOps) doit apprendre les services GCP\n\nL'estimation : **6-12 mois avant de voir un ROI positif** sur la migration. Pour une startup qui brûle du cash, c'est long.\n\n### La décision : optimiser AWS\n\nLa direction a tranché : **on reste sur AWS, mais on optimise**.\n\nLe plan :\n- **FinOps** : audit complet de la facture AWS, identification des quick wins\n- **Reserved Instances / Savings Plans** : engagement 1 an pour réduire les coûts compute de 30-40%\n- **Rightsizing** : réduire les instances surdimensionnées\n- **Storage optimization** : GP2 → GP3, lifecycle policies S3\n- **Monitoring** : alertes budget, dashboards coût par service\n\n## Chapitre 4 : AWS vs GCP — l'analyse technique approfondie\n\nAvec du recul, voici mon analyse honnête des deux clouds pour un workload comme celui de DJUST.\n\n### Kubernetes : avantage net GCP\n\n| Critère | EKS (AWS) | GKE (GCP) |\n|---------|-----------|-----------|\n| Control plane | $73/mois fixe | $0 (Autopilot) |\n| Node management | Manuel (node groups, AMI) | Automatique (Autopilot) |\n| Upgrades | Manuels, risqués, planifiés | Quasi-automatiques |\n| Autoscaling | Cluster Autoscaler (addon) | Natif, plus réactif |\n| Multi-cluster | Basique | Anthos (puissant) |\n| Charge ops | Élevée | Faible |\n| Maturité K8s | Bonne | Excellente (K8s est né chez Google) |\n\n**Verdict** : GKE est objectivement meilleur. Kubernetes a été inventé par Google, et ça se sent. Pour 2 DevOps, GKE Autopilot aurait réduit significativement la charge opérationnelle.\n\n### Base de données : quasi-égalité\n\n| Critère | RDS PostgreSQL | Cloud SQL / AlloyDB |\n|---------|---------------|-------------------|\n| PostgreSQL managed | Excellent | Excellent |\n| Haute dispo | Multi-AZ | Régional (similaire) |\n| Performance | Très bon | AlloyDB potentiellement 4x |\n| Backup/restore | Automatique | Automatique |\n| Prix | Comparable | Comparable (léger avantage) |\n| Connexion pooling | Manuel (PgBouncer) | AlloyDB intégré |\n\n**Verdict** : match nul sur Cloud SQL, léger avantage GCP si on utilise AlloyDB.\n\n### Messaging : avantage GCP\n\n| Critère | SQS | Pub/Sub |\n|---------|-----|---------|\n| Modèle | Point-à-point uniquement | Pub/Sub + point-à-point |\n| Ordering | FIFO (limité) | Natif, plus flexible |\n| Fan-out | Nécessite SNS + SQS | Natif |\n| Dead letter | Oui | Oui |\n| Prix | Par message | Par volume (souvent moins cher) |\n\n**Verdict** : Pub/Sub est plus polyvalent. Pour nos flux de commandes et paiements, le pattern pub/sub natif aurait été utile.\n\n### Monitoring & observabilité : avantage GCP\n\n| Critère | CloudWatch | Cloud Monitoring |\n|---------|-----------|-----------------|\n| Prix | Cher (logs, métriques, dashboards payants) | Généreux free tier |\n| Intégration K8s | Via addons | Natif avec GKE |\n| Dashboards | Basiques | Plus riches |\n| Alerting | Correct | Correct |\n| Traces | X-Ray (séparé) | Cloud Trace (intégré) |\n\n**Verdict** : avantage GCP, surtout sur le pricing. On dépensait une part significative de notre budget AWS juste en CloudWatch.\n\n### Réseau & CDN : avantage AWS\n\n| Critère | AWS | GCP |\n|---------|-----|-----|\n| CDN | CloudFront (leader marché) | Cloud CDN (correct) |\n| DNS | Route 53 (excellent) | Cloud DNS (correct) |\n| Load Balancer | ALB/NLB (matures) | Cloud Load Balancing (bon) |\n| VPC | Très mature | Bon, mais différent |\n| Points de présence | 450+ | 200+ |\n\n**Verdict** : AWS a un réseau plus étendu et plus mature. CloudFront reste le meilleur CDN du marché.\n\n### IAM & sécurité : avantage AWS\n\n| Critère | AWS IAM | GCP IAM |\n|---------|---------|---------|\n| Granularité | Très fine | Fine |\n| Policies | JSON détaillé | Rôles prédéfinis + custom |\n| SSO intégration | Mature | Bon |\n| Audit | CloudTrail (excellent) | Cloud Audit Logs (bon) |\n| Compliance | Plus de certifications | En rattrapage |\n\n**Verdict** : AWS a plus d'expérience en sécurité enterprise. Pour des clients comme des enseignes de distribution qui auditent notre infra, c'est un argument.\n\n### Data & Analytics : avantage massif GCP\n\n| Critère | AWS | GCP |\n|---------|-----|-----|\n| Data warehouse | Redshift (bon, cher) | BigQuery (excellent, serverless) |\n| Data processing | EMR / Glue | Dataflow / Dataproc |\n| ML/AI | SageMaker | Vertex AI |\n| Intégration | Fragmentée | Très cohérente |\n\n**Verdict** : BigQuery est le meilleur produit de Google Cloud. Pour de l'analytics sur nos données de commandes, c'aurait été un upgrade massif. C'est peut-être l'opportunité manquée la plus significative.\n\n### Le score final\n\n| Domaine | Gagnant |\n|---------|---------|\n| Kubernetes | GCP |\n| Base de données | Égalité |\n| Messaging | GCP |\n| Monitoring | GCP |\n| Réseau/CDN | AWS |\n| IAM/Sécurité | AWS |\n| Data/Analytics | GCP |\n| Écosystème/Market share | AWS |\n| **Score** | **GCP 4 - AWS 3 (+ 1 égalité)** |\n\nSur le papier, GCP gagne. Mais le score ne capture pas le **coût du changement**, qui est le vrai sujet.\n\n## Chapitre 5 : Ce qui se serait passé si on avait migré\n\n### Le scénario optimiste\n\nAvec le support de Google et du cabinet partenaire :\n\n**Mois 1-2** : audit, plan de migration, POC sur GKE Autopilot\n**Mois 3-4** : migration des services non-critiques, double run\n**Mois 5-6** : migration de la production, bascule DNS, décommissionnement AWS\n\nRésultat après 6 mois :\n- **GKE Autopilot** réduit la charge ops de 40%\n- **Coûts cloud** réduits de 25-35% (crédits Google + pricing compétitif + FinOps intégré)\n- **BigQuery** opérationnel pour l'analytics\n- **DevOps** libérés pour travailler sur l'amélioration continue au lieu de l'ops K8s\n- **Codebase modernisée** : la migration a forcé le nettoyage de la dette technique\n\n### Le scénario pessimiste (et réaliste)\n\n**Mois 1-2** : audit et plan — tout va bien\n**Mois 3** : on commence la migration... et on découvre des dépendances cachées. Un service utilise une feature spécifique de SQS FIFO qui n'a pas d'équivalent exact dans Pub/Sub. Le mapping IAM est plus complexe que prévu\n**Mois 4** : les DevOps sont submergés. Un incident production sur AWS nécessite leur attention, la migration prend du retard\n**Mois 5** : un client enterprise demande un audit de sécurité. On leur explique qu'on est en pleine migration cloud. Ils paniquent\n**Mois 6-8** : la migration se termine finalement avec 2 mois de retard, quelques incidents mineurs, et une équipe épuisée\n**Mois 9-12** : stabilisation, correction des bugs post-migration, formation de l'équipe\n\nRésultat : les bénéfices arrivent, mais **après 9-12 mois au lieu de 6**. Le coût humain est significatif.\n\n### Le vrai risque : la réputation\n\nLe pire scénario n'est pas technique. C'est un **incident client** pendant la migration. Un downtime de 4 heures sur le système de commandes d'un client clé un vendredi après-midi, avec comme root cause \"on était en train de migrer de cloud\"... C'est le genre d'événement qui peut coûter un contrat.\n\nPour une startup B2B qui se bat pour gagner la confiance de grands comptes, la stabilité perçue est aussi importante que la stabilité réelle.\n\n## Chapitre 6 : Les leçons apprises\n\n### 1. Le meilleur cloud est celui que votre équipe maîtrise\n\nLa supériorité technique de GKE sur EKS est réelle. Mais une équipe de 2 DevOps qui connaît AWS par cœur sera plus efficace sur AWS qu'une équipe de 2 DevOps qui apprend GCP, même si GCP est \"objectivement meilleur\".\n\n**La maîtrise opérationnelle bat la supériorité technique.** Surtout avec une petite équipe.\n\n### 2. Le coût du changement est toujours sous-estimé\n\nTout plan de migration sous-estime :\n- Le temps de formation\n- Les incompatibilités subtiles entre services \"équivalents\"\n- L'impact sur le moral de l'équipe (fatigue du changement)\n- Le coût d'opportunité (pendant qu'on migre, on ne développe pas de features)\n\n### 3. Le timing compte plus que la technologie\n\nSi DJUST avait été en phase de construction (2021-2022), la migration vers GCP aurait eu du sens. Le code n'est pas encore en production critique, l'équipe est petite et agile, les clients sont peu nombreux.\n\nEn 2024, avec des clients enterprise en production et des SLA contractuels, le calcul risque/bénéfice a changé. **Le bon moment pour migrer était il y a 2 ans ou dans 2 ans — pas maintenant.**\n\n### 4. L'optimisation du cloud actuel est souvent le meilleur ROI\n\nNotre plan d'optimisation AWS a donné des résultats concrets :\n- **Savings Plans** : -35% sur le compute\n- **Rightsizing** : -20% sur les instances surdimensionnées\n- **GP2 → GP3** : -20% sur le stockage EBS\n- **Nettoyage** : suppression des ressources orphelines (snapshots, volumes non attachés)\n\nTotal : environ **-30% sur la facture AWS**, sans aucun risque opérationnel, en quelques semaines de travail.\n\nC'est moins que ce qu'une migration GCP aurait apporté à long terme, mais le ROI est **immédiat et sans risque**.\n\n### 5. Les crédits cloud sont un piège stratégique\n\nAWS Activate, Google Cloud Credits, Azure for Startups — tous les clouds offrent des crédits aux startups. Le problème : ces crédits créent un **lock-in initial**. Vous construisez votre stack sur un cloud parce qu'il est \"gratuit\", puis les crédits expirent, et vous êtes piégé par les coûts de migration.\n\nLe conseil : dès le jour 1, abstraire autant que possible les services cloud-spécifiques. Utiliser Kubernetes (portable), PostgreSQL standard (portable), S3 compatible (MinIO en local). Minimiser les services propriétaires (SQS, SNS, DynamoDB) qui créent du lock-in.\n\n### 6. Le cloud-agnostic est un idéal, pas une réalité\n\nCela dit, être 100% cloud-agnostic est une chimère. Vous finirez toujours par utiliser des services managés spécifiques (RDS, EKS, CloudFront). L'objectif réaliste n'est pas le cloud-agnostic, c'est la **réduction du coût de migration**. Chaque choix architectural devrait être évalué avec la question : \"combien ça coûterait de changer ça si on devait migrer ?\"\n\n### 7. Avec 2 DevOps, chaque décision d'infra est critique\n\nC'est peut-être la leçon la plus importante. Avec une équipe ops de 2 personnes :\n- **Chaque service ajouté** est un service de plus à maintenir\n- **Chaque migration** consomme une part significative du bandwidth total\n- **Chaque incident** mobilise 50% de l'équipe ops\n\nLa contrainte n'est pas technique. C'est le **temps humain disponible**. Et c'est cette contrainte qui, in fine, a fait pencher la balance vers \"on reste et on optimise\".\n\n## Chapitre 7 : Et si c'était à refaire ?\n\n### Ce que je changerais\n\nSi je pouvais revenir en 2021, au démarrage de DJUST :\n\n1. **Je commencerais sur GCP** plutôt qu'AWS. GKE Autopilot dès le jour 1 aurait évité toute cette histoire\n2. **J'abstrairais le messaging** : utiliser un broker standard (RabbitMQ, NATS) au lieu de SQS, pour rester portable\n3. **J'intégrerais BigQuery** dès le début pour l'analytics\n4. **Je mettrais en place du FinOps** dès le mois 1, pas après 3 ans\n\n### Ce que je garderais\n\n1. **La décision de rester en 2024** : dans le contexte de l'époque (clients enterprise, petite équipe, SLA), c'était la bonne décision\n2. **L'optimisation AWS** : le ROI immédiat sans risque, c'est pragmatique\n3. **La relation avec Google** : même sans migrer, les événements Google Cloud nous ont ouvert les yeux sur ce qui se fait ailleurs. Et la porte reste ouverte\n\n### Ce qui pourrait changer\n\nDJUST grandit. L'équipe DevOps pourrait passer à 4-5 personnes. Les crédits Google pourraient être renégociés. Le marché évolue. Une migration reste possible — mais elle se ferait à un moment choisi, pas sous la pression d'une offre commerciale.\n\n## Conclusion\n\nCette histoire n'est pas un échec. C'est une **leçon de pragmatisme**.\n\nEn tant qu'ingénieur, j'aurais voulu migrer. GKE est meilleur qu'EKS. BigQuery nous aurait ouvert des portes. La modernisation de la codebase aurait fait du bien. Et travailler avec des ingénieurs Google, c'est une opportunité rare.\n\nMais en tant qu'Engineering Manager, je comprends la décision de la direction. Quand vous servez des clients enterprise avec des SLA, que votre équipe ops fait 2 personnes, et que votre plateforme est en croissance — **la stabilité est une feature**. La plus importante, même.\n\nLe cloud n'est pas une religion. AWS n'est pas \"mauvais\" et GCP n'est pas \"meilleur\". Ce sont des outils, et le bon choix dépend du contexte : la taille de l'équipe, la maturité du produit, les contraintes clients, le timing.\n\nSi vous êtes dans une situation similaire — Google ou Azure qui vous courtise pour quitter AWS — posez-vous ces questions :\n- Quelle est la taille de mon équipe ops ?\n- Quels sont mes SLA clients ?\n- Est-ce que j'ai le bandwidth pour une migration ET le run quotidien ?\n- Est-ce que le ROI justifie le risque ?\n\nSi la réponse à la dernière question n'est pas un \"oui\" clair, restez et optimisez. Le meilleur cloud, c'est celui qui vous laisse dormir la nuit.\n\n---\n\n*Chetana YIN — Février 2026*\n*Engineering Manager chez DJUST, partisan de GCP qui dort bien sur AWS.*","## Introduction\n\nIn 2024, Google Cloud invited my team and me at DJUST to a series of exclusive events. The pitch was clear: **\"You've been on AWS for 4 years. Come to us, we'll support your migration, and we'll offer you substantial cloud credits.\"**\n\nGoogle wasn't doing this out of charity. DJUST is a B2B SaaS e-commerce platform processing orders for clients in food distribution, construction, and fashion. It's exactly the type of workload GCP wants to attract: Java/Spring Boot, Kubernetes, PostgreSQL, Elasticsearch — everything Google Cloud excels at.\n\nI was completely in favor. I saw this migration as a unique opportunity: not just saving on cloud costs, but above all **modernizing our codebase** by working hand-in-hand with Google engineers and a partner cloud consulting firm. It was the perfect chance to pay down technical debt while being supported by experts.\n\nBut DJUST's leadership said no. And in hindsight, I understand why — even though part of me still regrets the missed opportunity.\n\nHere's the full story, the technical analysis, and the lessons I've drawn.\n\n## Chapter 1: Context — DJUST on AWS\n\n### How we ended up on AWS\n\nDJUST was created in 2021. Like 90% of tech startups, the initial cloud choice was pragmatic:\n\n- **AWS Activate credits**: Amazon offers up to $100,000 in credits to startups. For a company just starting out, it's a massive argument\n- **Familiarity**: the first developers (including me, as Lead Software Engineer) knew AWS. EC2, RDS, S3, SQS — it's the lingua franca of cloud\n- **Ecosystem**: more documentation, more tutorials, more StackOverflow answers for AWS than any other cloud\n\nThe choice wasn't based on a detailed benchmark. It was: \"We know AWS, we have credits, let's go.\" And that's **normal** for a startup in build phase. The priority is shipping the product, not optimizing infrastructure.\n\n### Our AWS stack in 2024\n\nAfter 3 years of development, our infrastructure looked like this:\n\n- **EKS** (Elastic Kubernetes Service): our managed Kubernetes cluster, hosting ~15 Spring Boot microservices\n- **RDS PostgreSQL**: our main database (multi-AZ for high availability)\n- **ElastiCache Redis**: cache and sessions\n- **Amazon Elasticsearch Service**: product search engine\n- **SQS**: messaging between microservices (orders, payments, notifications)\n- **S3**: asset storage (product images, documents)\n- **ECR**: Docker registry for our images\n- **CloudFront**: CDN for the frontend\n- **Route 53**: DNS\n- **IAM**: access management\n- **CloudWatch**: monitoring and logs\n\nAll managed by **2 DevOps engineers**. Two people. For a platform serving enterprise clients with demanding SLAs.\n\n### The pain points\n\nAfter 3 years on AWS, we'd accumulated frustrations:\n\n**1. Exploding costs**\n\nThe Activate credits had run out. And the AWS bill had a clear trend: **it went up every month**. EKS alone costs ~$75/month just for the control plane, before even adding nodes. Multi-AZ RDS is expensive. ElastiCache is expensive. And above all: AWS is **notoriously opaque** about its pricing. Understanding your AWS bill is a job in itself.\n\n**2. Operational complexity**\n\nWith 2 DevOps managing all of this, we were constantly in firefighting mode. An EKS upgrade? That's a week of preparation. An RDS incident? Everyone's on alert. The operational burden was disproportionate to the team size.\n\n**3. AWS-tied technical debt**\n\nWe'd made quick choices early on (normal for a startup) that were becoming anchors:\n- Oversized EC2 instances \"just to be safe\"\n- Unoptimized services (unused Reserved Instances, GP2 instead of GP3)\n- Partial and expensive CloudWatch monitoring\n- No structured FinOps\n\n## Chapter 2: Google's Offer\n\n### The Google Cloud events\n\nGoogle Cloud has an aggressive strategy to attract AWS customers. They identify growing companies on AWS and offer personalized support.\n\nFor DJUST, this materialized as:\n\n- **Invitations to Google Cloud events**: technical workshops, client case presentations, networking with tech decision-makers\n- **Technical engagement**: Google Cloud engineers ready to work with us on a detailed migration plan\n- **Partnership with a partner cloud consulting firm**: specializing in cloud migrations, which would have provided operational migration support\n- **GCP credits**: substantial cloud credits to cover the migration period and beyond (often $100K-300K over 1-2 years for this type of deal)\n\n### What GCP was putting on the table\n\n**GKE (Google Kubernetes Engine) vs EKS**\n\nThis is Google's strongest point. GKE is unanimously recognized as the **best managed Kubernetes on the market**:\n- **Autopilot**: GKE manages nodes automatically. With EKS, our DevOps spent time managing node groups\n- **Cost**: GKE Autopilot = $0 for the control plane. EKS = $73/month fixed\n- **Upgrades**: GKE updates almost automatically. EKS requires planned manual updates\n- **Kubernetes was born at Google** — and it shows\n\nFor our 2-person DevOps team, GKE Autopilot would have been a **game changer**.\n\n**BigQuery — the missed opportunity**\n\nWe had no data warehouse. BigQuery would have opened the door to advanced analytics on our order, payment, and customer behavior data. It's Google Cloud's **best product**, with no direct AWS equivalent at the same price/performance.\n\n### The hidden opportunity: modernizing the codebase\n\nThis was what excited me most. A cloud migration is an opportunity to **review everything**: microservice architecture, FinOps, CI/CD, technical debt. And we wouldn't have been alone — Google engineers + the partner firm would have brought their expertise.\n\n## Chapter 3: Why Leadership Said No\n\n### The client risk argument\n\nDJUST serves enterprise clients with **contractual SLAs**. A 2-hour downtime isn't just a technical incident — it's a financial penalty and a loss of trust.\n\nA cloud migration for a platform our size means:\n- **3 to 6 months** of work minimum\n- Risk of **downtime** during the switchover\n- A costly **dual-run** period (both clouds in parallel)\n- **Unexpected bugs** from subtle differences between services\n- A **learning curve** for DevOps who know AWS inside out but not GCP\n\n### The team argument\n\nWith **2 DevOps**, we didn't have the bandwidth to maintain production AND pilot a migration simultaneously.\n\n### The short-term cost argument\n\nMigrating to save money costs money upfront: dual-run, consulting, training, human time. Estimated **6-12 months before positive ROI**.\n\n### The decision: optimize AWS\n\nLeadership decided: **stay on AWS, but optimize**. Savings Plans, rightsizing, GP2→GP3, resource cleanup. Result: approximately **-30% on the AWS bill**, with zero operational risk.\n\n## Chapter 4: AWS vs GCP — Deep Technical Analysis\n\n### Kubernetes: clear GCP advantage\n\nGKE is objectively better than EKS. Kubernetes was invented by Google, and it shows. GKE Autopilot ($0 control plane, automatic node management) would have significantly reduced operational burden for 2 DevOps.\n\n### Database: tie\n\nRDS PostgreSQL and Cloud SQL are comparable. AlloyDB (Google's PostgreSQL-compatible) could offer 4x performance for transactional workloads — interesting for our OMS.\n\n### Messaging: GCP advantage\n\nPub/Sub is more versatile than SQS: native pub/sub pattern, flexible ordering, simpler pricing.\n\n### Monitoring: GCP advantage\n\nCloudWatch is expensive. Google Cloud Monitoring has a generous free tier and native GKE integration.\n\n### Network/CDN: AWS advantage\n\nCloudFront remains the best CDN. AWS has 450+ points of presence vs GCP's 200+.\n\n### IAM/Security: AWS advantage\n\nMore certifications, more enterprise audit experience. Important for clients who audit our infrastructure.\n\n### Data/Analytics: massive GCP advantage\n\nBigQuery is the best product in Google Cloud. No direct equivalent at the same price/performance on AWS.\n\n### Final score: GCP 4 - AWS 3 (1 tie)\n\nOn paper, GCP wins. But the score doesn't capture the **cost of change**, which is the real issue.\n\n## Chapter 5: Lessons Learned\n\n### 1. The best cloud is the one your team masters\n\nGKE's technical superiority over EKS is real. But 2 DevOps who know AWS by heart will be more effective on AWS than 2 DevOps learning GCP. **Operational mastery beats technical superiority.**\n\n### 2. The cost of change is always underestimated\n\nEvery migration plan underestimates: training time, subtle incompatibilities, team morale impact, opportunity cost.\n\n### 3. Timing matters more than technology\n\nIn 2021 (build phase), migration would have made sense. In 2024 (enterprise clients, contractual SLAs), the risk/benefit calculation had changed.\n\n### 4. Optimizing your current cloud often has the best ROI\n\n-30% on the AWS bill, zero risk, a few weeks of work. Less than a GCP migration would have brought long-term, but **immediate and risk-free ROI**.\n\n### 5. Cloud credits are a strategic trap\n\nAll clouds offer startup credits that create initial lock-in. Advice: abstract cloud-specific services from day 1. Use Kubernetes (portable), standard PostgreSQL (portable), S3-compatible storage. Minimize proprietary services.\n\n### 6. With 2 DevOps, every infrastructure decision is critical\n\nThe constraint isn't technical. It's **available human time**. And it's this constraint that ultimately tipped the balance toward \"stay and optimize.\"\n\n## Conclusion\n\nThis story isn't a failure. It's a **lesson in pragmatism**.\n\nAs an engineer, I wanted to migrate. GKE is better than EKS. BigQuery would have opened doors. Working with Google engineers is a rare opportunity.\n\nBut as an Engineering Manager, I understand leadership's decision. When you serve enterprise clients with SLAs, your ops team is 2 people, and your platform is growing — **stability is a feature**. The most important one.\n\nThe cloud isn't a religion. AWS isn't \"bad\" and GCP isn't \"better.\" They're tools, and the right choice depends on context: team size, product maturity, client constraints, timing.\n\nIf you're in a similar situation — Google or Azure courting you to leave AWS — ask yourself:\n- How big is my ops team?\n- What are my client SLAs?\n- Do I have the bandwidth for a migration AND daily operations?\n- Does the ROI clearly justify the risk?\n\nIf the answer to the last question isn't a clear \"yes,\" stay and optimize. The best cloud is the one that lets you sleep at night.\n\n---\n\n*Chetana YIN — February 2026*\n*Engineering Manager at DJUST, GCP advocate who sleeps well on AWS.*","## សេចក្តីផ្តើម\n\nក្នុងឆ្នាំ 2024 Google Cloud បានអញ្ជើញក្រុមរបស់ខ្ញុំនៅ DJUST ទៅព្រឹត្តិការណ៍ផ្តាច់មុខជាច្រើន។ សំណើច្បាស់៖ **\"អ្នកនៅលើ AWS អស់ ៤ ឆ្នាំហើយ។ មកជាមួយយើង យើងនឹងជួយក្នុងការផ្លាស់ប្តូរ ហើយយើងផ្តល់ credit cloud ច្រើន។\"**\n\nខ្ញុំយល់ស្របទាំងស្រុង។ ខ្ញុំមើលឃើញក្នុងការផ្លាស់ប្តូរនេះជាឱកាសពិសេស៖ មិនត្រឹមតែសន្សំថ្លៃ cloud ប៉ុណ្ណោះទេ ថែមទាំង **ទំនើបកម្ម codebase** របស់យើងដោយធ្វើការជាមួយវិស្វករ Google និងក្រុមហ៊ុនពិគ្រោះ cloud ដៃគូ។\n\nប៉ុន្តែថ្នាក់ដឹកនាំ DJUST បាននិយាយថាទេ។ ហើយនៅពេលមើលថយក្រោយ ខ្ញុំយល់ពីមូលហេតុ។\n\n## AWS vs GCP — ការវិភាគ\n\n**Kubernetes**: GKE ល្អជាង EKS យ៉ាងច្បាស់។ GKE Autopilot គ្រប់គ្រង nodes ដោយស្វ័យប្រវត្តិ control plane ឥតគិតថ្លៃ។ សម្រាប់ក្រុម DevOps ២ នាក់ វាជា game changer។\n\n**មូលដ្ឋានទិន្នន័យ**: RDS PostgreSQL និង Cloud SQL ស្មើគ្នា។ AlloyDB អាចផ្តល់ប្រសិទ្ធភាព 4x សម្រាប់ workloads ប្រតិបត្តិការ។\n\n**Analytics**: BigQuery ជាផលិតផលល្អបំផុតរបស់ Google Cloud ដែលគ្មានសមភាគផ្ទាល់នៅ AWS។\n\n## ហេតុអ្វីយើងនៅលើ AWS\n\nជាមួយ DevOps ២ នាក់ អតិថិជន enterprise និង SLA កិច្ចសន្យា ហានិភ័យនៃការផ្លាស់ប្តូរខ្ពស់ពេក។ ការបង្កើនប្រសិទ្ធភាព AWS បានផ្តល់ **-30%** លើវិក្កយបត្រ ដោយគ្មានហានិភ័យប្រតិបត្តិការ។\n\n## មេរៀន\n\n- Cloud ល្អបំផុតគឺដែលក្រុមរបស់អ្នកស្គាល់\n- ការចំណាorg នៃការផ្លាស់ប្តូរត្រូវបានប៉ាន់ស្មានទាបជានិច្ច\n- ពេលវេលាសំខាន់ជាងបច្ចេកវិទ្យា\n- ស្ថេរភាពជា feature — feature សំខាន់បំផុត\n\nCloud មិនមែនជាសាសនាទេ។ ជម្រើorg ត្រឹមត្រូវអាស្រ័យលើបរិបទ។\n\n---\n\n*Chetana YIN — កុម្ភៈ 2026*\n*Engineering Manager នៅ DJUST អ្នកគាំទ org GCP ដែលគេងស្រួលនៅលើ AWS។*","Google nous a proposé de migrer de AWS vers GCP avec accompagnement et crédits. Avec 2 DevOps et des clients enterprise, on a choisi de rester. Analyse technique complète AWS vs GCP et leçons apprises.","Google offered to migrate us from AWS to GCP with support and credits. With 2 DevOps and enterprise clients, we chose to stay. Complete AWS vs GCP technical analysis and lessons learned.","Google បានស្នើឱ្យយើងផ្លាស់ប្តូរពី AWS ទៅ GCP ជាមួយការគាំទ្រ និង credits។ ជាមួយ DevOps ២ នាក់ និងអតិថិជន enterprise យើងបានជ្រើសរើសនៅ។ ការវិភាគបច្ចេកទorg ពេញលេorg AWS vs GCP។",[16,17,18,19,20,21],"AWS","GCP","Cloud","DevOps","Kubernetes","Infrastructure","2026-01-23T19:00:00",[]]