tl:dr; A part quelques exceptions, Heroku devrait être un no-brainer pour toute start-up qui a des problématiques d'hébergement. En effet la plateforme améliorera autant vos environnements de production que vos pratiques de développements et de QA.
Des années d'évolution de mentalités pour finalement apprendre à lâcher du lest : du VPS à Heroku
Notre métier est de concevoir et d'implémenter des produits digitaux. Souvent, nos clients souhaitent d'ailleurs que nous prenions en charge l'exploitation de nos réalisations, c'est à dire l'hébergement dans le cas d'applications web. A notre création, en 2014, il était d'usage d'opérer des instances de machines virtuelles (Virtual Private Server / VPS). Notre fournisseur était alors Rackspace Cloud, puis nous avons migré plus tard vers Digital Ocean lorsque celui ci est sorti du bois : 4 fois moins cher et pourtant beaucoup plus performant.
Notre stratégie était la suivante : à chaque application son serveur. Pour les plus exigeantes d’entre elles, nous mettions en place des stratégies plus fines du type un serveur par service de façon à pouvoir gérer horizontalement la scalabilité.
Toute cette gestion de serveurs représentait pour nous du temps, que nous facturions plus ou moins facilement à nos clients. Il était assez simple de faire comprendre le coût lié à l'installation d'un serveur, moins celui lié à la surveillance régulière des machines et à leur mise à jour et encore moins lorsque nous devions résoudre des incidents de production dû à des pannes !
Très vite, l'arrivée de la technologie Docker a fait évoluer nos pratiques grâce à ses nombreuses promesses : Docker incarnait la possibilité de faciliter la création d’environnements de développement et de production. D'ailleurs leur baseline “build once, run everywhere” le résumait bien. Si sur le papier l’approche semblait idéale et promettait des économies d'échelle, nous n'avons en réalité quasiment pas ressenti de gain de temps. Appréhender Docker, technologie pourtant simple de prime abord, n’était pas si facile. Le temps que nous pouvions consacrer à l'administration système étant toujours à la marge, il nous restait pénible d'acquérir des pratiques suffisamment robustes et industrialisées. Malgré tout nous étions convaincus de la nécessité de la containérisation et en particulier d'avoir la capacité de répliquer facilement nos environnements.
Nous avons décidé en 2016 de challenger Docker avec Heroku. Son offre avait bien évolué et proposait maintenant :
- un auto deploy connecté à des branches de projets Github
- des review apps : c'est à dire des instances d’applications pour chaque “Pull Request” ouverte
- une vue synthétique de tous les environnements applicatifs actifs sous forme de pipeline
- une documentation extrêmement complète pour la plupart de nos langages et frameworks usuels
Il n’a pas fallu plus de quelques semaines d'utilisation de Heroku pour s’apercevoir de quelque chose de majeur : l'infrastructure était devenue génératrice de valeur pour nos clients.
Internaliser l'administration système, vraiment ?
Nous avons été fous d’investir autant d’énergie sur l’hébergement d’applications. Administrer des serveurs, c'est à dire ce que propose au final un Amazon ou un Digital Ocean ou OVH, est un métier compliqué, chronophage et risqué. Nous avons toujours fait de notre mieux dans l’exercice de cette tâche mais n'étions nous pas naïfs de nous croire capable de le faire ?
Lorsque vous gérez vous même votre infrastructure vous devez vous poser un tas de questions et voici quelques exemples qui illustrent l’ampleur de la tâche:
- Gestion des données : que faire en cas de crash ? Quelle est la politique de sauvegarde ? C’est à dire à quelle fréquence sont elles effectuées ? Combien de temps sont elles conservées? Plus d’actualité : suis je conforme avec la législation en vigueur, par exemple la RGPD ?
- Disponibilité : pouvez vous garantir un niveau minimum de up-time ?
- Monitoring et alerting : quelles sont les sondes que vous allez mettre en place ? En cas de problèmes, quel est votre protocole d’escalade ? Comment réagir en dehors des heures ouvrées ?
- Reprise d’activité : Testez vous votre plan de reprise d’activité ? Etes vous capable de garantir que vous pouvez reconstruire vos services sur une nouvelle infrastructure sans encombre ?
Ces quelques questions posent au final celle de la capacité à assumer le choix de la gestion d'une infrastructure et ouvre la porte au débat « Infrastructure as a Service » versus « Platform as a Service », soit dans notre cas les VPS/docker vs Heroku . En effet leur offre est belle et bien de proposer une couche de gestion en plus sur l'infrastructure qui permet de s'affranchir des questions posées plus haut et surtout d'une équipe d'administrateurs systèmes !
En ce qui nous concerne, depuis que nous sommes passé à Heroku, l'exploitation n'est plus devenu une source d'inquiétude. Nous sommes sereins quant il s'agit de déployer nos applications et nous pouvons nous consacrer sur notre coeur de métier, à savoir l'implémentation du produit en lui même. Et puis, comme nous allons le voir ensuite, les bonnes surprises avec Heroku ne se sont pas arrêtées là.
Auto-deploy, pipelines et review apps : pour des pratiques de développement top-notch
L’une des pratiques parmi les plus standards dans le développement logiciel est de créer un environnement dédié aux tests et à la recette, l'environnement de qualification ainsi qu’un environnement de production, qui comme son nom l’indique est dédié à la production.
Une autre pratique qui a vu le jour ces dernières années est le développement
par branches, suivant un git flow. L'idée est la suivante : une version de l'application est créée temporairement à chaque fois que l'on développe une nouvelle fonctionnalité à travers une « feature branch ». Ainsi, si N développeurs travaillent sur N fonctionnalités différentes, il va alors exister N versions de l'application qui vont coexister sur le gestionnaire de code source (Github). Le problème de ce développement par branches est qu’il complexifie le travail des équipes de testeurs (QA). En effet, il faut soit :
- un processus de gestion des environnements de tests au top, malheureusement il sera compliqué à mettre en place
- tester les développements directement sur le poste de développement, ce qui s'avèrera surement contre productif
- monopoliser l'unique environnement de qualification avec le déploiement d'une branche donnée, c'est ce ce qui est fait la plupart du temps et qui empêchera la QA d'être réalisé efficacement
Heroku a résolu ce problème en proposant une prise en charge globale du workflow de développement par branches grâce aux pipelines et aux reviews apps.
Les pipelines permettent de modéliser l’organisation des différents environnements : production, qualification ainsi que les différentes « review apps »
Couplé à Github, cette fonctionnalité est magique. Très concrètement, aujourd'hui, lorsqu’une fonctionnalité est prête, à chaque fois le processus est le même :
- Le développeur ouvre une « Pull Request » pour demander l'intégration de sa branche (et donc de sa fonctionnalité) dans la branche principale (et donc dans la version prête à déployer aux utilisateurs finaux)
- Heroku détecte la PR et déploie une application contenant la fonctionnalité
- En parallèle nos outils d'analyse statiques de code tels que Code Climate font une première passe pour vérifier d'éventuelles erreurs de code, suivi par les développeurs qui viennent faire une code review.
- Enfin l’équipe QA vient vérifier la conformité des développements par rapport aux spécifications grâce à la review app.
Limites réelles à l'utilisation d'Heroku et idées reçues
La plateforme exige que les applications suivent un cadre, les 12-Factor guidelines, pour s'exécuter correctement. Par exemple, le contenu de chaque container est supprimé à chaque déploiement, donc si vous devez sauvegarder des fichiers, il faudra donc utiliser des systèmes de stockage externes, comme Amazon S3. Comme côté positif, ce cadre a souvent l'avantage d'obliger à mettre en place dès le début des pratiques qui permettent une très bonne scalabilité horizontale et rendent les applications peu dépendantes de leur environnement.
Ensuite, on peut reprocher aux dynos (le nom donné aux containers sur Heroku) d'avoir des spécifications un peu faiblardes et un manque de flexibilité. Il est clair que Heroku n'est pas fait pour héberger une application de traitements massifs. Pour autant, si votre application fonctionne correctement sur un dyno, il vous suffira de multiplier les dynos pour avoir une scalabilité horizontale.
Heroku a la réputation d'être cher, en particulier lorsque l'on le compare d'autres fournisseurs Cloud comme Google Cloud ou AWS. Il ne faut pas faire de raccourcis et baser la comparaison uniquement sur les spécifications techniques. Le pricing d'un dyno est à comparer à celui d'un VPS auquel il faut ajouter du temps humain dédié à les administrer. Lorsque l'on fait le calcul, on s'aperçoit qu'il est beaucoup plus lean d'utiliser des plateformes comme Heroku. Nos insistons beaucoup sur ce point auprès de nos clients start-ups.
Un limite plus à la marge (quoi que...?) concerne des technologies qui ont le vent en poupe comme Elixir. Elles fonctionnent très bien sur Heroku mais néanmoins elles ne tirent pas du tout avantage de certaines de leurs capacités intrinsèques, par exemple le déploiement à chaud. Pour le coup, il parait difficilement concevable de voir Heroku solutionner le problème tant il est fondamental et l'on peut facilement convenir de la frustration que cela provoque chez certains. Pour autant, encore une fois, cela n'empêche en rien de d'utiliser Heroku avec ces piles technologiques.
La manière choisie par Heroku pour adresser de nouvelles piles technologiques est d'ailleurs l'un de leurs gros point forts. La communauté peut contribuer en proposant des "buildpacks", semblable à ce qu'il est possible de faire avec Docker et ses Dockerfile.
Le dernier argument fréquemment opposé, en particulier par les administrateurs systèmes, est le fait que l'on perde en partie le contrôle... C'est vrai, c'est d'ailleurs ce que l'on recherche. Cet argument n'a en définitive pas de sens lorsque l'on prend du recul deux minutes et que l'on se pose les questions évoquées plus hauts.
Rester lean et se rappeler de ses véritables objectifs
La prochaine fois que vous vous posez la question de monter une machine pour faire tourner une de vos applications, ayez le réflexe de vous demander si vous ne faites pas une bêtise. A mon sens, peu de start-ups ont un intêret à internaliser l'administration système. Cette tâche n'apporte aucune valeur à la majorité des business.
De plus Heroku non seulement fera fonctionner d'une excellente manière votre application en lui apportant une garantie de runtime, des possibilités de scalabilité mais en plus Heroku vous permettra d'atteindre un niveau d'industrialisation de vos pratiques et de celles de vos équipes bien au delà de tout ce que vous pouvez mettre en place vous même.
