Guide simplifié des Twelve-Factor-Apps.
12-Factor-App est un ensemble de principes décrivant une manière de créer des logiciels de type Software-as-a-Service. (SaaS) qui, lorsqu'ils sont suivis, permettent de créer du code qui peut être publié de manière fiable, mis à l'échelle rapidement et maintenu de manière cohérente et prévisible.
Présentée en 2011 par les ingénieurs de Heroku, ces principes ont depuis lors influencé les pratiques de développement des applications web et mobiles jusqu'à ce jour.
Téléchargez l'aide mémoire du 12 Factor App
Qu'est ce qu'une application SaaS?
Sofware-as-a-Service (SaaS) est un modèle de livraison de logiciels basé sur le cloud qui permet aux utilisateurs d'accéder à une app via Internet. Avec le modèle SaaS, le logiciel est hébergé sur des serveurs d'un fournisseur cloud (Ex: AWS, Azure, Google Cloud, Heroku etc.), et mis a la disposition des utilisateurs via un navigateur web, applications mobiles et des APIs.
Puisque le logiciel est hébergé par un fournisseur cloud, l'utilisateur n'a pas à investir dans une infrastructure coûteuse pour utiliser le logiciel, ce qui réduit les coûts d'utilisation du logiciel.
Quelques exemple d'app SaaS populaires:
- Spotify
- Netflix
- Zoom
- etc.
Les Twelves Factors
1. La base de code
Le 1er facteur stipule que toute 12-Factor-App doit avoir une base de code unique qui est maintenue dans un système de contrôle de version.
La base de code inclu les sources de code, les fichiers de configuration, les scripts de maintenance etc. A partir de la base de code, on produit plusieurs deploys. Un deploy est une version exécutable de l'app qui être installée dans divers environnements (test, pré-production, production etc.).
La base de code facilite la collaboration entre les développeurs qui effectuent les mise a jour du code.
Des plateformes tels que Github, Gitlab ou Launchpad facilitent le support de ce facteur.
2. Les dépendances
Le 2eme facteur stipule que toute les librairies externes utilisées doivent être déclarées de façon explicite dans un fichier.
Ces librairies vont être chargées en mémoire lors de l'exécution de l'app, et vont aussi être parfaitement isolées pour éviter tout conflit avec d'autres apps. En d'autres termes, une 12-Factor-App ne doit jamais s'appuyer sur l'existence implicite des librairies à l'échelle du système.
Des outils tels que Maven (Java), npm (Javascript) ou pip (Python) permettent de gérer efficacement les librairies externes.
3. Configuration
Le 3eme facteur exige une stricte séparation entre la configuration et le code source.
Dans une 12-Factor-App, la configuration définit les paramètres d'exécution de l'app dans un environnement donné (Ex: les informations de connexion aux bases de données, les clés d'accès, URLs des APIs externes etc). D'un environnement à l'autre, la configuration de l'app est différente, mais pas le code source!
La configuration d'une 12-Factor-App peut être:
- soit dans de fichier à l'extérieur de l'app.
- soit dans des variables d'environnement du serveur qui héberge l'app.
4. Les Services de Suport
Le 4ème facteur stipule de traiter tous les service de support comme ressources externes.
Un service de support est un service qui est utilisé par l'app via le réseau lors de son fonctionnement normal. Cela inclut les bases de données (MySQL, MongoDB etc.), les APIs externes (AWS, Twitter, Google Map) etc.
En traitant ses services comme ressources externes, ça implique qu'ils peuvent être rapidement remplacés sans avoir à modifier le code source. Par exemple, si la base de données MySQL est endommagée, on crée une nouvelle instance de MySQL et reconfigure l'app pour utiliser la nouvelle instance.
Il important de noter que les informations de connection aux backing services doivent être maintenus dans la configuration de l'app
5. Build, Release and Run
Le 5ème facteur définit le processus de déploiement logiciel en 3 étapes: Build, Release et Run.
- Build: le code source est converti en un fichier exécutable qui inclut toutes les librairies externes.
- Release: le fichier exécutable est combiné avec une configuration pour générer une version prête pour exécution dans un environnement donné.
- Run: La version de l'app est installée dans un environnement et disponible pour utilisation par les usagers.
Des outils tel que Jenkins, Github Actions permettent d'automatiser le processus de Build-Release-Run.
6. Les Processus
Le 6ème facteur stipule que l'app est composée d'un ou plusieurs processus stateless indépendants.
Un processus stateless est un processus qui ne stocke aucune donnée localement (ni en mémoire, ni dans son disque). Pour stocker les données, il utilise plutôt un service de support (Ex: bases de données, cache, queues de message).
Les types de processus que l'on retrouve dans les 12-Factor-App sont:
- Les processus web qui gèrent les requêtes web des clients
- Les processus périodique qui sont lancés par une horloge (Ex: cron jobs)
- Le processus qui consomment les évènement asynchrones (Ex: de queues de messages)
- Les processus administratifs qui effectuent des tâches de maintenance.
7. Les Ports
Le 7ème facteur stipule que une app doit être identifiée par son numéro de port réseau, et non par son nom de domaine.
La raison est que dans les environnements cloud, les noms de domaines et IPs des serveurs sont attribués à la volée de façon aléatoire. Alors il est plus simple d'exposer une app via un port. Par exemple, une app web va être accessible via les port 80 (http) ou 443 (https)
8. Concurrence
Le 8ème facteur stipule que l'on augmente la capacité d'une app en dupliquant ses processus.
Par exemple, si le trafic de l'app triple entre 8h00 et 18h00:
- On va augmenter le processus web de 1 à 3 instances de 8h00 à 18h00, et réduire à 1 après 18h00.
- Par contre, le processus qui envoie les statistiques tous les jours a minuit n'aura pas besoin d'être redimensionné.
9. Disposability
Le 9ème facteur recommande que l'app supporte des démarrages rapide et un arrêt en douceur, afin d'augmenter sa robustesse.
Cela permet des déploiements et une mise à l'échelle élastiques et rapides.
10. Dev/Prod Parity
Le 10ème facteur stipule de maintenir les environnements (dev, test et production) le plus similaire possible.
Ceci est important pour s'assurer que tous les bogues peuvent être identifiés lors du développement et des tests plutôt que lorsque l'application est mise en production. Cela permet d'éliminer l'énoncé des développeur stéréotypé : "Ça fonctionnait sur mon ordinateur"
11. Logs
Le 11ème facteur stipule que les logs applicatifs doivent être considérés comme un journal d'évènements.
Logging est une activité importante qui permet de valider le comportement de l'app lors de son exécution. L'app produit le contenu des logs, mais l'archivage et stockage des logs est délégué a un service externe, idéalement fourni par le fournisseur de Cloud.
Ces services externes offrent généralement des outils de recherche et visualisation les évènements de logs. Ces outils sont très importants lors des investigations de bogues et problèmes en environnement de production.
12. Admin Processes
Le 12ème facteur stipule que les applications doivent exécuter des tâches de gestion ou d'administration dans un environnement identique à celui des processus réguliers de l'application.
Conclusion
Les principes de 12 Factor App sont conçus pour permettre aux développeurs de créer des applications flexibles, modulaires et robustes destinées à s'exécuter à l'échelle du Web. Ils peuvent sembler complexes au premier abord, et à bien des égards, ils le sont. Repenser la nature même de la façon dont vous créez un logiciel peut être une tâche ardue.
Liens
Si vous avez aimé l'article, montrez votre soutien avec un ❤️ et abonnez vous a mon blog! Votre engagement m’inspire!
