c'est le titre d'une analyste du Gartner. Et il faut bien avouer qu'elle a raison.

Le SLA est le niveau de service que le fournisseur cloud fournit à ses clients. On dispose d'un % de disponibilité mais le SLA est conditionné à des formules de calculs, des exclusions (car toute panne, tout problème n'est pas pris en compte par la formule). est-ce un SLA mensuel ou annuel ? etc.

"Dans les services d'infrastructure, dans le but d'un SLA (ou, d'ailleurs, la clause de responsabilité dans le contrat) n'est pas «rendre l'argent des clients pour compenser les pertes du client qui ont résulté de ce temps d'arrêt". Au contraire, les garanties monétaires impliqués sont l'expression de partage des risques." précise même Lydia Leong (Gartner)

Et surtout Lydia prévient : "Malheureusement, en cloud ​​IaaS, le SLA peut facilement être structuré de manière à le rendre peu probable que vous verrez jamais un sou de l'argent - ce qui réduit considérablement les risques financiers du fournisseur en cas de panne."

L'analyse prend pour exemple : Amazon Web Services et HP Cloud Public. Sur AWS, Lydia est sans pitié : "le SLA d'AWS a également le statut du "pire des SLA de n'importe quel fournisseur IaaS Cloud majeur» ! -> pour certaines pannes, le SLA n'est pas applicable (les fameuses exclusions). Mais HP Cloud public n'est pas mieux noter : le SLA HP est encore pire !

Il faut dire que dans les deux cas, les termes des contrats SLA sont complexes et nombreux. Ce qui est un manque de clarté évident envers le client qui ne lira pas le contrat SLA ou n'y comprendra rien. J'ai d'ailleurs à plusieurs reprises sensibiliser à ce problème : lire et relire les contrats SLA.

L'une des difficultés est quand on utilise les zones géographiques impliquant différents datacenter. AWS mise sur des mesures, des calculs annuels et non mensuels. Le constat est très simple : "99,95% de disponibilité mensuel permet seulement environ 21 minutes de temps d'arrêt; 99,95% de disponibilité annuelle permet près de quatre heures et demie de temps d'arrêt, cumulée au cours de l'année." le calcul est identique car 21 minutes d'arrêt par mois correspond grosso modo à 4 heures annuelles. Mais le fait d'être annuel, donne une souplesse d'interprétation ainsi si une panne dure 45 minutes au mois X mais que le SLA annuel est respecté, le client n'aura rien !

Lydia continue en précisant : "Cependant, AWS et HP définissent tous deux leur SLA non pas en termes de disponibilité, par exemple, ou même la disponibilité AZ (disponibilité par zone, une zone étant un datacenter), mais en termes de disponibilité région (une région rassemble souvent plusieurs AZ, donc plusieurs datacenter). Cela signifie que si un datacenter d'une région donnée connait des problèmes, la disponibilité de la région baisse mais peut encore respecter le SLA contractuelle ! Tout est dans le subtilité. Dans le cas de Amazon : "Amazon exige que vous fournissiez les ID d'instance et les journaux prouvant la panne." dixit Gartner, ce n'est pas le cas pour HP Cloud public. Ce qui est une différence notable !

Et vous qu'en pensez-vous ?

post original : http://blogs.gartner.com/lydia_leong/2012/12/05/cloud-iaas-slas-can-be-meaningless/