Chez Dernier Cri, nous avons pour principe de délivrer des apps as-a-service performantes et scalables. Pour cela, nous nous basons sur la méthodologie 12factors qui nous permet de garantir à nos clients de livrer des applications de qualité.

Historiquement, la méthodologie 12 factor a été mise au point par des ingénieurs de Heroku, le fameux PaaS américain en 2011 (que nous avons beaucoup utilisé avant de passer sur des PaaS français comme Scalingo ou Clever Cloud). Basé sur l'analyse de milliers d'applications, ces développeurs ont peu à peu synthétisé leurs observations dans une approche autour de 12 points qui selon eux, hormis le code de l'application lui-même, doivent être respectés pour permettre de construire une application résiliente et scalable capable de fonctionner dans le cloud.  

Voici en détail les 12 points de la méthodologie et comment nous les adressons chez Dernier Cri :

Facteur 1 : la base de code

Le premier facteur souligne l'importance d'une seule base de code (ou codebase en anglais) pour une application, versionnée avec un système de contrôle de version, comme Git. Plusieurs déploiements peuvent être issus de la même base de code, mais il est important de les garder sous le même dépôt pour assurer la cohérence et la maintenabilité.

💡 Chez Dernier Cri, nous utilisons :

• Github.com

Facteur 2 : les dépendances

Une application ne devrait pas dépendre de librairies, de package ou de module système (ex: GD ou Curl). Même si la plupart des systèmes proposent ces outils, ils peuvent ne pas avoir la bonne version ou configuration. Ce qui rendrait l'application instable.

💡 Chez Dernier Cri, nous utilisons :  

• Composer (php)
• RubyGem (ruby)
• Package.json + npm/yarn (nodejs/javascript/typescript)

Facteur 3 : la configuration

Différentes informations sont utiles pour faire fonctionner une application, comme l'accès à la base de données, ou le chemin de stockage des images par exemple. Il faut stocker ces informations dans des variables d'Environnement. Cela permet de déployer facilement l'application dans différents environnements sans modifier le code source.

💡 Chez Dernier Cri, nous utilisons :  

• Des fichiers .env.${environnement}‍
• Dotenv
• toute autre ressource nécessaire à la configuration

Facteur 4 : les services externes

Tous les services utilisés à travers le réseau par l'application sont considérés comme des services externes qui doivent être attachés ou détachés à la demande. Typiquement, la base de données est considérée comme service externe, tout comme les services tiers (monitoring, paiement, backup, etc...). Ces services sont reliés à l'application au moment du déploiement.

💡 Chez Dernier Cri, nous utilisons :  

• S3 (ou équivalent) pour le stockage de fichiers
• Add-ons : base de données, redis, smtp, MQTT, Pusher (websocket)

Facteur 5 : Assembler, publier, exécuter

Il est important de distinguer 3 étapes au moment du déploiement :

• L'assemblage du code (build) : à cette étape on va récupérer le code source de toutes les dépendances externes, compresser certains assets, compiler les fichiers binaires, etc...  
• La publication (release) : à cette étape, on va ajouter à la résultante de l'étape précédente les configurations spécifiques à l'environnement sur lequel sera exécuté le build.
• L'éxecution (runtime) : c'est à cette étape que l'application sera concrètement utilisée par nos utilisateurs.

💡 Chez Dernier Cri, nous utilisons :  

• Github Actions

Facteur 6 : le processus

Le processus qui fait fonctionner notre application (runtime) et la base de code elle-même ne doivent pas avoir connaissance de l'état à un moment précis de notre app. On dit que l'application est Stateless. Les informations relatives à l'état (login, session, données formulaire inscription, etc...) doivent être stockées ailleurs (base de donnée, fichiers, etc...).

💡 Chez Dernier Cri, nous utilisons :  

• Redis / Memcache
• BDD
• Redux pour React

7. Portabilité

Une application 12factors est auto-contenue. Lorsqu'elle s'exécute, c'est à elle d'exposer ses ports d'entrée-sortie pour communiquer avec l'extérieur. On peut exposer tout types de services comme HTTP, mais aussi Redis, XMPP, MQTT, Websocket...

Utilisez des technologies telles que Docker et Kubernetes pour faciliter la portabilité et la gestion de l'infrastructure.

💡 Chez Dernier Cri, nous utilisons :  

• Docker
• K8
• Amazon ECS
• des PaaS

Nos PaaS fournissent un environnement d'exécution qui embarque le serveur et expose les ports vers les load balancer, par exemple.

Facteur 8 : la concurrence

Chaque processus qui exécute notre application lorsqu'une requête arrive est sans état par défaut. Ceci nous permet de lancer plusieurs processus en concurrence, par exemple lorsque le traffic augmente.

💡 Chez Dernier Cri, nous utilisons :

• le scaling Horizontal & Vertical

Facteur 9 : la disposabilité

Les processus doivent être considérés comme jetables, ils peuvent être démarrés, stoppés, et supprimés à la demande sans affecter le fonctionnement de notre application.

Il faudra cependant optimiser les temps de démarrage et d'arrêt pour rendre notre application plus résiliente.  

💡 Chez Dernier Cri, nous utilisons :

• Kubernetes
• Docker
• Supervisor
• PaaS (Scalingo, Clever Cloud, ...)

Facteur 10 : la parité entre les environnements

Le dixième facteur des 12 facteurs souligne l'importance de maintenir la parité entre les environnements de développement, de test et de production. Cela signifie que les différences entre ces environnements doivent être minimisées autant que possible pour éviter les problèmes liés aux différences de configuration, de dépendances ou de versions de services externes.

Pour maintenir la parité entre les environnements, les équipes de développement doivent :

• Utiliser les mêmes services et versions dans tous les environnements,
• Automatiser le processus de déploiement pour garantir une configuration cohérente,
• Utiliser des outils de conteneurisation et d'orchestration, tels que Docker et Kubernetes, pour faciliter la gestion et la réplication des environnements,
• Favoriser un retour rapide sur les changements en déployant fréquemment et en intégrant les retours d'expérience des utilisateurs et des tests.

💡 Chez Dernier Cri, nous utilisons :

• Docker
• Github Actions

Facteur 11 : les logs

Les logs ou journaux sont essentiels pour surveiller les performances, détecter les problèmes et assurer la sécurité de l'application. Les 12 facteurs recommandent de traiter les journaux comme des flux d'événements et de les stocker sur un système de stockage externe pour une analyse ultérieure.

Voici quelques bonnes pratiques pour la gestion des journaux :

• Utiliser un format standard pour les messages de journal, comme JSON, pour faciliter la recherche et l'analyse
• Ne pas stocker les journaux directement sur les serveurs de l'application pour éviter les problèmes de performances et de sécurité
• Utiliser des outils de surveillance et d'analyse des journaux, tels que ELK Stack (Elasticsearch, Logstash, Kibana) ou Splunk, pour centraliser, analyser et visualiser les journaux
• Configurer des alertes pour être informé en cas de problèmes critiques détectés dans les journaux

💡 Chez Dernier Cri, nous utilisons :

• Amazon Cloudwatch
• Sentry
• Papertrail

Facteur 12 : le processus d’administration

Le dernier facteur porte sur la gestion des tâches administratives et de maintenance qui doivent être effectuées sur l'application. Ces tâches peuvent inclure des migrations de bases de données, l'exécution de scripts ponctuels, ou la génération de rapports. Les 12 facteurs recommandent d'exécuter ces tâches dans le même environnement que l'application, en utilisant les mêmes outils et processus.

💡 Chez Dernier Cri nous utilisons :

• Sidekiq (Ruby)
• Background Queues (Laravel - php)