Avez-vous déjà entendu parler des 12 facteurs ?

Non, ce n’est pas La Poste qui optimise sa distribution de courrier. Il s’agit d’un ensemble de recommandations de développement pour faire une application cloud native.
Les 12 facteurs ont été pensés dès 2012 par une équipe d’Heroku. Ils ont synthétisé les problèmes qu’ils ont pu rencontrer durant leur activité. Personnellement, j’en ai entendu parler très tardivement, et comme les devs autour de moi ne connaissaient pas non plus, je me suis dit qu’il vaut mieux tard que jamais, et hop, un petit article.

L’intégralité du texte se trouve ici : https://12factor.net
Mais pour les bichons pressés que vous êtes, voyons en quelques phrases en quoi cela consiste (je vous préviens, certains points pourront vous sembler triviaux) :

1. Base de code

Le code source d’une application doit toujours être suivi dans un système de contrôle de version.

Une application ne doit pas être basée sur plusieurs base de code source. Sinon, on a affaire à plusieurs applications (une par base de code, à laquelle on peut appliquer les principes des 12 facteurs)

Si du code est en commun, il faut en extraire une librairie.

2. Dépendances

Pas de supposition sur l’existence de dépendance sur le système hôte de votre logiciels. Une dépendance peut désigner une librairie ou un programme de l’OS hote (curl par exemple).
Toutes les dépendances doivent être déclarées dans un manifeste de déclaration de dépendances.

Un outil d’isolation de dépendance doit être utilisé (pour faire simple, il faut empaqueter son code, dans un jar en java par exemple).
Si votre app a besoin d’outils externes, distribuez les avec l’app.

3. Configuration

Pas de stockage de conf directement dans le code => la conf peut varier selon la cible du déploiement, pas le code.
« Les applications 12 facteurs stockent la configuration dans des variables d’environnement »,
ce qui est préférable à l’utilisation de fichiers de configuration (ces derniers pouvant être commités par inadvertance).
Vous appliquez correctement le concept si vous pouvez rendre votre application open-source à tout instant, sans compromettre d’identifiants.

4. Services externes

Une app 12 facteurs ne différencie pas les services locaux (bdd, broker etc) des services externes (gérés par des tiers, google maps, binance api etc)
Pour l’app, les deux types de services sont accessibles via une url (ou autre).
Une modif d’un service doit pouvoir se faire sans impact sur l’application : exemple, passer d’un service mysql local à une base dans le cloud.
Simplement, les services sont des ressources qui doivent être faiblement couplés à l’application pour faciliter leur changement.

5. Assemblez, publiez, exécutez

Séparation stricte entre les différentes étapes d’assemblage et de publication
L’assemblage est la phase dite de « build »
L’étape de publication est la « release », combinée à la configuration, elle est prête pour une exécution immédiate dans l’environnement cible.
Chaque release devrait être horodaté. Tout changement doit créer une nouvelle release (interdiction de modifier manuellement une release).

6. Processus

L’app est exécutée comme un ou plusieurs processus sans état.
Les processus ne partagent rien entre eux (Shared-nothing architecture)
Concernant le cache, pas de supposition qu’une donnée doit se trouver dans le cache.
On doit supposer qu’à tout moment, un redémarrage du processus supprime le cache (exemple avec kubernetes).
En environnement web, les sessions persistantes sont une violation des applications 12 facteurs. Il faut privilégier un datastore (ex : redis)

7. Associations de ports

Une app 12 facteurs est « auto contenue ». Si elle a besoin d’un serveur pour s’exécuter, elle embarque ce serveur (sf spring boot par exemple).
On ne doit pas supposer qu’un serveur web va être à disposition dans l’environnement d’exécution.
L’app écoute sur un port et doit réagir aux requêtes qui arrivent sur ce port.

8. Concurrence :

Les processus de votre application doivent s’inspirer du modèle de processus unix. A savoir utiliser un nommage des processus par type de charge.
Voir https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/
Les processus des applications 12 facteurs ne devraient jamais être des daemons ou écrire des fichiers PID.
Il faut utiliser le gestionnaire de processus du système d’exploitation pour gérer les flux de sortie, répondre à un processus qui plante, et gérer les redémarrages et les arrêts initiés par les utilisateurs.

9. Jetable

Les processus doivent être très rapide au démarrage. Toujours dans le but d’optimiser la gestion par un gestionnaire de processus.

Les processus doivent s’éteindre proprement :

Un processus web doit d’abord arrêter d’écouter sur son port, terminer son travail et s’arrêter

En règle générale, les verrous doivent être levés, les tâches terminées, et les ressources libérées (fichiers par exemple)

Pour finir, un processus doit être robuste en ce qui concerne une « mort subite » (plantage matériel par exemple).

10. Parité dev/prod

Le déploiement continu est là pour régler différentes problématiques :

  • réduction du temps entre le codage et le déploiement en production
  • les devs sont impliqués dans le processus de mise en production
  • régler le fossé entre l’environnement de dev et l’environnement de production

Les développeurs ne doivent pas céder à la tentation de coder sur un environnement « allégé » par rapport à la prod, sous peine de passer à côté de bug.

11. Logs

Ce n’est pas à l’application de s’occuper de gérer les logs qu’elle produit. Chaque processus écrit vers la sortie standard (stdout).

C’est le rôle d’un routeur de logs de diriger, stocker et gérer les logs produits par l’app.

Les logs devraient être envoyés vers un outil d’indexation, afin de pouvoir d’une part les centraliser, et d’autre part les utiliser efficacement (recherche, alertes etc)

(Note perso : filebeat-logstash-kibana font des merveilles à ce sujet)

12. Processus d’administration

Pour administrer votre app, vous allez être amené à exécuter du code d’administration (par le biais de script pour par exemple migrer une base de données). Ces processus doivent être exécutés dans le même environnement d’exécution que l’application, que ce soit en dev ou en prod.

Le code d’administration doit être livré avec le code source de l’application, et donc dépend directement de la version de ce code source.

Partager sur les réseaux