Le nuage public d’Amazon reste trop nébuleux pour les entreprises

Le bilan est mitigé. Certes, Drue Reeves, analyste au cabinet Burton Group, concède à Amazon son statut de pionnier du Cloud Computing avec EC2. Mais ce n’est pas suffisant. Selon Drue Reeves, pour convaincre les entreprises, Amazon devra encore fournir de nombreux efforts. Et sur le terrain de la sécurité et de la disponibilité, en particulier.

Le Cloud façon Amazon, une boîte noire

Dans une étude, Drue Reeves souligne qu’Amazon « fait du bon boulot en matière de sécurité physique et réseau. » Pour autant, il manque, selon l’analyste, « la vérification, par un tiers accrédité, des affirmations d’Amazon » ou encore « de certifications », tant sur l’organisation interne que sur les procédures d’audit. A tout cela, il convient d’ajouter également une transparence insuffisante : Amazon ne communique pas sur l’architecture et les procédures de sécurité relatives à EC2. Dans son étude, Drue Reeves souligne que « dans le cadre de sa politique, Amazon ne discute pas de l’infrastructure physique d’EC2. Du coup, les clients ne peuvent pas déterminer le niveau de redondance et de protection des composants physiques. » Et la liste est longue : interfaces réseau, contrôleurs de stockage, alimentations des serveurs ; redondance sur les baies de stockage ; redondance et gestion du routage sur le réseau ; infrastructure énergétique ; etc. C’est bien simple, « pour le Burton Group, ceci est inacceptable pour beaucoup d’applications d’entreprises. » Quitte à en ajouter à l’inconfort, Drue Reeves relève en outre qu’Amazon ne communique pas plus sur les taux de réplication des données au sein de son nuage dédié au stockage, S3. Surtout, le prestataire « ne fait pas de sauvegarde sur ses services de stockage. Amazon estime que la réplication sur S3 et la possibilité de réaliser des snapshots sur l’Elastic Block Store (EBS) fournit une redondance suffisante. »

La continuité de l’activité ? Une interrogation de plus

La gestion de la continuité d’activité serait également discutable. Dans le détail, Drue Reeves relève qu’Amazon dispose deux zones pour servir l’Europe de l’Ouest. Malheureusement, EC2 « n’intègre aucun mécanisme de mise en grappe au niveau de l’hyperviseur ou de reprise automatique pour les machines virtuelles entre zones. » Bref : la reprise doit être manuelle en cas de défaillance dans une zone de service. Ce qui n’empêche pas Amazon, dans le même temps, de proposer de l’équilibrage de charge entre zones. Et l’analyste de souligner, au passage, qu’Amazon EBS n’assure pas de réplication des données entre zones de service, y compris au sein d’une même région géographique : bref, en cas d’incident, il faut non seulement relancer l’application mais aussi penser à recopier ses données. Et espérer qu’une sauvegarde récente des lots en cours de traitement a été faite entre S3 et EBS. Pour améliorer la disponibilité, Amazon propose des API. « Mais elles sont propriétaires », regrette l’analyste.

Des fonctions d’administration insuffisantes

Comme si tout cela ne suffisait pas, Drue Reeves, tout à l’exhaustivité de son étude, regrette l’absence de certaines fonctions dans la console d’administration du nuage d’Amazon : « bien que fonctionnelle, la console ne propose pas la plupart des outils que les entreprises utilisent aujourd’hui pour administrer leurs environnements. » Et d’étayer son propos par un exemple : « le provisionnement, la supervision, le décommissionnement et le diagnostique sur les images se fait intégralement dans la console. La seule façon d’intégrer cela à une suite d’administration d’entreprise, comme HP OpenView, serait d’écrire un widget sur-mesure en utilisant les API d’EC2 et/ou d’ouvrir des brèches dans les pare-feu et de la machine virtuelle et de l’entreprise pour laisser passer les messages SNMP. » Bref, pour l’analyste, « la console d’Amazon constitue un nouveau silo d’administration intolérable qui fragmente l’entreprise et augmente ses dépenses d’exploitation. » Un jugement que tempère Drue Reeves en soulignant qu’Amazon a là l’opportunité de « changer les règles du jeu en effaçant les lignes entre nuages internes et externes. » Une opportunité dont il reste à savoir si Amazon saura la saisir.

La montée en puissance ? Une capacité limitée

Enfin, l’analyste du Burton Group s’attache à détricoter une image construite sur la promesse d’une montée en puissance aisée. Tout d’abord, « pour éviter une consommation excessive de ressources, Amazon limite à 20 le nombre maximum de machines virtuelles par compte client. » De la même manière, « Amazon limite à 20 le nombre de volumes EBS. » Ce n’est pas tout ! Amazon limite à 5 le nombre d’adresses IPv4 publiquement exposées pour EBS. En outre, « Amazon impose une limite dure et rapide à atteindre de 1 To par volume EBS. » Ajoutons à cela que « la taille maximum d’un objet dans S3 est de 5 Go. » Mais aussi qu’Amazon est susceptible de brider les traitements, pour éviter les surconsommations de ressources processeur. Un bridage dont « Amazon n’informe pas ses utilisateurs lorsqu’il survient », relève Drue Reeves.

Une rentabilité à vérifier

Bref, pour l’analyste, le passage au Cloud public d’Amazon n’a rien d’une évidence : « le retour sur investissement » peut manquer « de clarté. ». De son point de vue, avant de sauter le pas, il convient non seulement de « construire un modèle de coût interne » mais aussi de « conduire une analyse d’impact métier. » Et de déterminer si le jeu en vaut vraiment la chandelle.