22 mai 2011

PowerPoint dans le Cloud

Depuis plusieurs années, j’emploie régulièrement des solutions SaaS (Software as a Service) comme Google Docs ou Microsoft Office Live, pour backuper en ligne mes présentations PowerPoint. Je n’ai jamais apprécié utiliser ces solutions SaaS, pour créer en ligne une présentation. Google a la fâcheuse tendance à déformer certains graphiques "SmartArt" et Office Live de Microsoft n’est pas compatible avec mon browser favori - Chrome. Pour moi, ces solutions ne sont pas assez mûres et performantes, pour abandonner ma suite de bureautique favorite.
Google Docs et/ou Microsoft Office Live sont adaptés pour faire des corrections de dernière minute. Ils sont aussi utiles pour faire des présentations sans installation préalable d’un logiciel. Les autres outils de ces suites de bureautique sont aussi idéaux pour le travail collaboratif.


Le 24 mai prochain dans le cadre de la semaine nationale de l’ingénieur du CNAM, je vais faire un exposé sur le Cloud computing.
Flyer : CONFÉRENCE LE MARDI 24 MAI À 19H, LE CLOUD COMPUTING, Olivier Leclère, ingénieur CNAM
Pour préparer ma présentation, j’ai décidé d’employer Prezi. Cette solution, dans sa version gratuite, permet uniquement de créer ses présentations en ligne (elles peuvent être ensuite downloadées).
Il faut moins d’une heure pour prendre en main Prezi. Cette solution permet ensuite de réaliser des présentations originales et totalement différentes des traditionnelles diapositives PowerPoint. Malgré quelques limitations, comme l’impossibilité de choisir le format des puces, j’ai apprécié travailler avec ce produit. Je pense donc réutiliser ce dernier pour mes prochaines interventions dans et sur le Cloud.

UPDATE :
Cette présentation a entièrement été réalisée dans une solution de type SaaS - Prezi.

15 mai 2011

Chromebook et la sécurité des données dans le Cloud

Le journal Le Matin a publié samedi 14 mai dans son édition papier un article "Le Chromebook arrive". Pour cet article, j’ai été interviewé pour parler des problèmes de sécurité lié au Cloud computing.

Dématérialiser son PC et le mettre dans le Cloud comporte des risques, mais cela peut-être aussi une solution pour accéder un environnement familier en tout temps et tous lieux. Je développe mon point de vue sur le blog de mon entreprise : http://campus.hesge.ch/lti/index.php/le-chromebook-arrive/lti/.

10 mai 2011

Citrix "Virtual Computing"

Logo Citrix
Mardi 10 mai 2011, j’ai assisté à la journée Citrix "Virtual Computing" à Lausanne (Suisse). Ce fut une journée très "marketing", comme toujours lors de tels événements, mais les intervenants de Citrix et leurs invités comme Cisco ont présenté des concepts et des solutions intéressantes.


L’élément qui a principalement retenu mon attention lors de la présentation de Citrix a été cette phrase : "Cloud enabled data centers and enterprise enabled Clouds". Je pense effectivement et je le répète régulièrement lors de mes propres présentations, qu’il faut dès à présent transformer son data center. En mettant en œuvre les concepts du Cloud computing que j’ai décrit dans les autres articles de ce blog, l’entreprise bénéficiera d’un data center plus robuste. Grâce à l’élasticité, le data center de l’entreprise pourra plus facilement être adapté aux besoins ponctuels et grandissants du responsable des systèmes d’information de l’entreprise. Des économies pourront aussi être faites en optimisant l’utilisation des ressources hardware. Finalement, en industrialisant et en automatisant les processus de gestion du data center, un niveau de service garanti (SLA – Service Level Agreenment) pourra être proposé aux utilisateurs finaux. Comme je l’écris dans mon article "Cloud computing : risques et périls!", il existe, pour chaque entreprise, une solution de type Cloud qui permet à l’entreprise de répondre à ses besoins métier, tout en garantissant la sécurité de son système d’information. En réalisant un premier projet l’entreprise se sera familiarisée avec le concept de Cloud computing et ainsi continuera de migrer son système d’information dans le Cloud.


Les autres éléments qui ont retenu mon attention durant cette journée de présentations, sont d’ordre technique. Citrix a présenté de nombreux produits, deux m’intéressent particulièrement.
Le premier est "OpenCloud Bridge". Cette solution a été conçue pour faciliter la connexion entre le data center de l’entreprise et une solution de Cloud externe. Vu le manque de standard d’interopérabilité entre les acteurs du Cloud, pour moi ce type de solution a un avenir prometteur.

Le second produit qui m’a  interessé  est "NetScaler". Cette solution de type "application trafic manager" permet de répartir la charge entre plusieurs instances d’une application de façon transparente. Ce type de solution est généralement vendue comme un service indépendant et supplémentaire par les prestataires de service de type IaaS (Infrastructure as a Service). Avec ce produit, Citrix vise à nouveau l’interopérabilité.

En conclusion, je peux dire que contrairement à d’autres acteurs du marché, Citrix semble préparer son entrée sur le marché du Cloud de façon discrète,  en développant des outils pour faciliter l’intégration de ses produits dans le Cloud avec d les autres solutions du marché.

02 mai 2011

Chaos chez Amazon EC2 – plus jamais ça!

Le 21 avril 2011 le service EC2 (Elastic Compute Cloud) d’Amazon a subi une panne qui a duré près de 3 jours. Certains clients ont même perdu une partie de leurs données [1]. Selon Amazon [2] seul 0.07% du volume des données hébergées dans la zone impactée par la panne ont été définitivement perdues. Ce chiffre ne signifie que peu de choses, car nous ne saurons jamais combien de clients ont réellement perdu des données. Nous pouvons aussi nous poser la question, est-ce que ces clients avaient respecté les règles qu’Amazon impose pour que son SLA (service level agreement) soit applicable?

J’ai écrit un article sur la solution d’Amazon en janvier 2010. Dans cet article je parlais de leur SLA. Il est très contraignant et ne dédommage que difficilement les clients en cas de panne.
"Le client peut demander des dédommagements pour autant que l’ensemble de ses instances aient été indisponibles pour plus de 5 minutes et qu’il n’ait pas pu créer de nouvelles instances. Amazon recommande de travailler au moins sur deux zones."
Si les clients qui ont perdu des données et tous les autres impactés par la panne d’Amazon le 21 avril ont respecté la recommandation du SLA: "travailler au moins sur deux zones", nous pouvons nous poser une seconde question: quel aurait été l’impact d’une telle panne, s’ils avaient hébergé leurs données dans leur propre data centre ou chez un hoster (hébergeur) "traditionnel"? L’impact économique et technique aurait sûrement été plus grand, mais il aurait touché moins de clients!


Pour éviter de reproduire ce problème lors d’une prochaine panne, Amazon décrit les mesures qu’ils vont prendre dans un communiqué [2]. De nombreux articles sur le web [3, 4, 5] donnent aussi des recommandations afin de réduire les risques liés à une panne du même type que celle qu’Amazon vient de connaître. Pour moi ces recommandations sont des recommandations de bon sens et doivent être appliquées à tout projet qu’il soit critique ou pas. Ces conseils sont aussi valables pour tout projet hébergé chez d’autres prestataires de service de type Cloud ou des prestataires que nous pourrions appeler "traditionnels".

Dans ces recommandations, le premier point consiste à multiplier les instances de son système d’information. Contrairement à ce qu’Amazon recommandait "travailler au moins sur deux zones", il faut travailler sur au moins 2 régions. Pour Amazon une "région" (Region) est un déploiement de son infrastructure, totalement indépendant des autres "régions". Une zone de disponibilité (Availability Zones) est un sous ensemble d’une région. Les zones de disponibilité permettent de facilement créer un système redondant, car Amazon fournit des mécanismes pour répliquer automatiquement les données entre les différentes zones d’une même région.
Travailler avec plusieurs régions permet de cloisonner les instances de son système d’information, mais nécessite la mise en place de mécanismes complexes pour la synchronisation des instances. Amazon n’offre pas de mécanismes pour synchroniser ses instances entre deux régions.

Le deuxième point consiste à effectuer des backups réguliers de son système d’information. Lors de la panne du 21 avril, la première tâche effectuée par les ingénieurs d’Amazon a été de réaliser un "snapshot" des Elastic Block Store (EBS) impactés. Un snapshot n’est rien d’autre qu’un backup. Amazon recommande de faire des snapshots réguliers des EBS afin de garantir une sauvegarde à long terme de ses données. La technique du snapshot permet aussi de multiplier rapidement les instances. Au sein de nos entreprises, ne faisons-nous pas des backups réguliers? La fréquence et la méthode des backups dépendent évidement de la nature et de l’importance des données.
Le troisième point des recommandations consiste à employer une solution de Cloud de type hybride ou multi-prestataires. Cette solution peut prendre différentes formes:

  • Garder les données vitales au sein de son entreprise. Cette solution permet de rassurer sa direction, car l’entreprise garde le contrôle total sur ses données. Par compte elle est souvent aussi couteuse qu’héberger son propre Cloud privé. L’entreprise doit assurer par elle-même l’élasticité de sa solution, mais aussi la sécurité de cette dernière.
  • Mettre en place une solution de multiplication d’instance. Nous revenons ainsi au deuxième point, sur les snapshots, que j’ai évoqué ci-dessus. La copie principale du snapshot est conservée au sein de l’entreprise et elle est instanciée autant de fois que nécessaire, en interne et/ou chez un prestataire de service Cloud. Cette solution permet une très grande élasticité, mais elle n’est pas adaptée pour des solutions applicatives où l’utilisateur doit éditer les données.
  • Utiliser plusieurs prestataires de service. Cette solution permet de réduire les risques de pannes. Par compte elle est souvent plus difficile à mettre en œuvre, car il n’existe pas de standards.

Pour conclure cet article, je peux dire qu’Amazon ne peut être tenu entièrement responsable pour la perte de données évoquée dans l’article "Panne dans le cloud: Amazon perd des données de ses clients" [1]. Il faut lire attentivement le SLA. En fonction de l’importance de ses données, il faut mettre en place une solution adaptée. Cette solution doit mettre en œuvre les solutions décrites ci-dessus. Elle devra être déployé dans des data centres entièrement indépendant. La solution devra être backupée régulièrement. Idéalement elle devra être hybride et/ou multi-prestataires.
Pour garantir le bon fonctionnement de sa solution Cloud, cette dernière devra être entièrement automatisée du backup à la multiplication d’instances.

[1] Panne dans le cloud: Amazon perd des données de ses clients, Nicolas Paratte - ICT journal, http://www.ictjournal.ch/fr-CH/News/2011/04/29/Panne-dans-le-cloud-Amazon-perd-des-donnees-de-ses-clients.aspx, publié en ligne le 29 avril 2011, consulté le 30 avril 2011
[2] Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region, Amazon web services, http://aws.amazon.com/message/65648/, publié en ligne le 29 avril 2011, consulté le 29 avril 2011
[3] How SmugMug survived the Amazonpocalypse, Don MacAskill, http://don.blogs.smugmug.com/2011/04/24/how-smugmug-survived-the-amazonpocalypse/, publié en ligne le 24 avril 2011, consulté le 28 avril 2011
[4] The Cloud is not a Silver Bullet, Joe Stump, http://stu.mp/2011/04/the-cloud-is-not-a-silver-bullet.html, publié en ligne le 25 avril 2011, consulté le 28 avril 2011
[5] Seven lessons to learn from Amazon's outage, Phil Wainewright ZDNet, http://www.zdnet.com/blog/saas/seven-lessons-to-learn-from-amazons-outage/1296, publié en ligne le 24 avril 2011, consulté le 28 avril 2011