Quel SLA pour le Cloud ? (par Lionel Laské, C2S)
Amazon, Microsoft, Google : quelles sont les différences entre les engagements de ces acteurs quant à la disponibilité de leur solution Cloud. Quels dédommagements attendre ? Quid du périmètre de leur responsabilité ? Comparatif.
Comme les hébergeurs traditionnels, les fournisseurs de solutions Cloud s'engagent via le Service Level Agreement (SLA), un document qui définit contractuellement la qualité du service à attendre.
Pour bien comprendre sur quoi ils s'engagent (et sur quoi ils ne s'engagent pas), je vous propose de faire une lecture croisée du SLA des solutions cloud : Amazon, Azure, Google App Engine, Google Apps et BPOS.
Disponibilité : 99,95%
La disponibilité des solutions de Cloud est assez uniforme entre les différents acteurs : le chiffre à retenir est : 99,95% de disponibilité. C'est un niveau de service très élevé. Rapporté aux nombres de minutes dans 1 année, cela signifie à peine 4 heures d'indisponibilité par an. Mais, on va le voir, ce n'est pas aussi simple que cela, car le mode de calcul est assez différent d'un fournisseur à l'autre.
Amazon Web Service
Amazon propose un niveau de disponibilité de 99,95%. Le mode de calcul du temps de disponibilité est décrit dans ce texte. Il y est notamment dit que le "'Pourcentage de Temps Utilisable Annuel' est calculé en soustrayant de 100% le pourcentage de périodes de 5 minutes pendant L'Année de Service durant laquelle Amazon EC2 était en statut de 'Région Indisponible'.
Pour Amazon, le calcul se base donc sur des périodes de 5 minutes (ce qui est plus facile à respecter que par période d'une minute) et surtout il s'appuie sur le statut de la "Région", c'est-à-dire l'indisponibilité de tout le datacenter. Ainsi en théorie s'il n'y a que votre machine virtuelle indisponible dans le datacenter pendant plusieurs semaines, cela n'empêche pas Amazon de respecter son engagement ! De plus si vous utilisez une instance pour une durée inférieure à un an, la plateforme est considérée comme ayant été disponible tout le reste du temps, ce qui a forcément un effet d'écrasement sur le taux global.
Windows Azure
Pour Azure, le niveau de disponibilité est également de 99,95%. Le texte qui détaille le calcul est lisible en cliquant ici. Pour Microsoft, la seule restriction importante dans l'engagement est qu'il n'est valable qu'à partir du moment où vous achetez deux instances qui se répliquent mutuellement. Dans la console d'administration Azure, il y a d'ailleurs un message d'avertissement qui rappelle lorsque vous n'avez qu'une seule instance.
Pour rester dans les solutions PaaS, Google App Engine propose également une disponibilité à 99,95%. A noter cependant que le document expliquant le SLA est encore à l'état de "brouillon" (Draft), ce qui est peu réconfortant pour les clients, car nous cela ne donne pas l'impression que c'est réellement un engagement...
Dans le texte, on notera que le calcul se fait par périodes mensuelles glissantes.
Google Apps
Google Apps, la solution SaaS de messagerie et collaboration de Google propose une disponibilité de 99,9%, un taux donc moins bon que 99,95%.
L'engagement est assez proche de celui de Google App Engine, le temps étant calculé sur un nombre de minutes par mois.
BPOS et Office 365
BPOS, la solution de messagerie SaaS de Microsoft propose elle aussi un niveau de disponibilité de 99,9%. Le calcul décrit dans le texte du SLA, est un peu différent et moins restrictif pour Microsoft.
En effet, le temps d'indisponibilité est dépendant du nombre d'utilisateurs ce qui peut diluer les problèmes d'indisponibilité d'un utilisateur particulier.
Par ailleurs, il est fait mention d'un temps d'indisponibilité planifié, désignant selon Microsoft "les périodes de Temps d'Indisponibilité que nous publions ou notifions au moins cinq jours avant le début dudit Temps d'Indisponibilité, ou une opération de maintenance ou de mise à jour planifiée du réseau, du matériel ou du Service, et ledit Temps d'Indisponibilité ne dépasse pas dix heures par année calendaire."
En toute logique, cette indisponibilité planifiée devrait se déduire de l'indisponibilité réelle, ce qui n'est pas le cas (à noter que jusqu'au mois de janvier 2011, Google intégrait également l'indisponibilité planifiée dans son calcul).
La solution Office 365, qui succède à BPOS, propose le même SLA.
Quel périmètre de responsabilité ?
Si un fournisseur de solutions Cloud ne tient pas ses engagements, est-il nécessairement responsable ? Là-dessus, même si le libellé diffère légèrement, on retrouve une réponse commune (et habituelle dans des contrats de services) : on ne peut pas demander l'impossible à un fournisseur.
Amazon détaille explicitement l'exclusion de son périmètre de responsabilité dans le texte de son SLA :
"L'Engagement de Service ne s'applique pas à toute indisponibilité, suspension ou résiliation de Amazon S2, ou tout autre problème de performance de Amazon S2 (...) causé par des facteurs échappant raisonnablement à notre contrôle, dont les cas de force majeure, les problèmes d'accès à internet ou les problèmes en rapport au delà du point de démarcation de Amazon S2, (...)"
On retrouve des termes très similaires dans le contrat Google avec quelques exemples :
"Aucune partie ne pourra être tenue pour responsable d'une exécution inappropriée du Contrat dans la mesure où elle est causée par une situation (par exemple, catastrophe naturelle, acte de guerre ou de terrorisme, émeute, conditions de travail, action gouvernementale et dysfonctionnements liés à Internet) échappant au contrôle raisonnable de la partie."
Azure et BPOS disposent également de ce type de clause dans le texte de leur SLA
"Quelle que soit la valeur réelle de vos données, le fournisseur n'est engagé que sur la somme que vous lui avez versée"
Dédommagement
Supposons que le fournisseur de Cloud n'ait pas tenu ses engagements et que sa responsabilité soit clairement engagée, quel dédommagement pouvez-vous attendre ? Sur ce point, les fournisseurs de Cloud proposent tous la même chose : un avoir sur l'utilisation de leur service, plafonné sur le montant de ce que vous avez déjà acheté. Autrement dit, quelle que soit la valeur réelle de vos données, le fournisseur n'est engagé que sur la somme que vous lui avez versée. Et si vous n'êtes pas content de son service, il vous propose... de continuer.
Chez Amazon cet avoir est appelé "Crédit de Service" et est de 10% de la facture
Pour Azure, il s'agit d' "avoir service" dont le montant est compris entre 10 et 25% de la facture selon la dégradation du niveau de service : 10% si le taux de service est inférieur à 99.95%, 25% si c'est moins de 99%.
Pour Google Apps Engine, l'avoir s'appelle "Crédit de service". Sa valeur est comprise entre 10% et 100% du montant payé mensuellement. Si l'indisponibilité est supérieure à 10% pendant un mois, selon les conditions définies plus haut, le service sera donc gratuit pendant un mois.
Pour Google Apps, Google précise explicitement dans son contrat le niveau de dédommagement que l'on peut attendre. L'avoir s'appelle ici aussi "Crédit de Service" et correspond à un nombre de jours offerts (de 3 à 15) : la moitié du coût mensuel peut donc être déduite, au maximum, si la disponibilité mensuelle est inférieure à 95%.
Pour BPOS, comme pour Azure, on parle également d'"Avoir service", l'engagement est néanmoins plus fort car il peut aller jusqu'à 100% de la somme versée.
En synthèse, on se rend donc compte que les fournisseurs de cloud s'engagent sur une disponibilité de l'ordre de 99,9%. En outre, leur responsabilité n'est engagée que sur des erreurs directement dans leur périmètre et au maximum pour le montant de la facture.
Lionel Laské est Directeur Innovation chez C2S, la SSII du groupe Bouygues. Il a initialement publié cet article, de manière plus exhaustive, sur son blog : http://www.7avoir.net/.