Manifeste 12 factor app

_{Home >> Cloud Computing >> Manifeste 12 factor app}

Elasticité, scalabilité, volatilité, microservices… sont autant de sujets à maîtriser pour tirer parti des avantages apportés par le cloud. Pour fonctionner de façon optimale dans le cloud, les applications doivent, avant tout, être architecturées correctement. Le manifeste 12 factor app de Adam Wiggins propose 12 bonnes pratiques pour la conception d’applications. Ce manifeste s’applique à tous les langages et toutes les plateformes (qu’elles soient cloud ou legacy).

1. Codebase

Un repository unique pour plusieurs déploiements

Un repository (repo) est un dépôt de code versionné à partir duquel on peut construire des releases immutables qui seront déployées dans différents environnements d’exécution. Tout le code doit se trouver à un seul emplacement centralisé et versionné, le gestionnaire de code. Un dépôt de code est à l’origine de plusieurs déploiements, et un déploiement ne doit pas être lié à plusieurs dépôts de code. Dans le cas où du code serait commun à plusieurs applications, alors celui-ci doit être factorisé puis extrait sous forme de librairie.

2. Dependencies

Déclarez explicitement les dépendances et isolez-les

Une application 12-factor suppose qu’il n’y a pas de dépendances système (packages) pendant son déploiement. Pour fonctionner correctement, il faut déployer l’application avec ses dépendances. Elles forment ainsi un « tout », une sorte de bundle. Il faut déclarer les dépendances de façon explicite en amont de la construction, et isoler ces dépendances au moment de l’exécution.

3. Config

Stockez la configuration hors du code applicatif

Un code donné doit pouvoir fonctionner dans tous les environnements sans aucune modification. Toutes les variables de configuration doivent être être stockées dans des fichiers adjoints. Exemple de variables de configuration : l’url d’un serveur SMTP, d’une base de données, les identifiants pour se connecter à une API…

4. Backing Services

Traitez les services externes comme des ressources attachables et détachables

Tout comme la configuration, les services externes doivent être gérés en dehors du code de l’application. L’idée est de pouvoir attacher et détacher une ressource externe à tout moment. Si un des services externes est défaillant, on modifie simplement la ressource au niveau du fichier de configuration, sans toucher au code applicatif.

5. Build, Release, Run

Séparez strictement les étapes d’assemblage et d’exécution

A partir d’une base de code, vous produisez un artifact auquel vous adossez des éléments de configuration externes qui produisent une release immutable, prévue pour être déployée dans environnement d’exécution. L’objectif de la séparation des phases de build et d’execution est de maximiser la capacité de livraison. Il est donc important de mettre en place de pipelines de CI/CD, de versionner et d’archiver chaque release.

6. Processes

Exécutez l’application comme un ou plusieurs processus stateless

Un état ne doit pas être maintenu par votre application. Chaque processus est ‘stateless’ c’est à dire qu’il ne fait aucune supposition sur le contenu de la mémoire avant de traiter une requête, ni sur son contenu après la requête. Si un de ces processus a besoin de stocker de la donnée, cela doit se faire via un service externe. En effet, les données produites par les processus sont souvent volatiles (mises en cache ou écrites sur le disque temporairement).

7. Port Binding

Exposez les services via des associations de ports

Une application 12 factor doit être auto-suffisante. Elle ne doit pas se baser sur l’injection d’un serveur web au moment de l’exécution. L’application et son exposition sont deux choses distinctes. L’application expose le port, généralement http, Et le cloud provider prend en charge l’assignation du port et le mapping avec l’extérieur. L’exposition est la couche d’abstraction de l’application qui est visitée par les clients.

8. Concurrency

Gérez votre scalabilité horizontale (scale out) en découpant vos services

Pour tenir la charge, on multiplie les processus mettre à l’échelle une application, il faut créer plus de processus afin de tenir la charge. On utilise différents types de processus pour différents types de tâches. L’avantage considérable de scalabilité horizontale sont les performances versus le coût. Le scale out, permet une croissance quasi-linéaire en termes de coûts et de demandes traitées (à condition que l’application soit conçue pour cette stratégie de croissance). Un autre avantage évident est la tolérance aux pannes. Une défaillance de processus ne paralysera pas l’application. Enfin, la parallélisation offre une application plus rapide et réactive. La possibilité de différer le traitement du thread principal signifie que le serveur web n’a pas besoin d’attendre que les actions de fond se terminent avant d’envoyer la réponse HTTP au client.

9. Disposability

Maximisez la robustesse avec des démarrages rapides et des arrêts gracieux

Dans le Cloud, les processus sont perçus comme volatiles et jetables, ils peuvent être démarrés ou stoppés à tout moment. Les processus doivent donc être prêts à l’emploi rapidement : s’ils sont lancés pour des besoins de montée en charge, il est important d’être opérationnel rapidement pour éviter la saturation des instances en cours (ou le déni si aucune ne fonctionne). En complément, les développeurs doivent prévoir des arrêts gracieux, c’est-à-dire prévoir les cas où l’application est en train d’être déconnectée ou est en train de crasher : il est préférable d’intercepter ces signaux pour que le travail en cours soit renvoyé dans une file de travaux, afin de ne pas corrompre des données.

10. Dev / Prod Parity

Gardez le développement, la validation et la production aussi proches que possible

L’idée de ce principe, est de réduire au maximum le fossé entre le développement et la production. En terme de temps comme en terme de collaboration d’équipes. Développement continu. Les grandes lignes directrices sont de faire en sorte qu’une modification de code puisse être rapidement envoyée en production, que les personnes impliquées dans le développement le soient aussi dans le déploiement, et enfin que les outils utilisés dans les deux contextes soient le plus proche possible. C’est d’ailleurs très lié aux principes DevOps.

11. Logs

Traitez les logs comme des flux

Les logs sont des flux d’événements qui retracent le comportement d’une application. Un événement est une ligne de texte brute et qui est datée. L’application doit générer des événements sur sa sortie standard et se décharger de toute la phase de stockage des logs. Cela permet de centrer le code de l’application sur son cœur de métier.

12. Admin Processes

Lancez les processus d’administration et de maintenance comme des one-off-processes

Les processus d’administration (migration base de données, scripts de mise à jour…) doivent être des opérations ponctuelles et uniques, et ils doivent être exécutés dans le même environnement que celui de l’application. Le code implémentant ces opérations doit être livré avec le code de l’application afin d’éviter les problèmes de synchronisation.