Shadow IT – Comment gérer ?

Shadow IT – Comment gérer ?

Le Shadow IT, aussi appelé Rogue IT, est un phénomène de plus en plus présent au sein des entreprises. Mais savons-nous vraiment ce qu’est le « Shadow IT » ? Par le passé il était le fruit de l’impatience d’un employé souhaitant accéder rapidement à un logiciel ou à...

12-factor-app

12-factor App : une excellente base de développement applicatif

14 Fév, 2022 | Dev & Data Sciences | 0 commentaires

Le “12 Factor app” c’est quoi ?

Le “12 Factor app” est un manifeste proposant 12 bonnes pratiques concernant le développement d’applications Cloud. Il a été écrit en 2012, par Adam Wiggins, co-fondateur d’Heroku, un éditeur d’outils permettant le déploiement applicatif web en mode PaaS.

Ces directives sont importantes et pertinentes pour concevoir une architecture d’application évolutive pouvant être publiée de manière fiable, mise à l’échelle rapidement et maintenue de manière cohérente et prévisible. Le « 12 factor app » identifie les erreurs courantes et les points de vigilance concernant l’architecture, le déploiement et l’exploitation d’une application.

Ce processus peut être utilisé avec n’importe quel langage de programmation et n’importe quelle combinaison de services externes. Les applications respectant ces préconisations offrent une portabilité maximale et peuvent évoluer sans modifications importantes. Les divergences entre le développement et la production sont réduites au minimum, d’où une agilité maximale.

Bien que certains facteurs puissent sembler évidents pour les développeurs aujourd’hui, l’intérêt de développer des applications qui adhèrent aux meilleures pratiques continue de croître avec la généralisation des architectures micro-services.

 

Nous allons parcourir ces 12 bonnes pratiques à suivre lors de la création d’une application :

  1. Base de code (Codebase)

Une base de code suivie avec un système de contrôle de version, plusieurs déploiements.

Utiliser UNE seule base de code versionnée par application même lors de la création d’applications multiplateformes. Ce principe peut aussi être appelé « Single source of truth ».

 

  1. Dépendances (dependencies)

Déclarez explicitement et isolez les dépendances.

Une application ne doit pas supposer l’existence de dépendances sur une plate-forme pour être exécutable. Des outils comme Maven, Gradle ou NPM facilitent ce travail de déclaration. De manière plus globale, cette préconisation est aujourd’hui généralisée par l’utilisation de containers pour les déploiements. Cela évite les conflits entre différentes applications qui s’exécutent sur le même hôte, mais nécessitent des dépendances différentes.

 

  1. Configuration (config)

Stockez la configuration dans l’environnement.

Aujourd’hui, la pratique la plus courante consiste à utiliser des variables d’environnement pour définir le contexte d’exécution d’une application. Ainsi la configuration (connexion à la base de données, identifiants, paramètres spécifiques…) est injectée dans les applications en fonctions du contexte. Le but est de ne packager l’application qu’une seule fois et de la déployer de multiple fois.

Attention toutefois, certains paramètres de configuration n’ont pas à être externalisés de la sorte. Posez-vous une question simple : « La modification de ce paramètre nécessite-t-il un re-packaging de l’application ? ». Parfois la réponse est « oui ». 

 

  1. Services externes (Backing services)

Traitez les services externes comme des ressources attachées.

Une application Cloud utilise et dépend de services externes : base de données, serveur de mail, système de fichiers… Un corollaire du principe précédent implique que toute la configuration permettant d’accéder à ces ressources doit être séparée du code. On peut compléter en disant que l’ensemble de ces dépendances doivent être attachées ou détachées à la demande afin de gérer des problèmes de défaillance par exemple.

 

  1. Build, release, run (CI/CD)

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

Intégrer des divisions strictes entre les étapes de construction, de lancement et d’exécution de son développement. Ces trois étapes transforment la base de code en un déploiement. Il est recommandé de suivre les étapes suivantes :

  • L’étape « build » utilise le code et ses dépendances pour produire un artefact
  • L’étape « release » met cet artefact et la configuration associée à disposition sur l’environnement cible
  • L’étape « run » exécute une ou plusieurs instances de la version

Les systèmes d’intégration continue et de CD modernes aident à respecter ce principe. Il est important de versionner chaque release afin de pouvoir garantir une maitrise des déploiements et de s’assurer la possibilité de rollback.

 

  1. Processus (Stateless)

Exécutez l’application comme un ou plusieurs processus sans état.

Qui dit cloud dit scalabilité, une requête doit pouvoir être traitée par n’importe quelle instance ou processus d’une application. Ceci implique qu’aucun état ne doit être stocké en interne par un processus. Si un processus nécessite le stockage d’un état, il le fera en utilisant un service externe et partagé par tous comme un cache distribué ou une base de données.

 

  1. Association de port (Port Binding)

Exportez les services via des associations de ports.

Une application est autonome et doit exposer le port utile à son fonctionnement. L’exposition de l’application à l’extérieur est prise en charge par le cloud provider qui assure le mapping et le routage. Cela présuppose que l’application ne doit pas dépendre d’un serveur web externe, l’utilisation de containers tend à être la solution la plus répandue.

 

  1. Concurrence (concurrency)

Grossissez à l’aide du modèle de processus.

Lorsque la capacité doit augmenter, mettez les applications à l’échelle horizontalement et non verticalement. La concurrence signifie que les tâches peuvent être exécutées dans le désordre et que le résultat ne sera pas différent de celui obtenu si elles avaient été exécutées dans l’ordre.

 

  1. Jetable (disposability)

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

Le « 12 factor app » part du principe qu’une application peut être démarrée ou stoppée à tout moment pour n’importe quelle raison. Pour cela une application doit être opérationnelle rapidement. De même, elle doit s’arrêter proprement afin que ses travaux en cours soient potentiellement envoyés vers une autre instance.

 

  1. Parité Dev/Prod (fast releases)

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

Réduire les écarts qui existent entre le développement et la production d’une application traditionnelle, favorisant ainsi un déploiement continu en s’assurant que les environnements de développement, de staging et de production sont aussi similaires que possible.

 

  1. Logs (logging)

Traitez les logs comme des flux d’événements.

L’application ne doit pas gérer le stockage des logs. Ceux-ci doivent être envoyés vers la sortie standard et traités par un système externe.

 

  1. Processus d’administration (Admin Process)

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

Les opérations de maintenance doivent être ponctuelles, uniques et exécutées dans le même environnement que l’application. Ces opérations doivent être idempotent. Afin d’éviter les problèmes de synchronisation, les scripts éventuels doivent être livrés avec l’application.

Conclusion

Plus de 10 ans après, on observe que le « 12 factor app » est toujours une excellente base pour les équipes de développeurs créant des applications nécessitant d’un certain niveau d’échelle, de fiabilité et de maintenabilité. Elle est particulièrement utile comme critère d’acceptation pour évaluer si un logiciel est prêt pour la production.

Aller au contenu principal