Des frappes iraniennes sur les Émirats arabes unis ont mis hors ligne le datacenter AWS de Dubaï ce week-end. Une triste première dans l’histoire du cloud computing.
On découvre qu’il n’y a pas que les centrales électriques et les centrales nucléaires qui ont de l’importance de nos jours !
C’est étonnant. Normalement les DC sont censés être redonnés. Que le bâtiment soit perdu ou coupé…soit. Mais que tout soit ko …
Non, les services cloud, ce n’est pas nécessairement redondé.
Chaque client décide, pour chaque service qu’il utilise, le niveau de redondance à utiliser. Et il paye en conséquence, donc selon les priorité du client, il n’y a pas forcément de redondance.
Et encore, la redondance elle peut être assez limitée géographiquement, selon la nature des services.
En tout cas, c’est comme ça que ça se passe avec GCP, mais je suppose qu’AWS est pareil, y a pas vraiment de raison que ça soit différent.
Par exemple, sur GCP, pour une instance Cloud SQL, ton instance ne peut être que sur une seule « région », et elle peut être sur deux « zones » de cette région (pour le double du prix par rapport à une seule zone).
Et deux « zones » d’une même région, ce sont bien deux DC physiquement distincts, mais pas forcément très éloignés l’un de l’autre (par exemple, la région europe-west3, c’est des DC qui sont tous à Francfort, west6 c’est tout à Zurich, 9 c’est tout à Paris…).
Certains services sont disponibles aussi en double ou en multi-région, ce qui leur donne plus de résilience, mais c’est pas le cas de tous. Par exemple chez GCP tu as les buckets de stockage qui peuvent être sur plusieurs régions (mais quand même limité géographiquement : le double région, c’est forcément deux régions proches, par exemple tu peux avoir Belgique et Pays-Bas, ou Berlin et Francfort, mais pas Varsovie et Turin, et le multi-régions c’est que des régions d’un même continent).
Et à l’inverse, tu as des services qui ne sont accessibles qu’en mono-zone, comme les VM. Là si tu veux gérer de la redondance sur plusieurs DC, c’est à toi de le faire à la main, donc créer deux instances de VM distinctes, et gérer toit même la synchronisation des données et la répartition des requêtes.
1 « J'aime »
Ils sont chiants ces iraniens, sous prétexte qu’on les bombardent ils ripostent. La seule faille difficilement prévisible dans le plan de Trump et Hegseth.
He ben tu vois on en apprend tous les jours 
. Parce que pour moi qu’en entreprise les DC ne soient pas toujours éloignés ça s’entend mais sur des structures comme Amazon ou même Azure ça me paraît complètement dingue.
Chez tout les providers, par exemple, avec lesquels j’ai bossé les DC étaient éloigné d’au moins 90km avec des redondances. Idem pour différentes infrastructures que j’ai eu a gérer ou a mettre en place. La prochaine en date 1 en France l’autre en Allemagne…
En fait selon les besoins que tu as et les performances dont tu as besoin, avoir des DC proches peut être soit un avantage, soit un inconvénient.
Par exemple pour les bases de données managées, ils ne proposent que du multi-zones, pas du multi-région, parce que entre deux régions, les latences peuvent être trop élevées pour garantir la fiabilité du service.
Idem pour les buckets, là ils proposent du multi-région, mais en te signalant que ça a un coût en performances.
Après dans tous les cas, pour le client ça reste possible de faire du multi-région avec tous les services, c’est juste que pour ceux qui le proposent pas nativement, il faut que le client le gère lui même la synchronisation entre les instances. C’est ce qu’on fait dans ma boîte par exemple pour le Harbor, on a deux instances, une aux USA et une en Europe, et on gère les réplications avec des webhooks qui déclenchent des scripts de réplication.
Mais tout comme avec le on-premise ou des hébergements classiques, tu as toujours un paquet d’entreprises qui ont tout dans le même DC, parmi les clients des clouds providers, tu en as aussi un paquet qui mettent tout dans la même zone, par simple souci d’économie…
Ah et aussi, mention spéciale à celui (cas vécu) qui se croit malin en mettant une VM de front dans une région, une VM de back dans une autre, une base managée dans une 3ème… Comme ça tu comprends, si une région tombe, il perd pas tout… Mais y a quand même plus rien qui marche 
Et même quand ça marche, les performances sont aux fraises, avec 20ms de latence entre le backend et la db 