Heroku

Créé en 2007 puis racheté en 2010 par Salesforce.com [16], Heroku [6] est un service de PaaS spécialisé pour les applications écrites en langages Ruby, Node.js, Java, Python, Clojure et Scala. Il gère également certains canevas de programmation basés sur ces langages. Il fut originellement destiné au développement rapide d’applications web. Cette préoccupation caractérise encore aujourd’hui cette offre.

Le déploiement dans Heroku s’effectue au travers du logiciel de gestion de version git. Il suffit de pousser le code source sur le dépôt distant d’Heroku à partir du dépôt local. De façon préalable, l’utilisateur doit renseigner un fichier mentionnant les com-mandes admises par chaque conteneur d’exécution ainsi que d’éventuelles dépendances extérieures, telles que les plugins d’un serveur Node.js requis pour le fonctionnement de l’application par exemple. L’approche de Heroku repose sur des Buildpacks, des pa-quets de construction permettant à la fois de compiler le code mais aussi de l’exécuter. Cette approche est suivie par une large communauté et les Buildpacks ainsi créés sont largement utilisés par d’autres solutions décrites dans ce manuscrit.

Modèle d’application

Si Heroku repose sur l’infrastructure d’Amazon, celle-ci n’est pas directement visible par l’application. Les VMs d’EC2 et le stockage de S3 sont ainsi utilisés de façon quasi-ment transparente. L’application est exécutée dans des conteneurs légers appelés dynos. Chaque dyno peut exécuter un certain nombre de processus :

• Des processus orientés présentation de pages web.

• Des processus pour les traitements métier appelés workers.

• Des processus systèmes qui permettent notamment la gestion de l’interface en ligne de commandes, de l’administration et de l’ordonnancement.

L’ensemble des dynos requis pour l’exécution d’une application est appelé slug. Lors du déploiement, le BuilPack nécessaire est automatiquement détecté et va déterminer les dynos requis pour l’application.

Opérations d’élasticité couvertes

Chaque slug est élastique au travers d’opérations d’élasticité horizontale portant sur le nombre de dynos. Les dynos ne sont pas élastiques en eux-mêmes. Ils provoquent notamment des notifications d’erreurs lorsque leur consommation de mémoire vive excède le quota fixé par leur profil. Une fois ce quota dépassé, la mémoire supplémentaire est prise sur le swap d’où une dégradation importante des performances du dyno. Si ce rapport parvient à cinq, le dyno incriminé est redémarré automatiquement.

Heroku met à disposition différents profils de dynos. Ces profils sont caractérisés par le nombre de cœurs virtuels et la quantité de RAM. Les profils des dynos peuvent

3.3. SOLUTIONS DE GESTION COMPLÈTE DE L’ÉLASTICITÉ 41 modifiés mais, pour un slug donné, un seul profil est admis par type de dyno. Le redi-mensionnement d’un dyno entraine successivement le rediredi-mensionnement de l’ensemble des dynos de même type pour le slug auquel il appartient, puis leur redémarrage.

Architecture applicative

L’architecture de l’application est implicite et répartie en dynos dont le type détermine le comportement au sein de l’application. Plus précisément le type d’un dyno induit les liaisons vers les autre(s) type(s) de dynos. Chaque type de dyno est présent dans un catalogue fixe.

Certains types de dynos doivent respecter le pattern singleton : à chaque instant, un seul et unique dyno de ce type doit exister pour une application. C’est notamment le cas du dyno de type clock qui est une horloge pour l’application. Il appartient à l’utilisateur de ne pas commettre l’erreur de l’instancier plusieurs fois, ce sans quoi des dysfonctionnements pourraient apparaître.

Gestion du placement

Le placement est transparent pour l’utilisateur au niveau des dynos. Ceux-ci sont répartis au sein de l’infrastructure physique par la plateforme de sorte à ce qu’au sein d’un même slug, tous les dynos d’un même type soient placés sur des machines différentes.

Au niveau des slugs, l’utilisateur maitrise leur emplacement d’exécution. Les ma-chines en elles-mêmes sont disponibles dans deux régions correspondant à deux data-centres d’EC2 :

• La région USA correspond au datacentre us-east-1.

• La région Europe en cours de test correspond au datacentre eu-west-1.

Par défaut, les applications sont déployées aux USA, sauf demande explicite lors du déploiement. Un slug est entièrement localisé dans une région.

Positionnement par rapports aux critères

• L’Indépendance applicative est Faible puisque Heroku ne gère que des applications Web. Il s’agit d’une limite due à l’utilisation de routeurs http/https qui empêchent tout autre trafic.

• Indépendance architecturale. Heroku ne permet que le déploiement d’applications ayant une architecture multi-tiers. L’indépendance architecturale est donc évaluée à Faible.

• Indépendance vis-à-vis de l’environnement. Heroku s’appuie exclusivement sur le IaaS Amazon EC2 alors même que les conteneurs légers permettent potentiellement une couverture plus vaste. Ce critère est en conséquence évalué à Faible.

• La Gestion des applications patrimoniales est évaluée à Faible puisque leur déploie-ment dans Heroku requiert de les recompiler.

• L’évaluation concernant la Granularité des opérations est Moyenne car Heroku offre une granularité au niveau du groupe de composants. Même s’il est possible de rajouter des composants individuellement (chacun étant exécuté dans un conte-neur), l’élasticité verticale ne peut s’appliquer qu’à l’ensemble des dynos de même type.

• Concernant la modélisation à l’exécution, celle-ci est évaluée à Moyenne en raison de l’absence d’un modèle ayant un niveau de détail plus fin qu’une liste des dynos utilisés par l’application.

• La modélisation de l’élasticité évaluée à Moyenne. Heroku n’offre effectivement qu’une approche explicite mentionnant une liste des types de dynos que l’applica-tion utilise.

• Enfin, l’Expression de contraintes est évaluée à Faible : aucune expression n’est possible. L’exemple du pattern singleton est révélateur de ce point.

3.3. SOLUTIONS DE GESTION COMPLÈTE DE L’ÉLASTICITÉ 43