Devoxx 2009 – Amazon Web Services

Chris Richardson de SpringSource a présenté l’offre de Cloud Computing d’Amazon appelée « Amazon Web Service » pendant 3 heures. Cette présentation fut très intéressante, et nous laisse vraiment avec pleins d’idées en tête, une grosse envie de sortir la carte bleu et de débuter dès ce soir quelques tests avec Amazon. Qui est Chris tout d’abord ? C’est un Java Champion comme Antonio Goncalvès. Il a fondé la société CloudFoundry qui a été racheté par SpringSource… qui a été racheté par VMWare. Avec un talent certain pour présenter son sujet, il a animé sa présentation en expliquant aussi les limites de la solution d’Amazon Web Service, ce qui est appréciable. Je vous parlerai de CloudFoundry.com à la fin, car pour l’instant il commence la présentation et je ne veux pas vous faire louper un instant. Les lumières s’éteignent, les premiers slides de Devoxx 2009 commencent à défiler…

Introduction à la mode Touilleur Express
Commençons par quelques faits : regardons l’infrastructure IT du point de vue de l’Entreprise et de la Startup. Dans le monde de l’Entreprise, l’achat de serveurs pour héberger une application est un processus long. De même, l’installation de Weblogic, puis la configuration d’une base sur Oracle prend parfois plus de temps qu’envoyer un pigeon voyageur à un Corse. A croire que les logiciels qui nous font gagner du temps, demandent en retour un temps d’invocation énorme pour être installé par votre équipe IT.

Alors de votre côté votre application Java est prête. Ce nouveau moteur de réservation des skis et des surfs pour la saison de février vous a demandé quelques semaines d’efforts. Par contre un souci : vous n’avez aucune idée de la puissance machine nécessaire, que ce soit le CPU ou le nombre de machine. C’est vrai qu’en juillet par contre, votre site de vente en ligne ne risque pas de servir à grand chose. A quoi bon alors commander 4 serveurs Solaris et 1 Oracle RAC pour un usage encore inconnu ?

Enfin vous souhaitez tester votre application en charge. Une question : comment comptez-vous faire ? Est-ce que vous avez le luxe d’avoir une deuxième base clusterisée avec Oracle RAC pour les tests ? Certainement que non. Est-ce que de toutes les façons vous avez ne serait-ce qu’un serveur pour faire vos tests ? Non. Vous allez attendre le 1er février, quitte à faire un sacrifice rituel pour vous assurer les bons hospices d’un dieu magique… mais entre nous, vous ne savez même pas si votre application de vente de skis ne va pas se planter dans la poudreuse le 1er février au matin.

A travers ces 3 paragraphes, nous avons déjà 3 motivations qui nous poussent à regarder le Cloud Computing en général, et le principe de l’infrastructure comme un service en particulier (Iaas).

Réactivité
Tout d’abord le premier argument de la solution d’Amazon: la réactivité. Vous souhaitez 4 serveurs Tomcat+MySQL pour tester le mode cluster ? C’est possible en 10 minutes avec une Carte Bleu et un compte Amazon. Dans sa démonstration, Chris utilise le plugin « Elastic Fox » pour Firefox pour démarrer une instance sur la plateforme d’Amazon.

Même pas peur du 1er février
Faire héberger son application sur une plateforme comme Amazon EC2 c’est certainement s’assurer des nuits calmes. Pour peu que votre site fonctionne à mort le 1er février, vous serez en mesure d’ajouter des machines et de migrer votre application vers une machine plus puissante si nécessaire. Gardez le mot « migration » dans un espace mémoire, je vous en reparle tout à l’heure.

Faire des tests
Un luxe mais un des points forts de la plateforme EC2 d’Amazon, c’est la possibilité de s’installer une ou plusieurs machines, le temps d’effectuer des tests. Pas plus tard qu’il y a quelques mois chez un client, cela me rappelle que j’avais demandé des images Linux sous VMWare pour travailler, chose que j’ai obtenu assez rapidement (10 jours) mais qui m’a demandé ensuite un certain temps pour l’installation et la configuration. L’intérêt de la solution d’Amazon EC2 c’est aussi de vous proposer un kit « pied sous la table ». Par exemple une soudaine envie d’un Tomcat 6 sur Ubuntu pour tester votre application à 1h du matin ? Oui c’est possible.

Après les 35H, faut-il passer aux 0h dans l’IT ?
L’Entreprise ensuite lorsque son coeur de métier n’est pas l’informatique, doit-elle encore s’offrir le luxe d’avoir des machines dédiées ? Des personnes pour l’administrer ? La question mérite d’être posée. Selon Chris, les serveurs informatiques et les applications sont assez matures pour être maintenant externalisés et gérés comme un moyen de production externe au monde de l’entreprise.

Il cite une étude où le premier critère qui freine l’adoption du Cloud Computing est la sécurité à 43% des réponses, suivi à 28% en raison de problèmes pour s’intégrer avec des applications existantes (voir aussi cet article). Et là, cher lecteur, je te demande un exercice de représentation. Est-ce que tu préfères déployer ton WAR sur Amazon EC2, un gars bien sous tout rapport, ou est-ce que tu préfères le donner à un prestataire externe recommandé par ton copain de chez IBM, prestataire qui aura peut-être disparu dans 6 mois, qui sera lui-même racheté par GrosPrestataire avec tout le bonheur et la qualité de service qui suit ?
La sécurité du service, sa qualité, est-elle meilleure à votre avis chez Amazon ou dans votre département IT de 6 bonhommes ? Dur… mais vrai.

Amazon EC2, sachez-le, concernant le problème de l’intégrité des données est certifié SAS70 Type II. Ils sont aussi compatibles avec la norme HIPAA pour protéger la vie privée et le secret médical des personnes dans le monde de la Santé. Bon, je vous l’avoue : je ne connais pas ces normes. Mais à l’air sérieux de Chris, on sent que les petits gars d’Amazon pourraient héberger les plans de la nouvelle douche de l’Elysée.

La sécurité par rapport au Cloud c’est avant tout un problème émotionnel. Moi j’ai plus confiance en GMail qu’en mon Mac à la maison. On peut me voler mon Mac ou celui-ci peut tomber en panne. Je préfère que mes emails soient dans le cloud, comme c’est le cas avec GMail. Alors arrêtons de chipoter et passons à la suite.

Si tu veux faire une Startup
J’ai bien aimé cette partie, où il nous a amené à réfléchir à l’intérêt de la solution de Cloud Computing d’Amazon pour les startups. Avant tout, il explique qu’aux USA, certains fonds d’investissement ne regardent pas votre dossier si votre projet d’application Web est hébergé sur une plateforme classique.

A votre avis pourquoi ?

Et bien imaginez que votre service Web marche vraiment bien : vous êtes mort.

En effet, le pire scénario pour une Startup qui réalise un service sur le Web serait… que celui-ci marche trop bien très rapidement. Imaginez la catastrophe : vous lancez votre startup, un article passe au journal de 20 heures, et boom votre serveur tombe, écroulé sous le nombre de requêtes. C’est ce qui est arrivé à l’IGN et à son GéoPortal. Et même si le site fonctionne aujourd’hui très bien, que dire de son image ? Allo ! nous sommes en 2010, et un site avec 10 000 visites par mois c’est petit (c’est le Touilleur Express). Il y a beaucoup plus d’internautes au 21e siècle, pensez-y avant de vous lancer.

Repensez aussi à une Startup: il y a 4 développeurs, et votre temps est le bien le plus précieux. Avez-vous vraiment envie de perdre votre temps à configurer un Linux avec le load-balancer d’Apache, puis le tuning de Tomcat avec MySQL là où des centaines de personnes l’ont déjà fait pour Amazon ? Et bien pas moi. Mon métier c’est développeur Java, pas ingénieur système au fait des dernières bidouilles sous Linux.

Enfin au départ, une machine c’est largement suffisant. Pour peu qu’ensuite vous souhaitez tester une nouvelle version, que faut-il faire ? Et bien louer une deuxième machine sur Amazon, et ne pas toucher à l’ancienne version. Oui, tu vas gérer les upgrades de version en louant de nouvelles machines, car cela te coûte moins cher que de faire le kéké à upgrader à minuit ton unique et pauvre serveur chez Gandi.net. Il fallait aussi y penser. Une fois la version 2 stabilisée et testée, tu pourras sagement éteindre la version 1 pour économiser quelques dollars. Mais est-ce que tu te rends compte qu’il aurait été impossible de faire de la montée de version en passant d’une machine à l’autre sans le Cloud ? C’est la mort de la plateforme de « préprod » qui n’est jamais identique à la production, faute d’argent. Vive le Cloud ! Yes you can !

Faisons une pause, la foule est en délire, et reprenons un peu de notre sérieux (légendaire)

IaaS ?
C’est quoi IaaS ?
La définition de l’Infrastructure as a Service: c’est une pile de serveurs hautement disponible gérée par un tiers, sur lequel vous déposez votre application. Amazon EC2 est une infrastructure d’hébergement qui vous permet de louer des machines. Le nombre de machine ainsi que leur puissance peuvent être décidés à tout moment. La demande de machine s’effectue via une librairie de programmation (une API). A l’aide de simples messages, il est possible de créer et lancer une instance Amazon en quelques minutes. Les mots clés : flexibilité et location, puissance adaptable.

Le monde de l’Entreprise est handicapé lorsqu’il doit décider du nombre et de la puissance des serveurs. N’importe quel architecte vous le dira : c’est du pifomètre. Combien de machines sont trop ou pas assez puissantes dans votre entreprise ? Il y a un gâchis de ressources et d’argent. Un autre effet positif du Cloud Computing : il vous permet de louer 5 serveurs par exemple le week-end, puis d’en rendre 4 pour n’en garder qu’un seul pour la semaine. L’exemple cité par Chris est un brasseur de bière américain qui a utilisé ce principe durant la saison du Super Bowl. Chaque week-end, des publicités sur les TV américaines faisaient venir beaucoup de visiteurs, mais la semaine, faute de matches, il n’était pas nécessaire de garder autant de serveurs. Les coûts sont réduits et les risques sont limités. En fin de présentation, Chris a parlé de CloudFoundry qui vous aide justement à ajuster ces paramètres, sans devoir passer votre certificat Amazon pour s’y retrouver dans l’API.

Le premier prix de la plus petite machine d’Amazon est de $0,085/heure. Pour ce prix, vous avez un serveur monoproc 32 bits avec 1.7 Go de RAM, 160 Go d’espace disque, et un processeur d’1Ghz environ. C’est déjà trop pour des petits serveurs, il manque un bundle plus petit et plus économique. Cela représente environ 61 $ par mois, ce qui peut sembler beaucoup par rapport à une solution dédiée… mais attendez de voir les avantages.

L’offre d’Amazon c’est donc Amazon Elastic Cloud Compute (EC2), une plate-forme de virtualisation des serveurs sur laquelle on dépose des images systèmes. Il est aussi possible de prendre des packs préconfigurés par Amazon et aussi par la communauté avec un serveur linux + un tomcat + java + mysql par exemple. C’est aussi une offre de stockage avec Amazon S3, un moteur d’échanges de message à la JMS avec SQS, une base de données non relationnelle dans le Cloud avec SimpleDB, et un hébergement localisé pour les médias avec CloudFront.
Chris a présenté pendant environ 1 heure la partie sur Amazon EC2, puis ensuite nous a montré comment développer une application d’hébergement de photos avec l’ensemble des services d’Amazon.
Amazon EC2 est un service dans le cloud qui permet de démarrer une activité sur Internet, mais qui peut aussi être utilisé dans le cadre de l’entreprise.

Amazon EC2 bien expliqué
Amazon Elastic Cloud Computing (EC2) est une solution d’hébèrgement sur Internet qui fonctionne sur la base d’images systèmes virtuelles, une Amazon Image (AMI). Une AMI est une image d’une machine virtuelle, stockée sur Amazon S3 dont nous parlerons plus loin. Après avoir sélectionné le type d’image, Chris démarre ce que l’on appelle une instance. L’instance se voit allouée un certain nombre de ressources : cpu, mémoire et espace disque virtuel. Le contenu des disques est perdu en cas de crashes ou de redémarrage de l’instance. En fait une instance ne peut vivre qu’une fois, comme une Thread Java. Par contre, si vous faîtes rebooter le système d’exploitation qui tourne dans cette image, les disques ne sont pas perdus. Il existe plusieurs types d’instances, et il est possible de sélectionner la zone géographique où l’instance sera lancée.

Les outils
Pour commencer à utiliser Amazon EC2 il faut une Carte Bleu, un compte Amazon et c’est tout. Une API orientée service permet de créer une instance, de la contrôler, de l’arrêter. En fait, cette API est maintenant masquée par des outils comme Elastic Fox, ou des plugins dans Eclipse et IDEA IntelliJ. Vous n’avez pas besoin d’apprendre l’API. Par contre, il faut quelques connaissances sous Unix, sur SSH et sur le principe des clés publiques et privées. Rien de bien compliqué, mais c’est assez bas niveau.

La machine la plus puissante que vous pouvez louer est un monstre 64 bits avec 128Go de mémoire. Là on parle de 560$ par mois. Et le top du top, c’est que si vous voulez 10 machines de cette puissance, c’est possible ! En fait la limite du Cloud Computing c’est votre Carte Bleu, plutôt que le matériel lui-même. Tout le modèle de facturation est basé sur l’utilisation, avec des prix à l’heure. L’idée est proche du domaine des téléphones portables. Vous téléphonez peu, vous prenez 2h. Vous êtes un gros consommateur, vous prenez 6H. Ici on parle plutôt de puissance machine, de la taille de la mémoire et de l’espace disque.

Un slide dans la présentation montre un exemple avec 3 machines : 1 serveur web sur Apache, 2 serveurs sur Tomcat en cluster. Le tout pour 180$ par mois environ. Et comme Chris l’explique : si vous avez envie de changer de machine, ne serait-ce que pour tester pendant une semaine, c’est aussi faisable.

Le Web tiers
Dans cette partie, Chris nous a montré des exemples de déploiement avec un serveur Apache. Difficile ici de vous retranscrire les quelques 8 slides. En bref nous avons parlé d’adresse IP static, d’adresses privées pour le réseau Amazon et d’adresses publiques. Il a aussi montré comment créer une petite infrastructure avec un serveur Web rapidement.

Concernant le Load-Balancing, il existe une solution proposée par Amazon. Il suffit de configurer l’adresse de l’Elastic Load-Balancer acheté avec votre compte en tant que CNAME sur la configuration DNS de votre domaine, afin de load-balancer les visiteurs sur plusieurs machines. Attention cependant, le SSL et les Sticky Sessions ne fonctionnent pas avec ce LoadBalancer. Mais c’est simple à installer.

Les serveurs d’applications
Dans cette partie, nous avons parlé Tomcat essentiellement. Depuis que la société de Chris s’est fait racheter d’abord par SpringSource puis ensuite VMWare, on sent la touche SpringSource avec quelques citations de tc Server. Mais sans plus.

Il n’y a pas de Multicast dans l’offre EC2. Si votre serveur d’application utilise le multicast pour détecter ses voisins, comme avec JGroups, il faut alors soit configurer JGroups en mode TCP, soit utiliser Terracotta pour faire tourner Tomcat en le configurant correctement par exemple.

Concernant la montée en charge, Amazon propose depuis mai 2009 un service appelé « Amazon Auto Scaling ». Comme son nom l’indique, c’est un moteur capable de démarrer automatiquement de nouvelles instances lorsque la charge CPU ou mémoire devient trop importante sur un de vos serveurs. Vous pouvez limiter le nombre d’instances bien entendu. Ce système cependant présente quelques limites : tout d’abord Amazon regarde des metrics bas niveaux comme le CPU ou la mémoire, mais n’est pas capable d’utiliser JMX pour diagnostiquer l’application. Ensuite, même si le démarrage de nouvelles instances est automatique, il faut encore penser que la configuration de votre application (adresse IP de la base par exemple) n’est pas automatique. Cela demande un travail de configuration pour que tout fonctionne.

La base de données
Comment gérer une base de données lorsque l’on travaille avec Amazon EC2 ? Première mauvaise nouvelle : l’espace disque de la machine qui vous est alloué ne doit pas être considéré comme un espace qui sera toujours là. Si votre machine plante puis qu’elle redémarre, le système de fichier sera complètement initialisé. Cela pose un gros problème si vous souhaitez sauver votre base en local sur la machine : c’est impossible.

Pour répondre à ce problème, Amazon propose EBS (Elastic Block Storage). Sous ce nom digne d’une crème épilatoire, se cache en fait comme un disque réseau, qui sera monté sur l’image Amazon EC2 et qui sera sauvegardé. Similaire à un NAS en fait. EBS est automatiquement divisé sur plusieurs disques physiques. D »après Chris, c’est 10 fois plus solide qu’un disque physique classique. EBS coûte $0.10 par mois, pour 1G. Il est possible de prendre des snapshots pour sauver ce disque et de les placer sur S3. Par contre côté performance, d’après lui c’est largement en dessous d’une solution comme du RAID 10 avec 2Gb de cache, bref un NAS à 300 000 EUR. Mais c’est suffisant pour la majorité des cas.

Concernant le monde des bases relationnels, qui devrait disparaître bientôt, Amazon propose aussi « Amazon Relational Database Service » ou RDS. Il s’agit d’un serveur MySQL 5.1 configuré par Amazon pour vous. Ce service est administré par Amazon. Lors de la création, l’interface Web vous demande même de donner 4h dans la semaine pendant lesquelles Amazon peut éteindre ce service pour passer des patches de sécurité. L’interface demande aussi de donner un créneau de 2h dans la journée pour qu’Amazon effectue des sauvegardes de la base. Bref c’est un MySQL configuré, backupé, géré par Amazon, qui vous évite de vous ennuyer avec la configuration et la sauvegarde de votre base. Moi je dis : pourquoi pas ?

La sécurité
Bon j’espère que vous n’avez plus peur d’utiliser Amazon EC2 maintenant. Si c’est encore le cas, visualisez la tête de votre Chef de Prod. Chez mon ancien client, c’est marrant, mais le responsable de la production était tellement aimable qu’un hygiaphone de la Poste fait rêver à côté. Mon fils adore la grosse méchante dans Monster, vous voyez le poulpe ? Et bien c’est le chef de la prod. Bon j’en étais où moi ?

Concernant la sécurité, il est possible de régler finement les droits d’accès à chacune de vos machines. SSH, HTTP ou FTP, n’importe quel port se règle afin de sécuriser votre réseau.

Le déploiement dans le monde
Il existe des projets pour lesquels il n’est pas possible légalement d’héberger aux USA des données. Pour cela, il existe depuis maintenant 2 ans des Datacenters Amazon en Europe. L’Asie est prévue pour 2010. Cela permet de rapprocher géographiquement vos serveurs de vos utilisateurs, et de rentrer aussi dans le cadre de la législation sur l’export du code source d’un logiciel.

Si vous n’avez pas ce genre de soucis, Chris recommande de répartir sur chacune des 2 zones en Europe son Infrastructure. Cela rapproche la disponibilité de votre service des 99,95%, ce qui est tout à fait supérieur à beaucoup de services.

Critiques sur IaaS
Un souci qui saute aux yeux avec une infrastructure de type IaaS, c’est que cela demande encore un peu de temps pour tout ce qui est installation et configuration. Si cela vous freine, Chris parle alors de PaaS : Platform as a Service. Premier exemple dont je vous parlerai cette semaine : Google AppEngine. L’avantage ? Pour vous, plus d’installation d’images, de réglages de Linux ou autre : vous utilisez un méga serveur virtuel et vous ne payez que l’utilisation. Cependant Google AppEngine a quelques limitations : pas de base de données relationnelles, les transactions sont très limitées et surtout, l’API Java n’est pas complètement disponible.

Chris a créé CloudFoundry il y a 2 ans, pour justement aider le développeur Java qui souhaite utiliser Amazon EC2 et ses différents services, sans avoir le temps ou l’envie de se plonger dans l’API d’Amazon. Je trouve son offre pleine de sens. Elle répond à un vrai besoin. De plus, Chris nous a montré des installations types proposées par son outil. Cela permet réellement de créer une infrastructure avec des serveurs configurés en cluster en quelques minutes. Pensez-y si vous avez de l’Apache, du Tomcat, du MySQL mais aussi d’autres serveurs.

Ainsi se termine les 2/3 de la présentation.

Nous allons maintenant passer à un résumé des différents produits de l’offre d’Amazon dans la deuxième partie.

Articles similaires:

Devoxx 2009 – Amazon Web Services partie 2 USI 2009 : Google pour l'Entreprise puis Amazon Architecture Devoxx : présentation Amazon et Elastic Grid Google App Engine à Devoxx 2009, journée 2