GitHub
IV. Backing services
Tratar a los “backing services” como recursos conectables
Un backing service es cualquier recurso que la aplicación puede consumir a través de la red como parte de su funcionamiento habitual. Entre otros ejemplos, podemos encontrar bases de datos (como MySQL o CouchDB), los sistemas de mensajería y de colas (como RabbitMQ o Beanstalkd), los servicios SMTP de email (como Postfix), y los sistemas de cache (como Memcached).
Tradicionalmente, los “backing services” (como las bases de datos) han sido gestionadas por los mismos administradores de sistemas que despliegan la aplicacion en producción. Además de esos servicios gestionados localmente, las aplicaciones también pueden usar servicios proporcionados y gestionados por terceros, como por ejemplo los servicios SMTP (Postmark), los servicios de recopilación de métricas (como New Relic o Loggly), los servicios de activos binarios (como Amazon S3), e incluso servicios que se consumen accediendo a ellos mediante un API (como Twitter, Google Maps, o Last.fm).
El código de una aplicación “twelve-factor” no hace distinciones entre servicios locales y de terceros. Para la aplicación, ambos son recursos conectados, accedidos mediante una URL u otro localizador o credencial almacenado en la config. Un despliegue de una aplicación “twelve-factor” debería ser capaz de reemplazar una base de datos local MySQL por una gestionada por un tercero (como Amazon RDS) sin ningún cambio en el código de la aplicación. Igualmente, un servidor SMTP local se podría cambiar por un servicio de terceros (como Postmark) sin modificaciones en el código. En ambos casos, solo el manejador del recurso necesita cambiar en la configuración.
Cada “backing service” distinto es un recurso. Por ejemplo, una base de datos MySQL es un recurso; dos bases de datos MySQL (usadas para “sharding” en la capa de aplicación) les convierte en dos recursos distintos. Una aplicación “twelve factor” trata esas bases de datos como recursos conectados, lo que demuestra su bajo acoplamiento al despliegue al que se unen.
Los recursos se pueden conectar y desconectar a voluntad. Por ejemplo, si la base de datos funciona mal debido a un problema en el hardware, el administrador de la aplicación puede cambiar a un nuevo servidor de bases de datos que haya sido restaurado de un backup reciente. La base de datos actual de producción se puede desconectar, y conectar una nueva base de datos sin tener que cambiar nada en el código.