Quel sera l’impact du Cloud Computing sur le métier de Développeur d’ici 2015 ? Qu’est-il possible de construire aujourd’hui ? Comment allons travailler dans les années qui viennent ? Quels sont les enjeux du Cloud pour celui qui code ?
Il y a 14 ans j’étais jeune développeur chez Coplanet, dans une agence Web. A l’époque nous étions dans les premiers à développer des sites Internets à Paris. Nous avons fait par exemple le premier site de la Société Générale, de SynthéLabo ou de la Camif, avec des serveurs SUN, des serveurs Webs Netscape, du code Javascript côté serveur avec LiveWire et pas mal de C.
Et un truc marrant dont je me souviens, c’est une mise en prod.
C’était en 1998. Avec Fabien notre directeur technique qui à cet époque était plus jeune que moi aujourd’hui, nous étions dans un taxi. Nous venions de partir de Boulogne Billancourt pour aller à la Défense. Entre nous deux, un serveur SUN Microsystems avec, je vous le jure, le serveur web de notre client, autrement dit la première version d’un grand site d’une grande banque… Peut-être 5 mois de travail, avec des copies sur d’autres machines restées à notre agence. La mise en prod se faisait en allant installer et brancher la machine chez l’un des rares hébergeurs, en attendant que la salle machine du client soit prête. Le développement ne pouvait s’effectuer que sur la machine de prod, vu le prix exorbitant de ces serveurs. Nous utilisions SCCS pour la gestion de version. Tout était vraiment artisanal. Et c’était il y a 14 ans.
Là nous étions en plein dans le monde de la machine… ce qui me semble dépassé aujourd’hui.
Commençons par regarder ce que nous appelons une application Web. Il s’agit du site de réservation de vos billets de train, du site de ventes de chaussures ou du dernier réseau social à la mode. Pour vous, c’est une adresse dans votre navigateur ou une application sur votre mobile. Pour nous, c’est un ou plusieurs serveurs pour faire fonctionner tout cela. L’utilisateur n’a pas à s’intéresser à l’idée de serveurs. Seul le service que vous lui rendez a de l’importance. Il en est de même dans l’entreprise.
Aujourd’hui une start-up n’est pas valorisée sur le nombre de serveurs qu’elle possède. La culture de l’acquis (je possède un serveur) est complètement obsolète par rapport à la culture de l’usage (j’offre un service de courrier électronique d’entreprises). Dans d’autres industries déjà nous sommes passés d’une culture de l’acquis à une culture de l’usage. Mercedes Truck ne vend pas de véhicules poids lourds mais des kilomètres. SFR ou Orange vous vendent des minutes de communication. Votre photocopieur est facturé en nombre de copies par an. Voyez comment d’autres industries sont déjà dans une culture de l’usage par rapport à nous, informaticien avec nos superbes serveurs en plastique.
Pourtant nous y arrivons depuis quelques temps, et ce, grâce au Cloud Computing. Mon coup de coeur c’est le PaaS proposé par CloudBees ou Heroku. C’est LE truc qu’il faut découvrir en 2012.
Heroku ne vend pas un serveur mais une capacité de montée en charge. Vous ne payez que l’usage. La vision « immobilisation d’un bien » est remplacée par une notion d’usage, où chacun ne paye que sa consommation. Demain, une publicité « à la IBM » avec un serveur en rack nous semblera même complètement obsolète. Franchement, quel intérêt y-a-t-il à payer 10 000 EUR une 4ème de couverture dans 01 Info pour vous montrer des boites en plastique qui ressemblent à des PS3 ? Aujourd’hui lorsque vous utilisez de l’électricité, est-ce que vous pensez à la centrale nucléaire qui est derrière ?
Il est temps de penser « puissance informatique » plutôt que « nombres de serveurs ». L’informatique est une commodité comme le pétrole, le gaz ou l’électricité. Aujourd’hui il est possible de démarrer un projet Web et de le mettre en production en quelques heures à peine. De l’écriture du code à la première visite sur le site, il est possible de démarrer facilement et rapidement. Heroku est arrivé en septembre 2011 dans l’univers Java. Fort d’une communauté et d’une expérience réussie dans le monde Ruby on Rails, la plateforme s’est ouverte aux quelques 6 millions de développeurs Java dans le monde. Et ce que l’on observe est intéressant : une partie de la communauté Java bascule vers ces nouvelles approches, grâce à l’appel de ce type d’infrastructure. La facilité et la simplicité de mise en production va à l’encontre de l’ancienne complexité, hérité de notre côté entreprise. En tant que développeur, j’ai accès aujourd’hui à des socles d’exécutions faciles et simples, comme CloudFoundry, Google App Engine, Windows Azure, Heroku, OpenShift ou Beanstalk.
Il y a d’abord une peur du « locking » lié aux premières expériences avec le Cloud. Faire le choix d’utiliser le cloud, c’est ajouter un passif sur son projet, plus ou moins important selon le type de solutions retenues. Comme dans un projet classique, plus le temps avance et plus la valeur de cette dette augmente. Sur le Cloud Computing, il y a parfois de mauvaises surprises. Nous ne sommes pas à l’abri de l’abandon d’une solution, et donc de la faillite d’un projet. Cependant, nous allons voir qu’il existe différents types de solution. De la solution fermée proposée par Google App Engine (type PaaS) à une solution ouverte et open-source comme CloudFoundry.
Google App Engine a été une plateforme intéressante à sa sortie, mais qui soufre de quelques défauts. Tout d’abord les restrictions sur l’API Java, qui en font une version édulcorée et qui posent parfois certains soucis lors du développement. Ensuite l’absence de système de gestion d’état, comme les Webs Dyno Workers d’Heroku qui permettent d’avoir des tâches régulières. Cela force une architecture sans état, ce qui n’est pas adapté à tous les cas d’usages. Enfin l’aspect locking est trop fort avec la solution de Google.
CloudFoundry est un projet open-source plus ouvert que GAE. Le support de PHP par exemple a été proposé par la communauté, via GitHub. Cet aspect open-source est une sécurité importante pour éviter le locking à moyen-long terme. Mais je trouve que cette solution ne répond pas à tous mes besoins de développeur.
Je préfère une solution un peu plus complète du type « PaaS » (platform as a service ) comme celles proposées par CloudBees ou Heroku. Je viens chercher un service, pas de nouveaux problèmes. Le packaging de MongoDB ou la facilité de mise en production d’une base PostgreSQL avec Heroku sont autant de temps gagné. Certes, je peux acheter un serveur dédié chez un hébergeur. C’est moins cher. Mais mon métier est d’abord de développer une solution pour mon client, pas de découvrir le tuning en production d’un serveur d’application.
Le Développeur ne veut pas que de l’hébergement, mais aussi des solutions pour coder dans le Cloud
Les solutions de Cloud Computing qui se contentent de proposer « des ordinateurs dans les nuages » sont déjà dépassées. Ce que veux le développeur, c’est des services. Venant de la communauté Java, j’attends un niveau d’industrialisation plus important. J’attends par exemple des solutions qui proposent de l’ hébergement de mon code, la gestion des tickets, la compilation et l’intégration continue, l’audit technique de la qualité du code, et des facilités pour passer d’une version à l’autre, pour configurer mon infrastructure en me basant sur l’usage de mes clients, pas sur des plans d’architectures théoriques. Je veux des services simples, décentralisés et sécurisés.
Cela explique le succès de certaines solutions comme CloudBees ou Jelastic. Ces solutions dans le cloud proposent la partie « run » mais aussi la partie « dev » avec l’intégration du build. CloudBees va assez loin en proposant aussi l’intégration continue et des outils de suivi de la qualité du code. Tout ceci est plutôt teinté Java. Nous avons créé une forte culture de la qualité. De nombreux projets open-source autour du build comme Jenkins par exemple proposent des outils facilement intégrables dans le Cloud.
En tant que développeur, l’hébergement est un problème déjà résolu. La capacité à monter en charge et à régler la puissance disponible est aussi un problème résolu depuis 2007 avec Amazon EC2. Ce que je cherche aujourd’hui, c’est la suite : j’aimerai des outils collaboratifs puissants dans le Cloud, afin de travailler efficacement en équipe. L’éditeur eXo Platform va encore plus loin en proposant un IDE dans le Cloud. La promesse est de coder et de compiler à distance. Le tout via un navigateur. J’avoue que j’ai du mal à franchir ce dernier point. Mais je crois à l’idée du développement à distance, où le code n’est plus sur notre ordinateur en local. Demain, nous travaillerons de manière collaborative, à plusieurs développeurs, sur différents projets. Untel sera expert de l’API Facebook et travaillera quelques jours sur votre projet. Un autre sera l’expert MongoDB et viendra vous apporter une solution, au coeur de votre projet.
Amazon reste une solution d’infrastructure, qui répond à un problème d’hébergement. Il faut regarder un niveau au dessus et chercher des solutions « clés en main » où le développeur ne fait PAS d’infrastructure. De la même manière que nous avons oublié la notion de serveur (vous vous souvenez de la pub IBM au début de cet article ?) il est maintenant temps d’oublier l’infrastructure.
La plateforme du développeur de demain
Du coup je pense que ce sont des plateformes complètes qui vont finalement apporter un changement pour le métier de développeur. Il n’est pas interdit de penser que dans quelques années, même le développement dans une Banque ou un groupe d’Assurance se fera sur des PaaS plutôt qu’à l’intérieur du SI de l’entreprise. Je pense que des petites équipes autonomes et hautement qualifiées seront capables de construire des infrastructures complètes. La clé sera l’intégration avec les différents systèmes de l’entreprise. Nous pouvons imaginer que l’hébergement de serveurs par une entreprise dont le coeur de métier n’est pas l’informatique sera l’exception, pas la règle, dans quelques années. Les coûts de développement pourront être réduit avec la virtualisation des serveurs et des environnements des développeurs. Et il n’y a pas d’intérêt à le faire faire par sa DSI. Ce sera peut-être le prochain gros gâteau pour les entreprises comme VMWare, mais il y aura aussi des projets « complètement dans le Cloud ».
Je pars de l’hypothèse que tout sera Web, tout du moins pour les nouveaux services. Ne pensons pas à des solutions qui « remplacent » l’existant, mais surtout à la façon de développer dans les années qui viennent de nouveaux projets. Il y aura encore longtemps des projets Cobol (collection année 90), des projets J2EE (mode été 2000) et des projets Spring/Pas-J2EE (dont la première version date du 25 juin 2003).
Franchement, un environnement de développement complet et facilement clonable avec par exemple Vagrant supprime la phrase la plus débile de la terre qu’un développeur peut vous dire : « ouais ça marche sur ma machine mais pas sur la prod« . S’il n’est pas toujours nécessaire d’avoir un environnement complet sur sa machine, disons qu’en 2012 on apprécie de pouvoir travailler « déconnecté » d’Internet. Peut-être que dans les 5 ans à venir nous développerons dans le Cloud, mais pour l’instant je code surtout sur mon Macbook Pro (un noyau Unix soit-dit en passant).
Le code ensuite appartient à tout le monde, nous sommes collectivement responsables de sa qualité. Un projet sans gestionnaire de code n’est pas un projet. C’est un machin. Ensuite si vous avez l’occasion de passer de SVN/CVS vers Git/Bitbucket, votre projet ne s’en portera que mieux. Git est critiqué non pas pour sa complexité mais parce qu’il remet en question votre manière de coder en équipe. J’imagine que ma solution de « Developement as a Service » (DaaS copyright Nicolas Martignole-comment-je-me-la-pète) propose un gestionnaire de code décentralisé.
Ensuite le projet demande des librairies tierces. Dans le monde Java nous avons Maven ou Ivy. Ceci permet de construire un projet complet et de ne pas avoir à télécharger de bibliothèques externes. L’ensemble du projet est capable de se compiler sans assistance. Cela permet alors à mon super DaaS de compiler le code, de l’auditer, de le tester et même de me proposer des améliorations. Peut-être qu’il pourra l’auditer dans le cloud comme le fait la plateforme Kalistick par exemple.
Une fois que le projet est compilé, l’application s’exécute dans des environnements différents. Il y a la version de production, la version en pré-production, la version « beta-test » et même ma propre version, que j’ai déployé le temps de tester quelque chose. Heroku gère le problème de la configuration avec des variables d’environnements. Lorsque vous deployez votre application Play sur Heroku, la base de données est configurée avec des variables d’environnement, dont les valeurs sont déterminées par le PaaS d’Heroku. Car c’est le moyen le plus simple de configurer un environnement.
Sur Heroku comme sur CloudBees proposent des services intégrés, les DEV@Cloud Services pour CloudBees et les Add-Ons pour Heroku. La configuration et la mise en marche d’une base MongoDB, d’un service SMTP white-listé, d’un cache ou encore d’outils de monitoring devient très simple. En tant que développeur ceci nous permet de tester une solution technique sans perdre de temps en infrastructure. C’est énorme non ? Imaginez pouvoir tester une version avec une base NoSQL en 10 minutes… Cela permet de valider/invalider des idées rapidement.
Ensuite j’arrive à une notion que je défends depuis quelques mois : la fin de la session applicative stockée par le serveur en mémoire (ou sur le disque lorsque la mémoire est pleine). Pour cela, un serveur d’application ne doit pas stocker un état conversationnel (e.g. => sticky session sucks). Ce sera le rôle d’un cache comme memcached ou Redis, ou du navigateur avec les cookies ou de la base de données. Mais pas du serveur d’application. Pour que l’application fonctionne sur le Cloud le plus efficacement possible, il faut travailler sur des architectures de type « share-nothing » ou stateless.
Globalement, il n’y a pas ou peu de différences entre l’infrastructure de développement et celle de production. Il doit être possible sur un PaaS d’utiliser exactement la même infrastructure qu’en production. En allant plus loin, on devrait être en mesure de « versioner » cet environnement. Il serait vraiment pratique de pouvoir comparer les performances de notre application d’une version à l’autre. De même, la mise en production devient très facile et immédiate. Pour installer « une nouvelle version » il suffira de :
- déclarer une nouvelle machine
- lancer la compilation et le téléchargement des dépendances sur cette machine
- copier les données de la production vers le nouvel environnement
- faire tourner des outils de tests en charge et de qualité
- changer le routage vers le nouveau serveur
- taper une commande pour déclarer une nouvelle instance sur le PaaS
- faire un Git push vers le repo Git de la nouvelle instance
- boire un Mojito frais en regardant le tout se compiler et se déployer
- vérifier que tout fonctionne
En cas de soucis, nous pourrions aussi revenir à la version antérieure en quelques instants. Ce principe existe déjà avec Google App Engine. Vous pouvez retrouver la version antérieure de votre projet très facilement.
Bref comme vous le voyez, cela donne de nouveaux outils au développeur qui devient complètement autonome. J’aime aussi l’idée que celui qui code est celui qui met en production. Cela me ramène dans mon taxi 14 ans en arrière, où finalement le développeur était le bonhomme qui allait mettre en production. Et cela avait un sens. Comme disait le CTO d’Amazon : « You build it? You deploy it! ».
Donc pour résumer : oublions la machine, oublions aussi l’infrastructure. Essayons de regarder les plateformes as a service, quelque chose qui nous permettra de construire de belles applications, aussi facile à développer qu’à déployer.
Pour aller plus loin : lisez cette excellente liste de 12 caractéristiques pour votre projet dont j’ai repris les idées http://www.12factor.net/
Hello Francois!
Très intéressant cet article! Merci
Hello
Etourdi que je suis, j’ai fait une coquille sur le prénom dans mon commentaire précédent! :-/
Nicolas nous dit:
« Pour cela, un serveur d’application ne doit pas stocker un état conversationnel (e.g. => sticky session sucks). Ce sera le rôle d’un cache comme memcached ou Redis, ou du navigateur avec les cookies ou de la base de données. Mais pas du serveur d’application. Pour que l’application fonctionne sur le Cloud le plus efficacement possible, il faut travailler sur des architectures de type « share-nothing » ou stateless. »
Moi, il y a un truc que je ne comprends pas. Quelle est la différence entre ta session sur le serveur d’appli et stocker un état de session dans un cluster de serveur distant dans memcached? Dans un sens, ton serveur d’app est obligé d’aller sur un serveur memcached particulier pour récupérer d’info. C’est pas sticky ça?
@emmanuelbernard : je te propose de donner une réponse détaillée dans un article plus long. La réponse courte : un memcached/ehcache ou un redis doit être vu comme un espace mémoire distinct de ton serveur d’application, partagé par plusieurs instances de ton (tes) serveurs d’application. Est-ce que le rôle de ton serveur d’application est de gérer de l’espace mémoire ou de répondre aux requêtes de tes clients ?
Regarde par exemple http://www.12factor.net/concurrency
Ce qui me chagrine dans ses approches où la mémoire est 100% décorrélée du process, c’est que ça met juste entre parenthèse un truc fondamental, l’accès réseau est juste 100 fois plus lent que l’accès en RAM (cf
https://gist.github.com/2841832). Et encore c’est dans le meilleur des cas:
– réseau du feu de dieu – si on parle de serveur coloc dans un datacenter, c’est plus du 5000 fois plus lent
– hypothèse de sérialization / déserialization de coût zéro – temps, CPU, difficulté
Article très intéressant, merci. Mais je crains que les entreprises qui ont investi dans des datacenters soient prêts à passer au cloud; et je ne parle pas de leur craintes quant à la confidentialité de leurs données.
Ce n’est pas le sujet premier de l’article, mais comme Emmanuel Bernard, je suis assez intrigué par cette notion qui apparait dans les discussions à droite et à gauche : « sticky session sucks ». Est ce que tu as des articles poussés sur le sujet? Autres que des articles creux de fashion-addicts?
Mickaël : je te prépare un article pour d’ici quelques semaines
Juste pour rebondir sur le point évoqué par Emmanuel,
Oui l’accès mémoire (cache interne serveur web) est de l’ordre la micro-seconde alors que l’accès réseau est de l’ordre de la milli, mais c’est pour ça que ce n’est pas qu’une question de matériel ou de faire tout blanc ou tout noir. Les deux peuvent être utilisés conjointement à mon sens car complémentaires.
Tu as plusieurs front web devant toi-> si tu affiche un gros document dans une page qu’il a été couteux de généré depuis ta base de données (et que probabilité d’affichage est supérieure au nombre de tes fronts bien sur…), tu peux le stocker sur ton cache réseau.
Si tu dois afficher pour chaque page, disons par exemple, un super menu de la mort avec les 200 liens du site qui sont chacune de objets et qui sont tout petits mais potentiellement dynamiques en fonction du contexte, est-ce que tu vas faire 200 x qq ms pour chaque page que tu affiche -> non, tu vas prendre le cache local, ou bien tu vas structurer ta donnée autrement.
C’est là où il faut aussi prendre en compte le design de l’application et peut-penser penser autrement certains préceptes voulus gravés dans le granit il y a 30 ans et qui n’ont peut être plus lieu d’être aujourd’hui (RDB/NOSQL suivez mon regard…).
Sinon Nicolas, superbe vision du futur et bel article! moi qui suis vieux ds le web aussi, je m’étais fais les memes réflexions. Ce qui est bien avec cette vision, c’est que le dev, devient chaque jour un peu plus devops, reprend chaque jour un peu plus le contrôle de son appli et que l’obscurantisme prédit par de nombreux bureaucrates de l’informatique (bouh, développer c’est mal, vous projet, code offshore) il y a déjà de nombreuses années n’est pas encore prêt d’être efficace…
Petite remarque sur « les publicités ‘à la IBM’ » :
IBM a lancé ses premières campagnes de « On Demand » en 2002 😉
Tout comme IBM a été un des premiers ‘gros’ à embrasser Linux et le le commodity hardware (les softs IBM dont WebSphere coutaient moitié moins cher sur serveurs blades il y a 7 ans).
Ok IBM Smart Cloud offre du Mainframe sur le Cloud 🙂 mais c’est une portion infime du catalogue, l’offre principale est du « commodity hardware » …
… alors que d’autres, après avoir rejeté le cloud computing par la voix même de leur PDG, construisent aujourd’hui un « mainframe cloud » à base de database-appliance et de java-appliance.
Et ces dernières années, les publicités de mainframes dans les aéroports ont un logo rouge, pas un logo bleu 🙂
Je ne dis pas pour autant que je rêve de big-fat-full-stack-jee-server sur le cloud (bleu, rouge, …) mais je pense que le plus ‘tradi-vieille-école’ en ce moment, ce n’est pas Mr Blue sur ce coup là 🙂
Sur ces belles paroles, je retourne travailler sur un environnement CloudBees ; j’ai de la chance, le cloud est le quotidien de mon client !
Cyrille
@Rui
Je ne suis pas contre l’utilisation d’un cache pour les données longues à calculer. Je restais juste perplexe sur l’idée que la stick session c’était à éviter et qu’il valait mieux mettre les données spécifiques à l’utilisateur dans un cache sur une autre machine que les garder en session sur le même serveur.
@Emmanuel rien ne te force à ce que ce soit sur une autre machine. Avec Redis je configurerai le serveur en slave. Mais que ce soit gérer par un cache, cela a du sens. Tu peux aussi rester dans la même JVM avec ehcache mais l’intérêt est limité. Ce que j’aime avec ehcache ou memcached, c’est que la partie infra (sur la meme machine ou non) est une décision modifiable et que tu peux prendre plus tard. Lorsque tu mets toutes ces informations dans la mémoire de ton serveur d’application, c’est terminé.
Excellent article, qui pose de vraies questions et une remise en question sur notre métier.
Et c’est ainsi que mon (ex) DSI vient d’exploser lui même la DSI en disant que cette notion devait disparaitre des entreprises. Il a coupe l’ancienne équipe en deux parties : l’infra et la prod du legacy sont dans une équipe (qu’il a refilée à un autre manager), les études et le dev sont dans sa nouvelle équipe. Et aux études et au dev, on cloudifie un peu plus chaque jour depuis deux ans…
Excellent article Nicolas dont une partie est déjà mon quotidien et une autre mon devenir.
Pour les sessions stateless, je suis assez d’accord mais juste en théorie. Dans la pratique, c’est la crise. Et dans les périodes de crise, on développe à moindre coût. On cloudifie, on réduit l’infra, on maintient l’existant efficacement et on réutilise les bonnes vieilles recettes qui marchent. La session statefull, c’est un vieux truc qui marche encore plutôt bien. Et des applis à 500,000 users, je n’en fais pas tous les jours. Euh… en fait, je n’en fais jamais. Donc, un Spring, un Vaadin, un pool jdbc, un pom.xml, un hudson, un nexus et un vieux SVN devraient encore faire l’affaire cette année (et peut-être même l’année prochaine 🙂
Je trouve au contraire qu’AppEngine se bonifie avec l’âge.
Les restrictions sont devenues rares, le nombre de langages supportés ne cesse d’augmenter, rajout de fonctionnalités asynchrone push et pull, limites d’exécution sans cesse repoussées, ajustement des ressources totalement dynamique, etc…
Comment concilier « ensuite l’absence de système de gestion d’état » et « un serveur d’application ne doit pas stocker un état conversationnel », quelques paragraphes plus bas? AppEngine propose memcache et des backends (pas de limitation de traitement, persistants, accessibles directement)
Comme je suis pas foncièrement d’accord sur tout, ça serait pas drôle sinon ;-),
une petite réponse : Le Cloud n’est pas la martingale
Hello,
N’est-ce pas un peu contradictoire de dire « un serveur d’application ne doit pas gérer les sessions » et en même temps « Play! ça roxxx ».
Bon ok Play! est Restfull mais quand même, la contradiction reste « découplage des responsabilités » VS « framework qui gère tout du début à la fin »
Perso je n’ai pas encore d’opinion tranchée sur laquelle des deux approches choisir, je pense que ça dépend des applications.
Dans un sens, quand on utilise un serveur d’application lourd, on a souvent une stack plus modulable que celle de Play! du coup tu n’as peut-être pas tort de dire qu’on ne devrait pas utiliser la gestion des sessions du serveur (ni d’autres services d’ailleurs?)
« sticky session sucks »: j’ai vu ça chez Amazon. Un load balancer qui fait du sticky session doit aller lire loin dans les paquets pour retrouver les cookies de session et aura donc 10x moins de capacité de traitement qu’un load balancer plus simple. Le choix est vite fait dès qu’on a un peu de traffic. Et ce n’est que l’un des nombreux problèmes. Tiens d’ailleurs j’ai une slide là-dessus (warning: elle prêche pour App Engine, ma paroisse actuelle): http://cloudpresident.appspot.com/#13
« sticky session sucks x2 »: avec de l’état en ram, c’est une petite catastrophe dès que votre instance meurt. Au mieux, votre utilisateur se retrouve délogué proprement, au pire l’appli est dans un état indéfini avec des bouts d’état commités en base. C’était pas trop grave du temps où le serveur ne mourrait que lors des maintenances, une fois par an.
Dans un PaaS moderne (comme App Engine – oui, je travaille chez Google 🙂 votre appli tourne dans plusieurs datacenters à la fois et le coordinateur peur faire basculer des instances vers un autre datacenter en quelques secondes en cas de souci. Il ne se prive d’ailleurs pas de le faire en fonction de la charge de chaque datacenter. Les instances meurent et rescuscitent tout le temps. C’est ça qui fait la résilience de la plate-forme. Le cas de la mort d’un serveur, voire même de la mort d’un datacenter, y est prévu comme un cas d’utilisation normal et fréquent.
Mais pour que ça marche, l’archi doit être stateless en ram + memcache + datastore. Exit les sticky sessions.
note pour les inconditionnels des variables de session: App Engine vous permet de les garder. Elles sont implémentées « proprement » au-dessus du memcache et datastore, pas dans la ram de l’instance.
Pour revenir a GAE, moi ce qui me semble un peu embêtant c\’est le prix et le couplage.
La technologue derrière semble vraiment sympa.
Le couplage ne me semble pas plus fort que Play! par exemple.
Je précise: je dis ca sans connaitre vraiment plus que ça. Je me souviens juste qu\’a l\’époque, au moment du lancement, par exemple, il y avait quelques soucis connus au niveau du support de JPA.
Pour avoir assisté au Cloud Day chez Xebia, aujourd\’hui cela semble résolu, et il y a même une offre MySQL scalable.
C\’est bien beau d\’être scalable, mais a quel prix?
Il me semble que GAE facture en fonction des ressources utilisées.
Faire une jointure distribuée ça coûte énormément en ressources.
Bref sans rentrer dans les détails, à mon avis GAE est super pour une startup qui fait un POC, un prototype, mais pour une production d\’envergure, sans une sensibilisation des devs aux coûts, a voir.
Je ne crache pas sur GAE, la simplicité de déploiement est vraiment cool, après, tout dépend des attentes qu\’il y a derriere.
Moi j’aime bien les développements « cost-aware ».
Pour référence le pricing détaillé d’AppEngine est ici: http://www.google.com/enterprise/cloud/appengine/pricing.html
@Martin Gorner
« Un load balancer qui fait du sticky session doit aller lire loin dans les paquets pour retrouver les cookies de session et aura donc 10x moins de capacité de traitement qu’un load balancer plus simple. »
Il ne faut pas aller *si* loin que cela dans les paquets pour retrouver les infos nécessaires mais cela reste relatif. Bien entendu il y a plus de boulot pour permettre le sticky session, c’est indéniable mais à mon sens ce n’est pas contre nature de demander cela a un load balancer, ça fait parti du job.
De là à dire que ça va 10 fois plus lentement ET donc que ça ne tiendra pas la charge, je ne suis pas d’accord. Il faut mettre en comparaison avec ce qu’engendrent les autres méthodes permettant la gestion d’états:
– stocker niveau client -> sympas pour les applis mobiles et l’overhead network sur une partie de l’infra qu’on ne maîtrise pour le coup par du tout (pas comme le load balancer)
– stocker sur memCache ou autre ou cela requiert
serialization/deserialization,…, tout a un coût
« Dans un PaaS moderne (comme App Engine – oui, je travaille chez Google )…
Mais pour que ça marche, l’archi doit être stateless en ram + memcache + datastore. Exit les sticky sessions. »
Si j’étais mauvaise langue j’aurai tendance à comprendre: « App engine est un Paas moderne mais qui ne supporte pas les sticky sessions donc les sticky sessions c’est nul ». J’attends d’un Paas moderne qu’il supporte un éventail le plus large de possibilités, pas qu’il me bride dans mon métier. Mais ce n’est que mon avis. Après qu’il y ait des limites, bien entendu mais l’argument est mal exprimé…
Je préfère qu’on me dise « attention notre solution ne supporte pas les sticky sessions, il vous faudra faire un choix » plutôt que « quoi? vous faites du sticky session? bande de gros nazes, arretez cela si vous voulez un jour faire du clouding ».
Je ne suis pas à tout prix pour le stateful géré par le serveur d’app mais:
– je ne trouve pas cela sale
– je trouve au contraire que ça colle parfaitement a différents types d’applis
– sauf à créer un store comme amazon, il faut quand même y aller pour atteindre la limite de performances. C’est plus la qualité d’implémentation que la stratégie de prise en charge du ‘stateful’ qui jouera.
Et qu’on se le dise clairement, énormément d’applis SONT stateful et il faut faire coller ce besoin sur une base http qui ne l’est pas.
On s’adapte, on ne dénature pas.
@Anthony Patricio
Attention à ne pas confondre « variables de session » et « sticky sessions ».
Comme je l’ai dit plus haut, App Engine supporte les variables de session. Elle sont implémentées par-dessus memcache et datastore et non pas dans la RAM de l’instance.
« sticky session » est le nom d’une d’une technologie qui permet aux load balancers d’envoyer un utilisateur donné vers une instance donnée, toujours la même. C’est ce point d’architecture qui est je pense, obsolète aujourd’hui. Le fait de vouloir envoyer un utilisateur toujours vers la même instance parce que sinon « ça marche pas » n’est plus d’actualité. Pour qu’un PaaS soit stable et fiable il faut que le client puisse arriver vers n’importe quelle instance et que tout fonctionne parfaitement.
C’est le rôle de memcache: cette technologie vous assure de pouvoir récupérer une donnée client à partir de n’importe quelle instance et avec de meilleurs performances qu’un accès base.
J’espère que c’est plus clair. Ce n’est pas un débat stateful vs. stateless, mais un débat sur la meilleure technologie à utiliser pour stocker l’état de l’application tout en assurant la fiabilité et la montée en charge.
@Martin
Merci pour le rappel, c’etait clair dans ma tete, peu être moins dans mes propos. Si tel était le cas désolé 🙂
Et je ne pense toujours pas que le sticky session soit obsolète.
D’ailleurs, si je ne me trompe pas, EC2 le propose, ok ça ne prouve rien.
Les solutions de type MemCache sont intéressantes, c’est certains, mais y a t’il des benchs dispos pour connaître la répartitions des charges avec une telle configuration?
Sur le papier c’est toujours beau mais en réalité on touche toujours des points « génants » (ex: EC2 super dispo oui mais avec perf loin d’être homogene), de nouvelles contraintes, des promesses de réduction de coût non tenues (NoSQL), …
Les caches distribués c’est bien, mais je trouve pas que le sticky cession n’ait plus lieu d’être.
Prenons 2 instances I1 et I2
En local sur chacun des serveurs, un memcached (M1 et M2), donc accès réseau local possible.
Si l’utilisateur va sur I1 au début, le cache M1 va s’alimenter avec ses données.
Si il va ensuite sur I2, le cache local M2 va s’alimenter avec ses données.
Alors qu’avec des sticky sessions, si l’utilisateur va toujours sur I1, seul le cache local M1 s’initialise avec les données de l’utilisateur.
Si I1 tombe, alors l’utilisateur tape sur I2 et donc le cache M2 est capable de charger les données de l’utilisateur donc ça continue de fonctionner.
Bref lorsque le cache et la webapp sont sur le même serveur, je ne trouve pas que ça soit une si mauvaise idée de faire des sticky sessions: l’utilisateur est toujours envoyé la ou ses données ont au préalable été cachées, et on ne cache pas ses données sur tous les serveurs donc des caches qui prennent moins de place inutile. Avec une expiration policy calée sur la durée d’une session, au final ça donne quelque chose de pas trop mal.
Avec les technologies de MapReduce, on envoie le code la ou la donnée se trouve.
Avec les datagrids, on envoie aussi le code la ou la donnée se trouve, avec des fonctions sympas du genre n’executer le code que sur les noeuds ou il est pertinent de le faire.
Alors moi j’ai une question: pourquoi on enverrait pas l’utilisateur également la ou ses données se trouvent? Et en l’occurrence si on sait que ses données se trouvent sur une instance donnée (après la connection par ex on sait que ses données sont dans le cache M1 qui a été initialisé avec les données en base)
Moi je pense que l’avenir c’est justement d’avoir des loadbalancers capable de faire rapidement du routage plus intelligent que du simple roundrobin.
Sur un datagrid en mode partionné (j’imagine que c’est pareil pour Cassandra), chaque noeud sait ou se trouve telle ou telle clé.
Pourquoi ne pas avoir un loadbalancer qui serait capable de savoir ou les données concernant un utilisateur se trouvent par exemple, histoire d’éviter des appels réseaux inutiles. Bon ca c’est vrai que lors de l’utilisation d’un datagrid en mode embeded.
@Sebastien : en général lorsque tu mets un memcached, un Redis ou un EHCache dans ton archi, tu utilises les capacités de réplication de serveur à serveur de ces technologies pour que M1 soit égal à M2. MongoDB a par exemple besoin d’une archi 1/3 pour pouvoir avoir un master et 2 slaves. Donc globalement, tes données froides restent dans une base partagée, les données chaudes qui n’ont pas une durée de vie sont montées dans ton cache, comme Redis. Tu n’as plus besoin de sticky sessions. Du tout.
Oui je suis tout a fait d’accord.
Ca c’est quand tu veux améliorer les perfs d’une petite appli, mais que se passe-t-il quand tes caches ne peuvent pas être répliqués car le volume de donnée est trop important?
Si tu veux payer 10 instances de memcached de 128go c’est toi qui voit hein, moi je préfère faire avoir 32 instances de 4go c’est beaucoup moins cher et avec une bonne architecture tu fais exactement la même chose.
Alors c’est certain si t’as un budget illimité et que tu as envi de gâcher des ressources et mettre les données partout, tu peux et ça marche très bien 🙂
A noter que le standard JSR 107 – JCache propose la notion de CacheLoader, tout comme les datagrids, EhCache, même Guava Cache, et surement d’autres.
Plutôt que d’utiliser un cache répliqué, pourquoi ne pas simplement envoyer toujours, si possible, l’utilisateur au même endroit. Lors d’un cache-miss, le CacheLoader va chercher les données en base.
Pour gérer le failover, il n’y a rien de plus a faire: une instance tombe, tu envoies l’utilisateur sur une autre instance, il y a un cache-miss et le cache local a la nouvelle instance initialise les valeurs de l’utilisateur.
En gros tu n’initialise que 1 fois les données de l’utilisateur à la connection par exemple, et n’a besoin d’initialiser à nouveau qu’en cas de failover.
/!\ Ça c’est valable quand les données sont dispo sur une source de données (cache répliqué, NoSQL, Datagrid, SGDB…). Après c’est sur que si vous utilisez la session pour stocker des états temporaires il vaut mieux stocker ces valeurs autre part que dans un cache local, mais dans ce cas pourquoi ne pas utiliser un mode distribué/partitionné plutôt que répliqué histoire de gagner de la place (avec bien sur quelques replicas)
Je pense qu’on est suffisamment avancés technologiquement pour commencer a arrêter d’utiliser systématiquement de la réplication. Quand on voit la croissance du volume des données, mon avis est qu’il va falloir s’habituer à utiliser d’autres techniques assez rapidement si on ne veut éviter d’exploser ses coûts.
@Sebastien La réplication permet aussi d’assurer la durabilité du service, et elle permet aussi de gérer les changements de version d’une application. Typiquement, nous mettons à jour notre application 3 fois par jour, et le fait d’avoir dans un cache séparé les données des utilisateurs nous permet de le faire de maniere transparente. Le serveur d’app (si l’on peut appeler cela un serveur d’app) n’a pas du tout d’état ou de sessions.
Je ne crois plus du tout à l’idée du fail-over et d’envoyer l’utilisateur avec son petit panier sur un autre noeud. Je crois plutot à une architecture où chaque appel HTTP est complétement sans état du coté serveur. Bref je ne crois pas à l’idée de sticky session (mais alors pas du tout)
Il y a de quoi écrire un article complet, il faudra que je développe.
Nicolas je pense que tu ne comprends pas ce que je veux dire.
A aucun moment je ne prône l’architecture stateful au niveau de la session HTTP.
Je ne parle pas du tout d’utiliser les sticky sessions pour mettre des données dans la session locale et les y retrouver lors de la prochaine requête, mais d’utiliser les sticky sessions uniquement pour envoyer l’utilisateur régulièrement sur le même serveur.
Je ne comprends pas du tout ta remarque « Je ne crois plus du tout à l’idée du fail-over et d’envoyer l’utilisateur avec son petit panier sur un autre noeud. »
Si tu ne crois plus du tout au failover, a quoi peux-tu croire? Au fail? 🙂
Il ne s’agit pas d’envoyer l’utilisateur avec son petit panier sur un autre noeud, mais d’envoyer, en bonne architecture sans état, son utilisateur SANS PANIER sur un autre noeud, et que ca continue de fonctionner.
L’architecture que j’ai proposé peut très bien marcher avec du roundrobin. La seule nuance qu’il y a par rapport à l’architecture que tu proposes avec de la réplication est que mon architecture est capable de consommer moins de mémoire, à condition uniquement d’utiliser les sticky sessions. Si tu utilises du roundrobin, ca va marcher quand même sauf que chaque cache va s’initialiser de manière indépendante avec une requête SQL donc plus de requêtes.
A noter que sur Gemfire par exemple le cache distribué fait un netSearch sur les noeuds du cache avant de déclencher le CacheLoader du coup pas de requête, mais a mon avis ce genre de fonctions n’est pas toujours présent dans les caches plus simples)
Bon après je me trompe peut-être sur l’utilisation du terme sticky session, mais pour moi cela signifie qu’on envoie toujours l’utilisateur la ou il a été la requête précédente.
Vu qu’on est sur une archi sans état dans la session, tu peux très bien faire un truc du genre un IP_OF_USER.hashcode() % nombre d’instances = instance de destination
N’importe quel truc qui envoie régulièrement le même utilisateur sur la même instance est ok pour moi (bon la c’est sans doute un mauvais exemple vu que si 10000 personnes se connectent avec la même ip la distribution est pas top, mais c’est l’idée)