# Les Apps 12-facteurs
une présentation sur le pouce par **Pierre Baillet**
*@octplane* sur twitter
pierre@baillet.name
Avril 2016
=
## Qui-suis-je ?
- Consultant Senior, Manager Technique chez IPPON Technologies
- Dev/Ops chez fotopedia pendant 4 ans
- Directeur du développement puis de la production chez IDM pendant 8 ans
- Développe des applications depuis 1993
=
# Plan
- Historique et Philosophie
- Les 12 FACTORS
- Conclusion et débat
==
# Historique
#### et
# philosophie
=
# The 12-factor App
- manifeste philosophique
- issu de la pratique DevOps
- rédigé par la communauté et Adam Wiggins de Heroku, en 2011
- presque devenu un classique de la littérature
=
# Mieux développer
- 12 facteurs - valeurs clés
- meilleure scalabilité
- meilleure intégration aux opérations
- meilleure indépendance vis-à-vis des plateformes cibles
- mini-mode d'emploi, agnostique par rapport à la technologie
- source d'inspiration et de débat !
==
# Les 12 FACTORS
=
## I. Base de code
*Une base de code suivie avec un système de contrôle de version, plusieurs environnements*
- utilisation du contrôle de source
- une application = une base de code. Si on a besoin de plusieurs base de code, cf. II
- chaque base de code peut être déployée de multiples fois (version pour le dev', le test, la pré-prod, ...)
> pour les dev' 💻 : transmission de code simplifiée
> pour les ops 🔧 : facile à manipuler
> en production 💵 : audit et historique
=
## II. Dépendances
*Déclarez explicitement et isolez les dépendances*
- pas de dépendance "implicite" sur le système cible
- y compris au niveau des outils systèmes (curl, p. ex.)
- **déclaration** explicite des dépendances via un gestionnaire de dépendances
- **isolation** lors du build des dépendances
> pour les dev' 💻 : onboarding plus rapide
> pour les ops 🔧 : auditabilité
> en production 💵 : vendor et cache
=
## III. Configuration
*Stockez la configuration dans l’environnement*
- configuration = ce qui varie d'un environnement à l'autre
- à stocker en dehors des app. (pas de constante de conf. dans les applications)
- dans les variables d'environnement
- agnostique à la techno ou au langage utilisé
> 💻 : facile à inspecter, modifier
> 🔧 : audit
> 💵 : isolation, interopérable
=
## IV. Services externes
*Traitez les services externes comme des ressources attachées*
- service externe = systeme, service sur lequel se connecte votre application
- isoler de la même façon les services locaux et les services tiers
- via la configuration, permettre de facilement les substituer
> 💻 : facile à connecter sur d'autres systèmes
> 🔧 : interaction simple à analyser
> 💵 : HA facilité, sécurité et flux
=
## V. Build, release, run
*Séparez strictement les étapes d’assemblage et d’exécution*
- la construction se fait lorsqu'un commit est envoyé dans une branche ailleurs qu'en développement
- l'artefact construit est immuable et est stocké
- le lancement est fait en production à partir de l'artefact et de la configuration
- chaque artefact est unique, numéroté et immuable
> 💻 : testabilité
> 🔧 : immutabilité
> 💵 : audit, replication, DRP
=
## VI. Processus
*Exécutez l’application comme un ou plusieurs processus sans état*
- les applications sont stateless, et stockent leur état dans les systèmes tiers (stateful, eux)
- stockage sur le FS temporaire, ou pour cacher, mais pas de garantie
- les assets packagés sont assemblés lors du build de l'artefact et pas lors du run
> 💻 : récupération des environnements facilités
> 🔧 : pas de données compliquées à stocker, déploiements plus sûrs
> 💵 : scalabilité, résilience
=
## VII. Associations de ports
*Exportez les services via des associations de ports*
- les applications ne doivent pas compter sur l'environnement au moment de leur démarrage pour être exposées sur internet
- elles doivent contenir le serveur qui leur permettra de tourner de manière autonome
- l'environnement d'exécution permettra lui de faire le lien avec l'extérieur (proxy, redirection de port...)
> 💻 : facilité de déploiement en local
> 🔧 : meilleur audit côté réseau
> 💵 : scalabilité
=
## VIII. Concurrence
*Grossissez à l’aide du modèle de processus*
- les modèles de croissance à l'intérieur d'une même VM sont souvent limités
- l'utilisation de processus de types variés (web, worker, ...) permet une croissance horizontale infinie
- en interne, l'utilisation de threads est bien entendu possible
> 💻 : moins de souci en context "multi"
> 🔧 : scalabilité accrue
> 💵 : croissance horizontale facile
=
## IX. Jetable
*Maximisez la robustesse avec des démarrages rapides et des arrêts gracieux*
- les applications doivent supporter des démarrages et arrêts "rapides"
- quelques secondes pour le démarrage
- pour l'arrêt suivant le type d'app, peut être plus ou moins simple : fin des requêtes en cours, rejet du job courant, ...
> 💻 : bootstrap plus simple
> 🔧 : pas de cas de conscience en cas de souci
> 💵 : meilleure maintenance et résilience
=
## X. Parité dev/prod
*Gardez le développement, la validation et la production aussi proches que possible*
- combler le fossé temporel, de personnes et techniques
- fossé temporel : agilité pour les déploiements
- fossé des personnes : faire travailler dev et ops ensemble depuis la conception jusqu'à la maintenance
- fossé technique : même système externes et version entre les environnements
> 💻 : plus facile de développer
> 🔧 : moins d'écart technique
> 💵 : moins de bugs, meilleure productivité
=
## XI. Logs
*Traitez les logs comme des flux d’évènements*
- pas vraiment le problème de l'application
- logger sur la stdout, sans buffer
- l'environnement d'exécution capture, route puis gère ce flux d'évènements
- systèmes d'analyse et de graphes tiers
> 💻 : facile à auditer
> 🔧 : facile à router et à traiter
> 💵 : meilleure analyse
=
## XII. Processus d’administration
*Lancez les processus d’administration et de maintenance comme des one-off-processes*
- les processus d'administration exécutent du code qui est livré avec l'application
- tournent dans les même contextes d'environnement et d'exécution que l'application
- sont des "one-off"
- peuvent être surveillés par l'environnement
> 💻 : plus facile à développer en synchro avec le code principal
> 🔧 : plus facile à déployer
> 💵 : stabilité accrue
==
# Conclusion & débat
- http://12factor.net/ : version en français
- Faites des applications !
- Transformez vos applications classiques en applications 12-factor
- Essayez et trompez-vous !
- Parlez-en à vos amis.
##### et merci...
==
### Et vous, comment mettez-vous en place le 12 factor ?
- Base de code
- Dépendances
- Configuration
- Services externes
- Build, release, run
- Processus
- Associations de ports
- Concurrence
- Jetable
- Parité dev/prod
- Logs
- Processus d’administration