L’écriture de code d’application est antérieure à la plupart des solutions cloud — des solutions que la plupart des programmeurs d’applications écrivent spécifiquement pour ces jours-ci.

Pour gérer cette dissonance, la méthodologie de l’application à 12 facteurs a vu le jour. Les 12 facteurs sont une approche qui aide les programmeurs à écrire des applications modernes de manière déclarative, en utilisant des contrats clairs déployés via le cloud.

Dans cet article, je vais présenter la méthodologie de l’application à 12 facteurs et offrir un résumé de haut niveau de ses principes.

Quelle est la méthodologie de l’application à 12 facteurs ?

En 2012, les programmeurs de Heroku ont lancé la méthodologie de l’application à 12 facteurs. Ces programmeurs ont développé et déployé des centaines d’applications qui ont écrit cette méthodologie, en s’appuyant sur leur expérience de voir des applications SaaS « dans la nature”.

Ce groupe considère la méthodologie comme une triangulation de:

• Pratiques idéales pour soutenir le développement d’applications
• La dynamique qui se produit à mesure qu’une application se développe organiquement
• La relation et la collaboration entre les développeurs de bases de code

Leurs objectifs sont doubles:

• Pour aider à éviter les coûts d’érosion logicielle
• Pour sensibiliser aux problèmes systémiques qu’ils ont observés dans le développement d’applications modernes

Le groupe pointe vers deux sources d’inspiration, les modèles d’architecture d’applications d’entreprise et le Refactoring, tous deux par le développeur professionnel Martin Fowler.

Et maintenant, je vais présenter chacun des 12 facteurs.

Principe I. Base de code

« Une base de code suivie dans le contrôle de révision, de nombreux déploiements”

Votre base de code doit avoir un système de contrôle de version logique facile à comprendre.

Chaque déploiement doit avoir son propre référentiel de code qui peut être déployé dans plusieurs environnements. Évitez d’héberger plusieurs applications dans le même référentiel. Cela rend le contrôle de version presque impossible à comprendre et les versions s’emmêlent, ce qui entraîne un travail sans valeur ajoutée.

Principe II. Dépendances

« Déclarer et isoler explicitement les dépendances »

Ce principe maintient que vous ne devez jamais vous fier à l’existence implicite de paquets à l’échelle du système. Au lieu de cela ”

• Assurez-vous que les bibliothèques spécifiques à l’application sont disponibles
• Vérifiez que les bibliothèques système nécessaires, telles que curl ou ImageMagick, sont disponibles. (Il n’y a aucune garantie que ceux-ci existent sur tous les systèmes sur lesquels l’application pourrait fonctionner à l’avenir.)

Dans l’ensemble, une application à 12 facteurs doit être autonome. L’application doit être suffisamment isolée pour éviter les interactions avec des bibliothèques en conflit installées sur la machine hôte.

Regardons un exemple. En Python, vous pouvez réaliser une déclaration et une isolation en utilisant respectivement Pip et Virtualenv. Pour satisfaire à ce principe, vous devez toujours utiliser à la fois la déclaration de dépendance et l’isolement. Gérez les dépendances au sein de l’application, pas à partir d’une source externe. Les dépendances doivent être hébergées dans un référentiel de l’application

Principe III. Config

« Stocker la configuration dans l’environnement »

Une application et sa configuration doivent être complètement indépendantes. De plus, le stockage constant des configurations dans le code doit être entièrement évité.

Vos configurations doivent avoir un fichier séparé et ne doivent pas être hébergées dans le référentiel de code. Un fichier de configuration séparé facilite la mise à jour des valeurs de configuration sans toucher à la base de code réelle, éliminant ainsi le besoin de redéployer vos applications lorsque vous modifiez certaines valeurs de configuration.

Lorsque les configurations se trouvent dans l’environnement, et non dans l’application, en tant que variables, vous pouvez facilement les déplacer vers un autre environnement sans toucher au code source. Les applications à douze facteurs stockent les configurations en tant que variables de sorte qu’il est « peu probable qu’elles soient vérifiées accidentellement dans le référentiel”. Autre bonus : vos configurations sont alors indépendantes de la langue et du système d’exploitation.

Principe IV. Services de support

 » Traiter les services de support comme des ressources jointes »

Dans une application à 12 facteurs, tous les services qui ne prennent pas en charge l’application principale doivent être accessibles en tant que service. Ces services essentiels non essentiels peuvent inclure :

• Bases de données
• Stockage externe
• Files d’attente de messages
• Etc.

Ceux-ci peuvent être traités comme une ressource. Ceux-ci doivent être accessibles en tant que service via HTTP ou une requête similaire, puis spécifiés dans la configuration. De cette façon, la source du service peut être modifiée sans affecter le code de base de l’application.

Par exemple, une application qui utilise un système de file d’attente de messages est préférable si elle peut facilement passer de RabbitMQ à ZeroMQ en ActiveMQ en modifiant uniquement les informations de configuration.

Principe V. Build, release, run

« Étapes de construction et d’exécution strictement séparées »

Une application à 12 facteurs est stricte quant à la séparation des trois étapes de construction, de libération et d’exécution.

Démarrez le processus de génération en stockant l’application dans le contrôle de source, puis créez ses dépendances. Séparer les informations de configuration signifie que vous pouvez les combiner avec la construction pour l’étape de publication — et ensuite elles sont prêtes pour l’étape d’exécution. Il est également important que chaque version ait un identifiant unique.

Principe VI.Processes

 » Exécuter l’application comme un ou plusieurs processus sans état »

Stockez toutes les données nécessaires pour persister dans un service de sauvegarde avec état, telles que les bases de données. L’idée est que le processus est apatride et ne partage absolument rien.

Alors que de nombreux développeurs sont habitués aux « sessions collantes », stocker des informations dans la session en attendant que la prochaine requête provienne du même service contredit cette méthodologie.

Principe VII. Principe de liaison de port

 » Services d’exportation via liaison de port « 

Les applications à 12 facteurs doivent toujours être indépendantes des applications supplémentaires. Chaque fonction doit être son propre processus – en isolement complet.

Dans un environnement traditionnel, nous supposons que différents processus gèrent différentes fonctionnalités. En tant que tel, il est facile de supposer que ces fonctionnalités sont disponibles via un protocole Web, tel que HTTP, ce qui rend probable que les applications s’exécutent derrière des serveurs Web, comme Apache ou Tomcat. Mais cela va à l’encontre de la méthodologie à 12 facteurs.

Ajoutez plutôt une bibliothèque de serveur Web ou similaire à l’application principale. Cela signifie que l’application peut attendre des demandes sur un port défini, qu’il s’agisse de HTTP ou d’un protocole différent.

Principe VIII.Concurrence

”Mise à l’échelle via le modèle de processus »

Une véritable application à 12 facteurs est conçue pour la mise à l’échelle. Créez vos applications pour que la mise à l’échelle dans le cloud soit transparente. Lorsque vous développez l’application pour qu’elle soit concurrente, vous pouvez créer de nouvelles instances dans le cloud sans effort.

Afin d’ajouter plus de capacité (démarrer des processus supplémentaires sur des machines supplémentaires), votre application devrait pouvoir ajouter plus d’instances au lieu de plus de mémoire ou de CPU sur la machine locale.

Principe IX. Disposabilité

« Maximiser la robustesse avec un démarrage rapide et un arrêt gracieux »

Le concept de processus jetables signifie qu’une application peut mourir à tout moment, mais cela n’affectera pas l’utilisateur — l’application peut être remplacée par d’autres applications, ou elle peut redémarrer. La mise à disposition de votre application garantit que l’application s’arrête gracieusement: elle doit nettoyer toutes les ressources utilisées et s’arrêter en douceur.

Lorsqu’elle est conçue de cette façon, l’application revient rapidement. De même, lorsque les processus se terminent, ils doivent terminer leur demande actuelle, refuser toute demande entrante et quitter.

Principe X. Parité Dev/prod

 » Gardez le développement, la mise en scène et la production aussi similaires que possible ”

Les applications déployées pour le développement et la production doivent avoir une parité. Essentiellement, il ne devrait y avoir que la moindre différence entre les deux déploiements.

Une grande différence peut entraîner des problèmes de compatibilité involontaires entre le code de développement et le code de production. Lors de la création d’une application à 12 facteurs, les services de sauvegarde entre dev et prod doivent être les mêmes; une différence ici pourrait causer des problèmes importants sur toute la ligne.

Principe XI.Logs

« Traiter les journaux comme des flux d’événements »

Contrairement aux applications monolithiques et traditionnelles qui stockent des informations de journal dans un fichier, ce principe maintient que vous devez diffuser les journaux vers un emplacement choisi — pas simplement les vider dans un fichier journal.

En règle générale, les journaux ne résident pas au même endroit dans les environnements basés sur le cloud après chaque gravure. Lorsque de nouveaux processus démarrent ou que votre application se bloque, les journaux seront distribués sur plusieurs machines cloud ; ils ne seront pas assis sur une seule machine ou hôte.

Résolvez ce problème en nommant un endroit commun pour les journaux à diffuser. Dans certains cas, vous pouvez simplement rediriger la sortie standard vers un fichier. Plus probablement, cependant, vous voudrez déployer un routeur de journaux comme Fluentd et enregistrer les journaux sur Hadoop ou un service spécifique, comme Splunk.

Principe XII.Processus d’administration

 » Exécuter les tâches d’administration / de gestion en tant que processus uniques”

Le principe final de l’application à 12 facteurs propose de séparer les tâches administratives du reste de votre application. Ces tâches peuvent inclure la migration d’une base de données ou l’inspection des enregistrements.

Bien que les processus d’administration soient séparés, vous devez continuer à les exécuter dans le même environnement et avec le code de base et la configuration de l’application elle-même. L’envoi du code des tâches d’administration à côté de l’application empêche la dérive.

Lecture connexe

• Blog BMC DevOps
• Agile vs Waterfall SDLC : Quelle Est La Différence ?
• Pipelines de Déploiement (CI/CD) en Génie Logiciel
• Qu’Est-Ce que La Programmation Extrême (XP) ?
• Comment &Pourquoi Devenir une Usine de logiciels
• Meilleures Conférences pour la Programmation&Développement de logiciels