GitHub
IV. Services externes
Traitez les services externes comme des ressources attachées
Un service externe (backing service) correspond à tout service que l’application utilise à travers le réseau pour son fonctionnement nominal. Cela concerne par exemple les bases de données (tel que MySQL ou CouchDB), les systèmes de messages/files (tel que RabbitMQ ou Beanstalkd), les services SMTP pour l’envoi d’email (comme Postfix), ainsi que les systèmes de cache (comme Memcached).
Les services externes comme la base de données sont le plus souvent gérés par les mêmes administrateurs réseau que ceux qui gèrent l’application de production. En plus de ces services gérés localement, l’application peut également avoir besoin de services gérés par des tiers. Cela concerne par exemple les services SMTP (comme Postmark), les services de gestion de métriques (comme New Relic ou Loggly), les services de ressources binaires (comme Amazon S3), et même les services que l’on peut consommer à travers une API (comme Twitter, Google Maps, ou Last.fm).
Le code d’une application 12 facteurs ne fait pas de distinction entre les services locaux et les services tiers. Pour l’application, ce sont tous les deux des ressources attachées, accessibles via une URL ou un autre système de localisation et d’authentification stockée dans la configuration. Un déploiement d’une application 12 facteurs doit pouvoir remplacer une base de données MySQL locale par une autre gérée par des tiers (Amazon RDS, par exemple) sans le moindre changement dans le code de l’application. De la même manière, un serveur SMTP local doit pouvoir être remplacé par un service tiers (Postmark, par exemple) sans changements dans le code. Dans les deux cas, seules les informations de configurations doivent changer.
Chaque service externe est une ressource. Par exemple, une base de données MySQL est une ressource. Deux bases de données MySQL (utilisées pour faire du sharding dans la couche applicative) correspondent à deux ressources distinctes. L’application 12 facteurs traite ces bases de données comme des ressources attachées, ce qui indique leur couplage faible au déploiement auquel elles sont rattachées.
Les ressources peuvent être attachées et détachées à volonté à des déploiements. Par exemple, si la base de données de l’application pose problème pour des raisons matérielles, l’administrateur de l’application peut vouloir lancer un nouveau serveur de base de données restauré à partir d’une sauvegarde récente. L’application courante pourrait être détachée de l’ancienne, puis rattachée à la nouvelle — le tout sans changement dans le code.