Cloud

Quelle est la fiabilité des clouds ?

Par Laurent Delattre, publié le 17 mai 2019

Mesurer la fiabilité des clouds est un exercice plus difficile qu’il n’y parait. Les différentes études publiées doivent être prises avec des pincettes. Mais ne sont pas dénuées d’informations utiles.

Quelle est la fiabilité des grands opérateurs cloud ? La question mérite d’être posée mais la réponse est loin d’être évidente car l’évaluation est loin d’être évidente. Surtout posée d’une façon aussi générale. Car chacun des grands Clouds est aujourd’hui une galaxie complexe de ressources d’infrastructures en mode IaaS, de plateformes et services middlewares en mode PaaS ou Serverless et d’applications (Surveillance, sécurité, Machine Learning, etc.) en mode SaaS. Mesurer la fiabilité des clouds reviendrait donc à mesurer la fiabilité de l’ensemble de la galaxie. Une tâche complexe pour ne pas dire impossible.
Certes, certains organismes s’y essayent à l’instar du Gartner (avec sa division CloudHarmony), Krystalize (qui propose aux entreprises ses services pour mesurer la fiabilité et la performance de leurs opérations dans le Cloud) ou de Cloud Spectator. Ces organismes publient régulièrement des indexs comparatifs et résultats de tests à vocation assez généralistes.

Des benchmarks limités

Le problème de ces tests, c’est qu’ils n’offrent qu’une vision extrêmement limitée. La plupart se basent sur la surveillance de VMs hébergées dans une seule région ou la surveillance d’un service de stockage. Mais ce n’est parce qu’on évalue un serveur sur le IaaS, un stockage sur le IaaS, ou une base de données en mode PaaS que l’on peut en conclure quoi que ce soit sur la fiabilité ou les performances de l’offre Cloud dans son ensemble. En outre, ces benchmarks en disent souvent plus long sur la pensée et l’infrastructure des organismes de tests que sur le cloud testé en lui-même.

Non pas que ces tests soient totalement inutiles. Chacun est susceptible de constituer une pièce d’un puzzle dont il manque malheureusement encore la plus grande partie des pièces pour que le profil tracé soit véritablement objectif et significatif. En outre, ces tests peuvent avoir le mérite pointer une défaillance ou des différences de comportement qui sont, d’une part, utiles aux clouds pour améliorer leurs prestations, et d’autre part, utiles aux entreprises pour définir des bonnes pratiques. Comme par exemple ne pas mettre tous ses œufs dans le même panier, ou encore concevoir des « métas-API » capables – par exemple – d’appeler indifféremment les API cognitives de clouds différents de sorte qu’une application fonctionne toujours même si les API d’un cloud sont momentanément inaccessibles.

Créez vos propres métriques

La réalité, c’est que les Benchmarks proposés ont assez peu de chance de refléter votre propre expérience en tant qu’entreprise cliente. Dès lors, mieux vaut incorporer vos propres métriques au sein de vos applications et de vos services cloud et ainsi contrôler à la fois la disponibilité, la fiabilité, la bande passante mais aussi la pertinence et le rapport qualité/prix des services que vous utilisez. De nouveaux outils multiclouds (Nutanix Xi Epoch, Scalr, Embotics, Turbonomic, CLoudHealth, HyperGrid) peuvent vous y aider et permettent même, à l’instar de Xi Beam de Nutanix, de réaliser des comparaisons entre le ROI d’un même service hébergé chez vous (sur l’infrastructure Nutanix Enterprise Cloud) et sur les différents grands clouds publics.

Amazon vs Google vs Azure

Par ailleurs chacun des clouds propose des tableaux de bord pour suivre le fonctionnement de ses services. Celui d’Azure n’est pas très visuel ni très parlant quant à la durée et la sévérité des incidents mais fournit nombre de détails sur l’impact, la cause et la résolution mise en place par Microsoft. Celui de Google est plus immédiatement parlant et fournit des détails quant à la durée de l’incident mais assez peu quant aux causes, aux remédiations et aux régions affectées. Celui d’Amazon est très précis sur les régions affectées mais les détails des causes et remédiations ne sont pas donnés. En outre, Microsoft limite désormais la vision des incidents sur 90 jours alors que les autres Clouds le font sur 365 jours.

Une guerre de chiffres

Certains analystes se basent justement sur ces rapports pour déterminer la fiabilité des Clouds en additionnant simplement l’ensemble des temps d’indisponibilité affichés sur l’ensemble des incidents. À ce petit jeu, AWS arrive en tête avec 338 minutes d’indisponibilité, devant GCP (361 minutes d’indisponibilité) et Azure (1800 minutes d’indisponibilité). Le problème d’une telle approche, c’est que tous ces clouds ne proposent ni le même nombre ni le même type de services et qu’ajouter ainsi l’ensemble des services ne transcrit en rien la réalité vécue par les entreprises. Sans compter que les clouds n’ont pas la même perception de l’heure de fin d’un incident (est-ce à partir du moment où le fix a été activé ou à partir du moment où la situation est revenue à la normale en termes de bande passante et temps de réponse ?).
Le manque de pertinence de ces chiffres s’est notamment vu lors du dernier Google Cloud Next de San Francisco. Lors du keynote, Google est passé à toute vitesse sur un slide censé prouver la supériorité de GCP : compilé à partir des données de Krystalize et Gartner, il donnait 208 minutes d’indisponibilité à GCP, contre 312 à AWS et 2033 à Azure. Et si Google est passé si vite sur ces chiffres, c’est parce que ses propres experts ont conscience de l’absence de véracité traduite par ces mesures et n’y croient pas eux-mêmes.
D’ailleurs, quand on y regarde de plus près, Gartner a mesuré des résultats très différents de ceux annoncés en son nom par Google sur ses tests de VM IaaS : 7 minutes d’indisponibilité sur l’année pour AWS, 10 minutes pour GCP et 109 minutes pour Azure.

Des 99,999 pas loin d’être tenus…

Toujours si l’on en croit le Gartner, les clouds affichent des résultats proches des 99,999% de fiabilité sur un an : 99,9987% pour AWS ; 99,9982% pour GCP et 99,9792% pour Azure, selon les mesures de ses analystes sur la « zone américaine ». Le cloud de Microsoft a été sur cette zone particulièrement affectée par le fait qu’un de ses datacenters a été violemment frappé par la foudre en Septembre 2018.
Comme déjà dit, tous ces chiffres doivent être pris avec beaucoup de précautions.
Mais ils traduisent quand même quelques réalités. D’abord la fiabilité de tous ces clouds en 2018 a été en partie affectée par la nécessité de patcher et redémarrer tous les serveurs après la découverte des failles Spectre et Meltdown.
Ensuite, ils mettent en évidence les différences d’approche. AWS et GCP ont d’abord basé leurs clouds sur des zones de disponibilités (Availability Zones) afin de s’assurer sur une même région la redondance des services. Azure à l’inverse a conçu son Cloud en privilégiant la multiplicité des régions (pour favoriser les temps des réponses) et la redondance des stockages au sein des régions et entre les régions sans se préoccuper de la redondance systématique des services eux-mêmes (pour la concrétiser, les entreprises doivent donc la mettre en œuvre entre les régions).
Depuis Mars 2018, Microsoft a décidé d’implémenter également et progressivement des « zones de disponibilité » dans ses régions. L’Iowa et Paris ont été les deux premières régions à disposer d’Availability Zones. D’autres régions US, Europe et Asie sont en train d’en bénéficier.
Lors de la dernière conférence Build 2019, Mark Russinovich, le CTO d’Azure est revenu sur les choix faits par Microsoft concernant l’architecture d’Azure et sur comment les entreprises peuvent appréhender les problématiques de disponibilité de leurs actifs cloud. Il a également évoqué comment Microsoft cherchait à améliorer la fiabilité d’Azure, d’une part en généralisant les Availibility Zones mais également en implémentant le projet Tardigrade (du nom de l’indestructible animal microscopique) fruit des recherches de Microsoft Research : en cas de détection de pannes matérielles ou de fuites mémoire engendrant le crash du système et de la machine, les VM sont figées quelques secondes le temps de migrer les workloads sur un autre serveur avant que la panne n’impacte la machine. Ces recherches reflètent la volonté des grands clouds de soigner la disponibilité des services notamment en améliorant leurs infrastructures mais aussi par le biais d’innovations technologiques.

Dans l'actualité