Les clouds sont-ils vraiment une valeur sûre ?

Vérifier à quel point les clouds sont une valeur sûre n’est pas un jeu d’enfant. Toutes les études réalisées doivent être considérées avec minutie. Mais elles sont source d’informations d’intérêt.

 

Les clouds sont-ils une valeur sûre ? La Question est parfaitement justifiée, mais la réponse n’est pas facile à trouver, car son étude elle-même n’est pas facile. Encore plus, quand la question est si généraliste. Comme aujourd’hui, les plus grands clouds forma une galaxie gigantesque de source d’infrastructures en IaaS, de services et de plateforme middleware en PaaS ou Serverless et d’applications (Machine Learning, sécurité, Surveillance …) en SaaS. Jauger la sureté des clouds entraine la mesure la sureté de toute la galaxie. Un exercice difficile, voire même impossible. Bien évidemment, quelque organisme tente le coup comme Gartner (avec sa division CloudHarmony), Krystalize (qui offre aux entreprises ses services pour jauger la sureté et la qualité de leurs opérations dans le Cloud) ou de Cloud Spectator. Ces organismes sorte quotidiennement des index comparatifs et des résultats de tests dans but plutôt généraliste.

 

Les benchmarks sont limités

 

Ce qui ne va pas dans les tests, c’est qu’ils proposent qu’une seule vision extrêmement étriquée. En générale ils se basent sur la surveillance de VMs hébergée dans une seule région ou alors sur la surveillance d’un service de stockage. En revanche, ce n’est pas parce ce qu’un serveur est évalué sur le IaaS, un stockage sur IaaS, ou une basse de données en PaaS que toutes les conclusions sont possible quant à la qualité et à la sureté de la totalité de l’offre Clouds. En d’autres mots, ces benchmarks en révèlent beaucoup plus sur l’idée et sur l’infrastructure des organismes de tests que sur le cloud que l’on teste.

Ce n’est pas que ces tests sont inutiles. Chacun d’entre eux ont la possibilité d’être un élément d’un tout dont il manque la plupart des éléments, afin que le profil tracé soit vraiment significatif et objectif. Autrement dit, ces tests sont potentiellement ceux qui révéleront une défaillance ou des différences de comportement qui sont d’un côté, pratique pour les clouds afin d’améliorer leurs offres, et d’un autre côté, pratiquent aux entreprises afin de définir des bonnes pratiques. On peut illustrer tout ça en concevant des « métas-API » pouvant, appeler indifféremment les API cognitives de clouds différents afin qu’une application marche toujours même si les API d’un cloud sont inaccessible durant une courte période.

 

Concevoir ces propres métriques

 

Dans l’état actuel des choses, les Benchmarks disponibles ne refléteront pas forcément votre propose expérience en tant qu’entreprise cliente. Ainsi, il est préférable de mettre vos propres métriques dans vos applications dans vos services cloud et de cette façon contrôler à la fois la disponibilité, la sureté, la bande passante comme la pertinence et le rapport qualités/prix des services donc vous vous servez. Dans cette optique les nouveaux outils multiclouds trouveront grâce à vos yeux comme (Nutanix Xi Epoch, Scalr, Embotics, Turbonomic, CLoudHealth, HyperGrid) tout en vous permettant de faire des comparaisons entre le ROI d’un même service hébergé chez vous (sur l’infrastructure Nutanix entreprise Cloud) et sur les grands clouds publics.

 

Qu’est-ce qui est le mieux entre Google, Amazon et Azure

 

Tous les clouds offrent des tableaux de bord afin de suivre le fonctionnement de ses services. Azure-lui n’a pas un super visuel et n’est pas très parlant sur la durée et la sévérité des incidents, mais donne un bon nombre de détails sur l’impact, l’origine et la résolution mise en œuvre par Microsoft. Google lui est plus parlant et fournie des détails sur la durée de l’incident, mais en revanche en fournie peu sur son origine, aux solutions à apporter et aux zones affectées. Et enfin, Amazon est pointu sur les zones affectées, mais ne fournit pas les origines et les solutions à apporter. En d’autres termes, Microsoft restreint maintenant la vision des incidents sur 90 jours, bien que les autres clouds le font sur 365 jours.

 

Les chiffres contre-attaquent

 

Quelques analystes se réfèrent justement à ces rapports pour déterminer la sureté des Clouds en faisant la somme des temps d’indisponibilité affichés sur tous les incidents. Pour ça, AWS est le premier avec 338 minutes d’indisponibilité, devant GCP avec 361 minutes d’indisponibilité et enfin avec Azure avec 1800 minutes d’indisponibilité. Le souci avec un tel point de vue, c’est que tous ces clouds n’offrent ni le même nombre ni le même genre de services et qu’ajouter comme ça les services ne reflète en rien le quotidien des entreprises. Sans compter que les clouds n’ont pas façon de voir de l’heure de fin d’un incident (est-ce que c’est quand le fix a été activé ou alors quand la situation est revenue à la normale en termes de de bande passante et temps de réponse ?).

Le manque de pertinence de ces chiffres est notamment observé durant le dernier Google Cloud Next de San Francisco. Durant le Keynote, Google est passé très rapidement sur partis censés justifier la supériorité de GCP : faite à partir des données de Krystaze et Gartner, il donnait 208 minutes d’indisponibilité à GCP, cotre 312 à AWS et 2033 à Azure. La raison pour laquelle Google est passé si vite sur ce chiffre c’est que ses propres experts connaissent l’absence de véracité traduite par ces mesures et ne n’y accorde que peu d’importance.

De plus quand ont est un peu observateur, on peut voir que Gartner a eu des résultats très différents de ceux annoncés en son nom par Google sur ses tests de VM IaaS : avec 7 minutes d’indisponibilité sur l’année pour AWS, avec 10 minutes de pour GCP en avec 109 minutes pour Azure.

 

Proche des 99.999

 

Si on se fit à Gartner, les clouds ont des résultats proches des 99.999% de sureté sur un an : 99.9987% pour AWS ; 99.9982% pour GCP et 99.992% pour Azure, selon l’estimation des analystes sur la « zone américain ». Le Cloud de Microsoft a été sur cette zone très toucher par le fait qu’un des ses datacenters a été soudainement touché par la foudre en Septembre 2018.

Comme dit plus haut, ces chiffres doivent être utilisés avec beaucoup de finesse.

Mais ils fournissent tout de même certaines réalités. En premier lieu, la sureté de tous les clouds en 2018 a été en partie touchée par l’obligation de patcher et redémarrer tous les serveurs après que les défaillances Spectre et Meltdown a été découvertes.

Puis ils soulignent les différences d’approche, AWS et GCP ont d’abord concentré leurs cloud sur des zones de disponibilités (Availability Zones) pour assurer sur une même région la redondance des services. À l’opposer Azure a construit son cloud de façon à favoriser la multiplicité des régions (pour privilégier les temps de réponse) et la redondance des stockages au cœur des régions et entre régions sans prendre en compte de la redondance systématique des services eux-mêmes (pour la réalisée, les entreprises doivent la mettre en place entre les régions).

Depuis mars 2018, Microsoft veut aussi implémenter de façon progressive des « zones de disponibilité » au sein des régions. Paris et L’Iowa été les premières régions à profiter d’Availability Zones. D’autres régions US, Asie et Europe sont en train d’en profiter.

Durant la dernière conférence Buils 2019, le CEO d’Azure, Mark Russinovich, à reconsidérer les choix faits par Microsoft sur l’architecture d’Azure et sur de quelle manière les entreprises peuvent appréhender les problèmes de disponibilité de leurs actifs cloud. Il a aussi parlé de comment Microsoft cherchait à embellir la sureté d’Azure, d’un côté en généralisant les Availibility Zones, mais aussi en implémentant le projet Tardigrade (du nom de l’indestructible animal microscopique) résultat des recherches de Microsoft Research : dans la situation ou les pannes matérielles sont détecter ou alors que des fuites mémoires entrainent le crash du système et de la machine, les VM sont paralyser durant quelques secondes le temps de migrer les workloads sur un autre serveur avant qu’une panne ne touche la machine. Ces recherches montrent la disponibilité des services particulièrement en embellissant leurs infrastructures toutes comme via l’innovation technologique.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.