Le cloud Azure de Microsoft en panne au niveau mondial

En effet, les chiffres sont à relativiser, tant en termes d'impact, que sur l'expression même de la disponibilité.

En effet, le calcul fait par le groupe IWGCR porte sur le cumul des indisponibilités sur plusieurs années, ce qui implique que l'uptime exprimé résulte de ce cumul et qu'il n'est pas annuel, contrairement à l'expression de la disponibilité dans un contrat.

Sauf pour Azure en l'occurence, vu que les 111.5 h d'indisponibilité sont toutes sur 2012.

Tout à fait d'accord. Il faudrait une comparaison plus détailée/fine pour pouvoir établir un classement refletant réelement la qualité de service offert par chaque solution cloud.

note : attention les chiffres que vous donnez correspondent au cumul d'indisponibilité de 2007 à 2012 et comme de nombreuses années manquent ils ne veulent pas dire grand chose.

L'update de l'étude citée en date de juin 2013 est en effet intéressant.
(Source : http://iwgcr.org/wp-content/uploads/2013/06/IWGCR-Paris.Ranking-003.2-en.pdf)

Entreprise : Somme indisponibilité (h)
VMware Cloud Foundry : 10
Google Apps : 28,93
Windows Azure : 111,4
OVH : 170
AWS 224,7

Il convient de comparer des Clouds offrant des services similaires (Iaas/PaaS/Saas), donc Azure, AWS, (voire OVH).

A noter, que la somme des indisponiblité présentée dans cette étude semble globale/generique et qu'elle n'implique pas nécessairement une mise hors ligne de l'ensemble des services, dans l'ensembles des zones géographiques où ces derniers sont présents.

Ce qui est à retenir de mon point de vue, c'est que les éditeurs de solution globale présentent tous les 3 un total d'indisponibilité notable, aboutissant à une disponibilité inférieure à 99,000% . Ce qui s'explique très probablement par le périmètre fonctionnel de ces Clouds du fait des services qu'ils délivrent et de leur "jeunesse".

Par jeunesse, j'entends le rapport entre l'effort de capitalisation sur les pannes et de réflexion autour de l'optimisation des patterns d'architecture d'une part et la complexité intrinsèque des solutions mises en oeuvre pour assurer le fontionnement de ces Clouds.

Au fil des erreurs liées à des problèmatiques de renouvellement de certificats, d'erreur humaine, de mise à jour de firmware, etc, le degré d'automatisation devrait "logiquement" être encore augmenté, tout comme les mesures de contrôles associées aux changement.
Mais cela prendra encore du temps.

Après, et dans un souci d'objectivité, les entreprises devraient comparer la disponibilité des ressources qu'elles hébergent on premise et qu'elles envisagent potentiellement de déplacer dans le Cloud, de manière à identifier les risques de dégradation du service, ou les améliorations (sait-on jamais).

Visiteur3246 -> Merci bien de la précision concernant l'étude que vous mentionnez.

Le propos initial concernant MS semble de fait factuel et justifié, au regard de l'indispo d'Azure décrite par la synthèse de l'étude citée.

Tout à fait d'accord avec tout ce que vous écrivez Visiteur3239. Chaque personne fait son choix en fonction des critères qui sont important pour lui, et les clouds dans leur ensemble ont encore des progrès à faire.

Ceci étant dit un groupe de travail international sur la résilience du cloud computing (IWGCR), publie une étude sur la disponibilité des services clouds. L'étude référence 28 fournisseurs de clouds et a comptabilisé au total, en 2012, 389 heures d'indisponibilité. La palme de l'indisponibilité revenant à Microsoft Azure avec 111,5 heures de pannes...

Attendons 2014 pour voir si 2013 a été une meilleure année pour Azure, mais j'en doute...
(panne en début d'année 2013 à cause des certificats SSL expirés)

"Encore une raison de plus qui me poussera à ne pas choisir le cloud MS..."

Les pannes d'ampleur pour les Cloud ne concernent pas que MS, mais aussi AWS, Google, Rackspace. Sans compter qu'avec les nombreux Cloud alternatifs qui se créés actuellement, fussent-ils d'une taille moins importante, ce problème risque de se multiplier.

Après, c'est comme pour le choix de la caisse au supermarché, çà peut toujours être le Cloud qu'on a choisi qui rencontre un problème (sauf qu'il n'y a pas de SLA, ni d'engagement de dispo au supermarché du coin :) ).

Bref, il existe certes un problème de fond à éclairer sur la généralisation de la panne, mais il suffit qu'elle soit liée à une fonctionnalité transverse indépendante de la zone géographique (Europe, US, autres) pour qu'elle impacte l'ensemble du Cloud MS. Auquel cas, on est pas dans un problème de compartimentation du Cloud, ni forcément de non conformité de l'architecture en place. Si la raison est rendue publique, ce point là poura être tranché.

Ceci dit, une phrase intéressante dans un commentaire d'un autre site : design it to work, not just to sell.
Autrement dit, le marketing du Cloud semble avoir encore un peu trop d'avance sur la réalité technique.

Au contraire cher Visiteur3218 !

La répartition globale des data et des service ne devrait pas être synonyme de la répartition globale des pannes ! Il ne doit pas y avoir de centralisation, c'est pas ça le cloud. Le cloud a été conçue (entre autres raisons) pour offrir la disponibilité maximum et assurer donc une tolérence très importante aux pannes... (redondance des datas et des services)

Il est donc bien logique que LMI (et tous les véritables spécialistes système et réseau) se posent la question de quel bétise Microsoft à pu bien faire dans la conception de son cloud pour qu'une tel panne (et surtout aussi longue) puisse se produire...

Encore une raison de plus qui me poussera à ne pas choisir le cloud MS...

Et cette panne doit ravir les détracteurs du cloud (qui sont quand même de moins en moins nombreux)

"mais le fait qu'elle ait touché un grand nombre de pays soulève des questions sur la façon dont a été construit le management de services sur son cloud"

Vous voulez du Cloud dispo partout, en un claquement de doigt, avec tous vos paramètres ?
Et vous découvrer maintenant que la gestion des Cloud est centralisée ?
Il y a du travail .......