GCP vs AWS pour un développeur Java : ce qui change vraiment

Arriver sur une mission GCP avec des réflexes AWS fonctionne, jusqu'au jour où un détail structurel (pas un nom de service) casse une hypothèse qu'on ne savait même pas avoir faite. J'ai fini par formaliser ces écarts dans GCPTrainer, pas pour bachoter une certification, mais pour ce qui compte vraiment en mission : les pièges de transposition.

Le VPC n'a pas la même portée#

C'est l'écart le plus coûteux à découvrir en production plutôt qu'à l'avance :

Un développeur qui arrive d'AWS reproduit souvent le réflexe « un VPC par région » sur GCP, ce qui ajoute de la complexité de peering pour un problème que GCP résout nativement par construction. À l'inverse, supposer qu'un VPC GCP se comporte comme un VPC AWS régional revient à sous-estimer sa portée réelle lors d'une conception multi-région.

IAM : deux modèles mentaux différents, pas juste deux syntaxes#

AWS raisonne en documents de policy JSON attachés à un principal (utilisateur, rôle, groupe), avec des règles explicites d'allow et de deny évaluées ensemble. GCP raisonne en hiérarchie de ressources : organisation, dossiers, projets, ressources, avec des rôles liés (IAM bindings) qui héritent automatiquement du niveau au-dessus, sauf ressource concernée par une politique de deny explicite (rare, réservée aux cas critiques).

AWS : principal → policy document → permissions explicites
GCP : organisation → dossier → projet → ressource
      (un binding de rôle à un niveau s'applique à tout ce qui est en dessous)

La conséquence pratique : sur GCP, un rôle accordé au niveau du projet se propage automatiquement à toutes les ressources qu'il contient, sans action supplémentaire. Un développeur habitué à AWS s'attend à devoir attacher une policy à chaque ressource individuellement, et découvre parfois trop tard qu'un accès accordé plus haut dans la hiérarchie était déjà suffisant, ou au contraire beaucoup trop large.

Le compute ne se traduit pas un pour un#

Cloud Run mérite une mention à part : il couvre à la fois ce qu'AWS sépare entre Lambda (fonctions courtes) et Fargate (conteneurs longue durée), en scalant un conteneur HTTP classique de zéro à N instances. Un développeur qui cherche « l'équivalent Lambda » sur GCP part parfois sur Cloud Functions alors que Cloud Run, plus flexible, aurait mieux servi un besoin qui dépasse une simple fonction événementielle.

Ce qui ne se traduit pas du tout#

DynamoDB et Firestore sont souvent présentés comme équivalents parce que tous deux sont des bases NoSQL managées. Ce n'est vrai qu'en surface : DynamoDB expose un modèle clé-valeur avec un contrôle fin sur le partitionnement et la cohérence, pensé pour un accès prévisible à très haute échelle. Firestore expose un modèle document orienté requêtes riches et synchronisation temps réel, plus proche d'un usage applicatif direct que d'un moteur de données bas niveau. Migrer un schéma DynamoDB vers Firestore sans repenser les requêtes est une source classique de mauvaises surprises de performance.

Ce que ça change concrètement#

La leçon qui dépasse GCP et AWS eux-mêmes : deux services au nom qui se traduit presque parfaitement peuvent porter des modèles structurels incompatibles. Avant de transposer une architecture d'un cloud à l'autre, la question à se poser n'est jamais « quel est l'équivalent de X », mais « quelle contrainte structurelle X impose-t-il, et l'autre plateforme impose-t-elle la même ». C'est cette question, pas le nom du service, qui détermine si la transposition tient la route.