Heroku

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

Heroku est un service de cloud computing de type plate-forme en tant que service. Créé en 2007, il était l'un des tout premiers services cloud, puis a été racheté par Salesforce.com[1]. À l'origine dévolue aux applications web programmées en Ruby et utilisant Rack (typiquement, des applications Ruby on Rails ou Sinatra), l'offre s'est ensuite étendue à d'autres runtimes : node.js, Java, Spring et Play, Clojure, Python et Django, Scala, API Facebook, ainsi que PHP de façon officieuse. Les différents runtimes coexistent aujourd'hui dans un même stack polyglotte, nommé Cedar, tournant sur une base d'Ubuntu[2]. Le service permet le déploiement très rapide d'applications web dans le cloud, avec une gestion très souple du scaling horizontal au travers d'un modèle de gestion des processus emprunté à Unix et adapté au Web[3].

Éléments historiques[modifier | modifier le code]

Heroku a été fondé par une poignée d'ingénieurs qui trouvaient le développement d'applications web trop fastidieux. James Lindenbaum, Adam Wiggins et Orion Henry fondent Heroku en 2007 avec l'intention de supporter toutes les applications Rack[4]. Le 8 décembre 2010, Salesforce.com se porte acquéreur de l'entreprise Heroku et l'intègre comme filiale du groupe. Le 12 juillet 2011, Yukihiro "Matz" Matsumoto, créateur et mainteneur du langage Ruby, rejoint Heroku comme Chief Architect[5] (bien qu'il se consacre essentiellement à Ruby). La même année, Heroku et Facebook nouent un partenariat[6].

Au fil des années, le stack s'est élargi. Coté bases de données, Heroku a intégré plusieurs bases NoSQL, dont MongoDB et Redis, bien que la base par défaut soit toujours PostgreSQL. Un serveur DNS est désormais disponible. Une architecture complètement modulaire du stack est venue remplacer les anciennes versions monolithiques, introduisant le support d'un grand nombre de runtimes et la possibilité de créer une version personnalisée du stack.

Fonctionnement[modifier | modifier le code]

L'infrastructure utilisée par Heroku repose sur AWS[7]. Différents services d'AWS, notamment EC2 (pour l'exécution du code) et S3 (pour le stockage) sont mis à profit dans l'architecture Heroku pour mettre à disposition de l'utilisateur final un environnement de déploiement et d'exécution adapté à son besoin. Cet environnement est accessible à travers la ligne de commande, via git, et un ensemble d'outils spécifiquement développés par Heroku (le heroku tool belts, un CLI dédié).

L'architecture Heroku est centrée sur les processus, et non sur des instances virtuelles ou des serveurs. Le code déployé est analysé pour détecter le type d'application à faire tourner, ainsi que les processus nécessaires ; l'analyse déclenche la mise en place d'un environnement dédié, adossé à une ou des unités d'exécution appelés dynos, lesquelles font tourner les processus requis pour faire fonctionner l'application deployée. L'utilisateur final peut explicitement déclarer quels processus utiliser, et comment les scaler, mais la plateforme est capable de réaliser ce travail de façon automatique, en laissant simplement à l'utilisateur l'opportunité d'affiner ses réglages par défaut.

Un dyno contient un certain nombre de processus : typiquement, un ou plusieurs processus dits « web » (ie. des instances d'un serveur web, pour l'exécution des requêtes routées vers l'application déployée), un ou plusieurs worker (pour les calculs tiers), ainsi qu'un nombre arbitraire de processus système (one-off admin process, scheduling processes, processus ouverts temporairement via le CLI…). L'ensemble des dynos requis pour faire tourner une application Heroku forment un slug, une unité matérielle logique qui adresse son propre système de fichier transitoire, possède une certaine capacité en RAM exclusive, etc. Le slug est scalable horizontalement à l'infini en modifiant la physionomie des dynos, quoique l'architecture des applications web empêchent souvent un scaling trop agressif (dans le cas de performances limitées par les accès à une base de données lente, typiquement). Le déploiement de code sur un slug, ou la modification de variables d'environnements, occasionnent une « recompilation » du slug, de sorte que le ou les dynos ainsi que le matériel qui le composent sont ré-adaptés aux nouvelles conditions d'exécution de l'application. L'utilisateur peut enfin, à tout moment, scaler manuellement toute ou partie des composants d'un slug, c 'est-à-dire modifier le nombre de processus de chaque type intervenant dans l'exécution. De nombreuses extensions sont par ailleurs activables pour augmenter les capacités de l'environnement (mise en place de bases de données spécifiques, monitoring, etc.)[8]

Le modèle économique d'Heroku repose sur un adressage fin du temps-horloge dévolu aux dynos (web et worker) d'un slug[9]. Certains dynos sont facturés à l'heure, tandis que d'autres sont monitorés à la seconde près. Compte tenu du fait qu'il revient à l'utilisateur d'anticiper la charge et de décider du nombre de dynos requis par une application déployée sur Heroku, il s'agit d'un PaaS automatisé en exécution, mais pas en scaling, avec un impact direct sur la tarification. Plusieurs services tiers se proposent de réaliser un auto-scaling des architectures Heroku pour minimiser la facturation. La plupart des extensions, quant à elles, offrent différents niveaux de prix selon le nombre et la complexité des fonctionnalités activées. Une offre grands comptes, avec un support personnalisé et des fonctionnalités techniques avancées, est également disponible.

Notes et références[modifier | modifier le code]

Voir aussi[modifier | modifier le code]

Liens externes[modifier | modifier le code]