Présentation « Technologies Google pour l’entreprise »
J’ai finalement craqué pour les présentations plutôt techniques. Je commence ma journée par la présentation de Didier Girard : « Technologies Google pour l’entreprise« . Axé sur la définition de la stratégie et la présentation des outils de Google, Didier termine par une démonstration convaincante de Google Wave. D’ailleurs, l’USI a prévu une autre présentation uniquement consacrée à Google Wave demain à 16h30. Il nous a présenté l’ensemble des outils de Google destinés à l’entreprise. La présentation de Google AppEngine est appuyée par l’exemple de l’application développée par Didier, pour Android.
Il cite quelques chiffres qui donnent le tourni : d’ici quelques années, 15% des CPUs seront achetés par Google, et l’un des plus gros consommateurs d’électricité en Californie sera bientôt Google. Plus tard dans la journée lors de la présentation d’Olivier Mallassi et André Nedelcoux d’OCTO, on apprendra aussi que Google possède à ce jour 39 Datacenters, que 400 serveurs par jour tombent en panne, et qu’ils consomment actuellement 2.5% de l’électricité aux USA. Chiffres difficiles à vérifier. Mais cela explique aussi pourquoi Google veut mettre ses machines au large sur des barges flottantes afin de réaliser des économies.
J’ai apprécié de revoir les outils, mais j’ai surtout aimé la démonstration de Google Wave. Didier Girard a développé un Robot pour Wave capable d’envoyer des SMS, et d’en recevoir. En fin de présentation nous avons testé son application en envoyant des SMS et tout a bien fonctionné.
Je m’arrête là pour ce soir car je vous reparlerai de Google Wave demain.
Architecturer pour le Cloud
J’enchaîne ensuite avec une présentation en Anglais de Simone Brunozzi d’Amazon : « Architecturer pour le Cloud« . Il débute sa présentation par une « non-définition » du Cloud Computing, pour ensuite lister les bénéfices du cloud :
– abstraction
– disponible à la demande,
– scalable,
– paiement à l’utilisation
Utiliser une plate-forme de Cloud Computing, c’est marcher dans des pas de géant tout en ne payant que ce que l’on utilise finalement. La scalabilité pour Amazon comme il l’explique, c’est tout d’abord un métier, dont ils sont spécialistes. Ensuite c’est un effort d’architecture de notre côté, car il ne suffit pas d’ajouter des machines sans réfléchir son SI dans le Cloud.
Les points qu’il nous propose de regarder :
– Design for failure
– Loose coupling sets you free
– Design for dynamism
– Security is everywhere
– Don’t fear constraints
– Many storage options
– AWS ecosystem and community
Tout d’abord comme le dit Werner Vogels le CTO d’Amazon : « Everything fails, all the time ». Comme je dis à mes clients : « On est sûr d’une chose et on ne connaît pas l’autre. On sait que cela va planter mais on ne sait pas quand ». Prendre en compte donc que l’application va planter. Amazon propose des solutions comme Elastic IP. Il prend l’exemple de la muraille de Chine, construite non pas pour empêcher les envahisseurs d’entre en Chine, mais pour les ralentir lorsqu’ils repartent, afin de les écraser lorsqu’ils étaient chargés de butin. La muraille a donc été dessiné dès le départ pour… ne pas marcher et laisser entrer les envahisseurs.
Le deuxième point « Loosely coupled system » nous dit qu’il faut massivement découper notre application en boîte noir dans le Cloud afin d’en tirer parti. Pour cela on peut introduire de l’asynchrone avec Amazon Messaging Service, utiliser des Web Services comme Amazon, bref prévoir de faire des petits châteaux plutôt qu’un gros château.
Le troisième point « Design for Dynamism » dans le Cloud est de dire que notre architecture d’application ne doit pas se reposer sur le serveur physique sur lequel elle tourne, elle doit être dynamique, elle doit être démarrable facilement avec un script de bootstrap sur Amazon, afin de pouvoir monter en charge.
Concernant ensuite « Security is everywhere », tout d’abord Simone explique qu’Amazon nous offre la sécurité physique en répliquant nos donnés, en montant des datacenters certifiés (sismique/cambriolage/électricité…). La sécurité applicative est bien entendu à prendre en compte mais il n’y a pas de risques avec nos voisins sur Amazon.
Le point suivant « Don’t fear constraints » nous fait comprendre qu’il faut s’adapter à la boîte à outil d’Amazon et ne pas avoir peur des contraintes. On vous demande plus de mémoire ? essayez le cache distributé (memcached). Vous voulez de meilleurs perfomances avec votre base ? Regardez SimpleDB. Amazon a sa propre infrastructure sur le Cloud, au nom de quoi votre application ne pourrait-elle pas suivre les mêmes bonnes pratiques ?
Concernant ensuite « Many Storage Options » ce slide présente simplement les différentes technologies d’amazon :
– Amazon S3 pour le stockage des données statiques
– Cloudfront pour la distribution
– SimpleDB pour une base simple et indexée
– Amazon EC2 avec l’accès à un disque local physique pour stocker
– Amazon EBS pour le stockage permanent
Dernier point enfin « AWS Community and Ecosystem » avec l’exemple de la migration d’une application vers la plate-forme de Cloud Computing d’Amazon.
Sa présentation est en ligne si vous souhaitez la regarder.
Présentation intéressante, qui permet de prendre conscience de l’offre d’Amazon sur le sujet.
0 no like
salut nicolas,
je regrette de ne pas t’avoir croisé pendant ces deux jours…comme quoi!!
J’espère que tu n’as pas retenu que ces quelques chiffres de la session tout de même ? 😉
en fait, les infos qu’on a sortent toutes du Web ;). ci-après qq liens
– http://royal.pingdom.com/2008/04/11/map-of-all-google-data-center-locations/
– http://www.gartner.com/resources/149800/149834/look_beyond_googles_plan_to__149834.pdf
J’essaierai de faire un article blog reprenant cette session et je rajouterai les sources
@bientot