[Devoxx FR 2013] – Cloud Best Practices
Ces dernières années, le Cloud Computing a pris de plus en plus d’importance. Les offres de Cloud se sont fortement développées, notamment de type « Plateform as a Service » (PaaS) avec des acteurs tels que CloudFoundry ou CloudBees. Grâce à ces nouvelles offres, les développeurs sont plus productifs que jamais, mais le Cloud leur ouvre de nouveaux challenges.
Dans cette présentation, Eric Bottard fait le parcours de 10 bonnes pratiques d’architecture et de développement pour assurer une transaction réussie sur le Cloud. Eric est ingénieur chez VMware spécialisé sur la plateforme PaaS CloudFoundry. En tant que “Developer Advocate” à VMware, il encourage l’adoption du Framework Spring et aide les développeurs à migrer leur application sur CloudFoundry.
La plateforme CloudFoundry
Comme indiqué ci-dessus, c’est une présentation ciblée sur des solutions PaaS avec des exemples sur la plateforme CloundFoundry. Celle-ci est une plateforme développée par la société VMware, ce talk était un peu (principalement) orienté sur CloudFoundry.
CloudFoundry est une solution OpenSource de Plateform-as-a-Service (PaaS). Elle permet de déployer une application web en quelques minutes et de gérer la montée en charge, en abstrayant de la gestion des serveurs, bases de données, runtime applicatifs, serveurs applicatifs, etc.
Cette plateforme offre de nombreuses caractéristiques et fonctionnalités
- Le choix des Framework de Développement : Spring pour Java, Grails pour Groovy, Rails pour Ruby, Node.js pour javascript, Play! Framework pour Scala etc.
- Le choix des services : MySQL, PostgreSQL, MongoDB, Redis, Rabbit MQ.
- Le choix du type de déploiement : Cloud public de VMware, Cloud public d’autres fournisseurs (OpenStack par exemple), ou Cloud privé
Contrairement à CloudBees, CloudFoundry n’offre pas de services pour le développement d’applications telles que Jenkins, Maven, Selenium, etc. Un module sur CloudBees permet de déployer les applications sur la plateforme CloudFoundry. Même si les deux solutions sont concurrentes sur la partie “run”, les deux technologies peuvent donc cohabiter en toute simplicité sur la partie “dev”, ce qui est plutôt rassurent pour éviter le “lock in”.
Best Practices
Passons au thème principal de cet article c’est-à-dire aux 10 bonnes pratiques présentées dans cette conférence.
Trafic HTTP
Dans le Cloud, il est important de connaître l’emplacement des Datacenter hébergeant vos applications web et le temps de chargement de vos pages. La rapidité de chargement d’une page dépend principalement du temps pour le navigateur pour télécharger les données et autres ressources statiques (css, javascript, images). Si votre base d’utilisateurs est située en Europe, le calcul du coût de ces requêtes est d’autant plus important si le Datacenter est situé de l’autre côté de l’atlantique. Les développeurs doivent être particulièrement attentifs à l’utilisation et l’optimisation du trafic HTTP de leurs applications web.
Il existe des solutions pour analyser ce trafic comme Chrome Dev Tools, YSlow et des solutions pour l’optimiser comme Content Delivery Network (CDN), Unique Paths, Spring Resource Handler Abstraction ou Web Resource Optimizer for Java (WRO4J).
Filesystem
La notion de système de fichiers est différente dans le Cloud, le système de fichiers est attaché à une instance. Il existe plusieurs problèmes dans le cas où le développeur stocke des fichiers sur le système de fichiers local. Même si les fichiers peuvent être écrits par chaque instance d’une application, ils ne seront pas visibles par les autres instances de l’application. Pire encore, ils seront conservés seulement pendant la durée de vie d’une instance. Le redémarrage ou la suppression de l’instance entraîneront la perte définitive de ces fichiers.
Il existe des solutions pour stocker des fichiers dans le Cloud : le mécanisme de stockage GridFs de MongoDB, le BLOB dans les bases de données relationnelles ou des systèmes de stockage en ligne comme Amazon S3.
Application Stateless
Dans un environnement de Cloud Computing, il est préférable que les applications soient ‘sans état’ pour plusieurs raisons.
- Horizontal Scaling qui consiste à ajouter plusieurs instances dans l’infrastructure
- Haute disponibilité : il n’y a pas d’état à partager entre les instances
- Déploiement de l’application sans interruption de services.
La notion d’état dans une application nécessite de partager ces états entre chaque instance, avec pour conséquence de nuire à ces performances. On trouve cette notion d’état dans la session utilisateur (HttpSession en Java), l’utilisation de cache central (des caches maisons par exemple) mais également dans des Frameworks qui maintiennent un état. Spring Security à partir de la version 3.1 permet de l’utiliser avec une notion sans état.
Il y a plusieurs solutions pour conserver ces états, en maintenant l’état côté client (Push To Client) avec un Framework comme AngularJS, ou par l’utilisation d’un service de CloudFoundry comme la base Redis (stockage clé/valeur).
Database
Il s’agit de quelques recommandations pour faire évoluer les pratiques
- éviter les manipulations manuelles autant que possible, souvent génératrices d’erreurs
- comme pour votre code, faites des versions à chaque modification du schéma de votre base
- utiliser des outils comme LiquidBase pour manipuler une base de données
Vendor Lock-In
Un aspect dangereux est de se lier avec un fournisseur de service et ainsi de se retrouver coincer avec celui-ci. Il faut éviter de se coupler avec une API spécifique, on sait que changer d’outil ou de fournisseur peut coûter très cher.
CloudFoundry utilise un mécanisme d’auto reconfiguration qui permet de connecter automatiquement une application à un service de stockage de données (MySQL, MongoDB, Redis, etc.). Lorsqu’une application est déployée, CloudFoundry est capable de détecter le Framework utilisé et de récupérer les propriétés de connexion au service de stockage, sans aucune modification de code ou de configuration. Ce mécanisme supporte un grand nombre de Frameworks (Spring, Grails, Play! 1 et 2, Node.js, Rails).
Un autre point important est de se méfier de la gestion de vos données par le fournisseur. Sur certaines plateformes, il est très difficile voir impossible de récupérer ces données.
Environnements identiques
Évitez la séparation des environnements, le Cloud vous permet de créer des environnements identiques de manière simple et rapide.
| Traditionnel | Cloud | |
| Machines | Dev ≠ Staging ≠ Prod | Identique => provisionner un environnement temporaire |
| Process | Manual => guide de mise en production | Automatisation |
| People | Dev ≠ Ops | DevOps |
Cette approche nécessite tout de même de prendre quelques précautions, le développeur doit vérifier que le livrable est toujours le même. Une solution est de générer un seul livrable avec une configuration externe pour chaque environnement (One App, Many Deploys). On peut par exemple donner une variable d’environnement qui propage le nom du fichier de configuration associé à l’environnement.
Approche SOA
Il est de plus en plus simple d’assembler des applications dans le Cloud. C’est l’occasion de penser à découper ces applications en plusieurs petites applications et de se diriger vers une vraie approche orientée service. Gardez la philosophie des outils Unix “Écrivez des programmes qui font une seule chose mais qui le font bien“.
Le développeur doit s’intéresser au plus tôt aux orientations de son architecture, il est difficile de modifier ces choix lorsque les développements sont bien avancés. Il dispose de nombreux concepts pour que ces applications communiquent entre elles.
- Asynchrones vs Synchrones : HTTP vs AMQP
- Format : XML, JSON, PBuffers, Thrift
Spring Integration est une réponse à ce type de problème, il simplifie l’intégration de ces technologies dans vos applications.
Déploiement
Sur la lancée de l’intégration continue, poussez l’idée un peu plus loin et adoptez l’approche du déploiement continu (Continuous Delivery).
Continuous Delivery = Continuous Integration (Automatic Builds, tests) + Automatic deploy
Eric Bottard présente le risque du déploiement de la façon suivante “il est proportionnel à la taille des changements dans le code et à la durée par rapport au dernier déploiement”. Avec cette approche, le développeur en tire plusieurs bénéfices.
- Détecter les problèmes au plus tôt
- Les environnements étant identiques dans le Cloud, il n’est pas nécessaire de déployer automatiquement en production
- Avoir constamment une application prête pour être déployée sur la production qui est testée et validée par le processus d’intégration continue
Les outils Maven et Jenkins permettent aux développeurs d’automatiser cette tâche. L’offre DEV@Cloud de CloudBees fournit les briques les plus classiques : Jenkins, Maven, Repository d’entreprise, etc.
Scale
Chaque application est différente (CPU, RAM, Disk, Bugs), évitez les approches automatisées qui ne répondent pas forcement à vos besoins. Il est préférable d’écrire ses propres logiques pour dimensionner les ressources de chaque application. CloudFoundry fournit des services de métriques (system-level metrics). Pour trouver le bon ratio, vous pouvez combiner ces métriques systèmes avec vos métriques métiers.
Upgrade
Cette dernière pratique contient 3 patterns pour mettre à jour son application.
- Blue/Green Deployment : Déployer son application sans interrompe le service. Les applications stateless facilitent ce type de mise à jour.
- Canary release : Il s’agit de donner accès à la nouvelle version à une partie de la population (privilégiée) avant de la déployer pour tout le monde.
- A | B Testing : Partager deux versions de l’application pour les essayer sur les utilisateurs. Cette technique permet d’évaluer ces deux versions pour prendre une décision sur la version définitive.
Conclusion
Cette conférence était vraiment intéressante pour un développeur qui souhaite déployer son application sur un PaaS et répondre aux problématiques de ce type d’environnement. Les offres PaaS manquent de standardisation, en suivant ces recommandations, le développeur évite de se retrouver emprisonner avec un fournisseur.
Je conseille aux développeurs de s’orienter vers des plateformes comme CloudBees, CloudFoundry ou Heroku. Elles prennent en charge des Frameworks web (Java/Spring, Play !, Grails, etc.) et des services (MySQL, MongoDB) reconnus favorisant la voie de la standardisation.