{"id":10703,"date":"2022-09-07T14:55:00","date_gmt":"2022-09-07T14:55:00","guid":{"rendered":"https:\/\/bissoluciones.com\/blog\/?p=10703"},"modified":"2022-09-07T19:52:57","modified_gmt":"2022-09-07T19:52:57","slug":"conoce-la-metodologia-de-los-12-factores-de-la-aplicacion","status":"publish","type":"post","link":"https:\/\/bissoluciones.com\/blog\/en\/conoce-la-metodologia-de-los-12-factores-de-la-aplicacion\/","title":{"rendered":"Know the methodology of the 12 factors of the application"},"content":{"rendered":"

Introduction<\/strong><\/p>\n\n\n\n

En estos tiempos, el software se est\u00e1 distribuyendo como un servicio: se le denomina web apps, o software as a service (SaaS). \u201cThe twelve-factor app\u201d es una metodolog\u00eda para construir aplicaciones SaaS que:<\/p>\n\n\n\n

Usan formatos declarativos para la automatizaci\u00f3n de la configuraci\u00f3n, para minimizar el tiempo y el coste que supone que nuevos desarrolladores se unan al proyecto;<\/p>\n\n\n\n

Tienen un contrato claro con el sistema operativo sobre el que trabajan, ofreciendo la m\u00e1xima portabilidad entre los diferentes entornos de ejecuci\u00f3n;<\/p>\n\n\n\n

Son apropiadas para desplegarse en modernas plataformas en la nube, obviando la necesidad de servidores y administraci\u00f3n de sistemas;<\/p>\n\n\n\n

Minimizan las diferencias entre los entornos de desarrollo y producci\u00f3n, posibilitando un despliegue continuo para conseguir la m\u00e1xima agilidad;<\/p>\n\n\n\n

Y pueden escalar sin cambios significativos para las herramientas, la arquitectura o las pr\u00e1cticas de desarrollo.<\/p>\n\n\n\n

La metodolog\u00eda \u201ctwelve-factor\u201d puede ser aplicada a aplicaciones escritas en cualquier lenguaje de programaci\u00f3n, y cualquier combinaci\u00f3n de \u2018backing services\u2019 (bases de datos, colas, memoria cache, etc).<\/p>\n\n\n\n

Contexto<\/strong><\/p>\n\n\n\n

Los colaboradores de este documento han estado involucrados directamente en el desarrollo y despliegue de cientos de aplicaciones, y han sido testigos indirectos del desarrollo, las operaciones y el escalado de cientos de miles de aplicaciones mediante nuestro trabajo en la plataforma Heroku.<\/p>\n\n\n\n

Este documento sintetiza toda nuestra experiencia y observaciones en una amplia variedad de aplicaciones SaaS. Es la triangulaci\u00f3n entre practicas ideales para el desarrollo de aplicaciones, prestando especial atenci\u00f3n a las din\u00e1micas del crecimiento natural de una aplicaci\u00f3n a lo largo del tiempo, las din\u00e1micas de colaboraci\u00f3n entre desarrolladores que trabajan en el c\u00f3digo base de las aplicaciones y evitando el coste de la entrop\u00eda del software.<\/p>\n\n\n\n

Nuestra motivaci\u00f3n es mejorar la concienciaci\u00f3n sobre algunos problemas sist\u00e9micos que hemos observado en el desarrollo de las aplicaciones modernas, aportar un vocabulario com\u00fan que sirva para discutir sobre estos problemas, y ofrecer un conjunto de soluciones conceptualmente robustas para esos problemas acompa\u00f1ados de su correspondiente terminolog\u00eda. El formato est\u00e1 inspirado en los libros de Martin Fowler Patterns of Enterprise Application Architecture y Refactoring.<\/p>\n\n\n\n

\u00bfQui\u00e9n deber\u00eda leer este documento?<\/strong><\/p>\n\n\n\n

Cualquier desarrollador que construya aplicaciones y las ejecute como un servicio. Ingenieros de operaciones que desplieguen y gestionen dichas aplicaciones.<\/p>\n\n\n\n

I. C\u00f3digo base (Codebase)<\/strong><\/p>\n\n\n\n

Un c\u00f3digo base sobre el que hacer el control de versiones y multiples despliegues<\/p>\n\n\n\n

Una aplicaci\u00f3n \u201ctwelve-factor\u201d se gestiona siempre con un sistema de control de versiones, como Git, Mercurial, o Subversion. A la copia de la base de datos de seguimiento de versiones se le conoce como un repositorio de c\u00f3digo, a menudo abreviado como repo de c\u00f3digo o simplemente repo.<\/p>\n\n\n\n

El c\u00f3digo base es cualquier repositorio (en un sistema de control de versiones centralizado como Subversion), o cualquier conjunto de repositorios que comparten un commit ra\u00edz (en un sistema de control de versiones descentralizado como Git).<\/p>\n\n\n\n

El c\u00f3digo base se usa en muchos despliegues<\/p>\n\n\n\n

Siempre hay una relaci\u00f3n uno a uno entre el c\u00f3digo base y la aplicaci\u00f3n:<\/p>\n\n\n\n

Si hay multiples c\u00f3digos base, no es una aplicaci\u00f3n \u2013 es un sistema distribuido. Cada componente en un sistema distribuido es una aplicaci\u00f3n, y cada uno, individualmente, puede cumplir los requisitos de una aplicaci\u00f3n \u201ctwelve-factor\u201d.<\/p>\n\n\n\n

Compartir c\u00f3digo en varias aplicaciones se considera una violaci\u00f3n de la metodolog\u00eda \u201ctwelve factor\u201d. La soluci\u00f3n en este caso es separar el c\u00f3digo compartido en librer\u00edas que pueden estar enlazadas mediante un gestor de dependencias.<\/p>\n\n\n\n

El c\u00f3digo base de la aplicaci\u00f3n es \u00fanico, sin embargo, puede haber tantos despliegues de la aplicaci\u00f3n como sean necesarios. Un despliegue es una instancia de la aplicaci\u00f3n que est\u00e1 en ejecuci\u00f3n. Normalmente, se ejecuta en un entorno de producci\u00f3n, y uno o varios entornos de pruebas. Adem\u00e1s, cada desarrollador tiene una instancia en su propio entorno de desarrollo, los cuales se consideran tambi\u00e9n como despliegues.<\/p>\n\n\n\n

El c\u00f3digo base es el mismo en todos los despliegues, aunque pueden ser diferentes versiones en cada despliegue. Por ejemplo, un desarrollador tiene algunos commits sin desplegar en preproducci\u00f3n; preproducci\u00f3n tiene algunos commits que no est\u00e1n desplegados en producci\u00f3n. Pero todos ellos comparten el mismo c\u00f3digo base, de este modo todos son identificables como diferentes despliegues de la misma aplicaci\u00f3n.<\/p>\n\n\n\n

II. Dependencias<\/strong><\/p>\n\n\n\n

Declarar y aislar expl\u00edcitamente las dependencias<\/p>\n\n\n\n

La mayor\u00eda de los lenguajes de programaci\u00f3n tienen un sistema de gesti\u00f3n de paquetes para distribuir sus librer\u00edas, como CPAN en Perl o Rubygems en Ruby. Las librer\u00edas instaladas a trav\u00e9s de estos sistemas se pueden instalar en el sistema (tambi\u00e9n conocido como \u201csite packages\u201d) o limitarse al directorio que contiene la aplicaci\u00f3n (tambi\u00e9n conocido como \u201cvendoring\u201d o \u201cbundling\u201d).<\/p>\n\n\n\n

Una aplicaci\u00f3n \u201ctwelve-factor\u201d no depende nunca de la existencia expl\u00edcita de paquetes instalados en el sistema. Declara todas sus dependencias, completamente y expl\u00edcitamente, mediante un manifiesto de declaraci\u00f3n de dependencias. Adem\u00e1s, usa herramientas de aislamiento de dependencias durante la ejecuci\u00f3n para asegurar que las dependencias, impl\u00edcitamente, no afectan al resto del sistema. La especificaci\u00f3n de dependencias completa y expl\u00edcita se aplica de la misma manera tanto en producci\u00f3n como en desarrollo.<\/p>\n\n\n\n

Por ejemplo, la Bundler de Ruby tiene el formato de su manifiesto Gemfile para declarar sus dependencias y bundle exec para aislar sus dependencias. En Python existen dos herramientas independientes para estas tareas \u2013 Pip se usa para la declaraci\u00f3n de dependencias y Virtualenv para el aislamiento. Incluso C tiene Autoconf para la declaraci\u00f3n de sus dependencias, y el enlace est\u00e1tico proporciona aislamiento de sus dependencias. No importa qu\u00e9 conjunto de herramientas se use, la declaraci\u00f3n y el aislamiento de dependencias se deben usar siempre juntas, usar solo una o la otra no es suficiente para satisfacer las condiciones de \u201ctwelve-factor\u201d.<\/p>\n\n\n\n

Uno de los beneficios de la declaraci\u00f3n expl\u00edcita de dependencias es que simplifica la configuraci\u00f3n para los nuevos desarrolladores de la aplicaci\u00f3n. Cualquier desarrollador que se incorpore al equipo debe poder probar el c\u00f3digo base de la aplicaci\u00f3n en su m\u00e1quina de desarrollo. Tan solo debe tener instalados el entorno de ejecuci\u00f3n del lenguaje y el gestor de dependencias como prerequisitos. Lo cual permitir\u00e1 configurar todo lo necesario para ejecutar el c\u00f3digo de la aplicaci\u00f3n con un mandato para construir. Por ejemplo, el mandato para construir en Ruby\/Bundler es bundle install, mientras que en Clojure\/Leiningen es lein deps.<\/p>\n\n\n\n

Las aplicaciones \u201cTwelve-factor\u201d tampoco dependen de la existencia de ninguna herramienta en el sistema. Por ejemplo, ejecutar mandatos como ImageMagick o curl. Aunque estas herramientas pueden existir en muchos, o incluso en la mayor\u00eda de los sistemas, no existen garant\u00edas de que vayan a existir en todos los sistemas donde la aplicaci\u00f3n pueda ser ejecutada en un futuro, ni de que las versiones futuras de un sistema vayan a ser compatibles con la aplicaci\u00f3n. Si la aplicaci\u00f3n necesita ejecutar una herramienta del sistema, dicha herramienta deber\u00eda estar incluida dentro de la aplicaci\u00f3n.<\/p>\n\n\n\n

III. Configuraci\u00f3n<\/strong><\/p>\n\n\n\n

Guardar la configuraci\u00f3n en el entorno<\/p>\n\n\n\n

La configuraci\u00f3n de una aplicaci\u00f3n es todo lo que puede variar entre despliegues (entornos de preproducci\u00f3n, producci\u00f3n, desarrollo, etc), lo cual incluye:<\/p>\n\n\n\n

Recursos que manejan la base de datos, Memcached, y otros \u201cbacking services\u201d<\/p>\n\n\n\n

Credenciales para servicios externos tales como Amazon S3 o Twitter<\/p>\n\n\n\n

Valores de despliegue como por ejemplo el nombre can\u00f3nico del equipo para el despliegue<\/p>\n\n\n\n

A veces las aplicaciones guardan configuraciones como constantes en el c\u00f3digo, lo que conduce a una violaci\u00f3n de la metodolog\u00eda \u201ctwelve-factor\u201d, que requiere una estricta separaci\u00f3n de la configuraci\u00f3n y el c\u00f3digo. La configuraci\u00f3n var\u00eda sustancialmente en cada despliegue, el c\u00f3digo no.<\/p>\n\n\n\n

La prueba de fuego para saber si una aplicaci\u00f3n tiene toda su configuraci\u00f3n correctamente separada del c\u00f3digo es comprobar que el c\u00f3digo base puede convertirse en c\u00f3digo abierto en cualquier momento, sin comprometer las credenciales.<\/p>\n\n\n\n

Hay que resaltar que la definici\u00f3n de \u201cconfiguraci\u00f3n\u201d no incluye las configuraciones internas de la aplicaci\u00f3n, como config\/routes.rb en Rails, o como se conectan los m\u00f3dulos en Spring. Este tipo de configuraciones no var\u00edan entre despliegues, y es por eso que est\u00e1n mejor en el c\u00f3digo.<\/p>\n\n\n\n

Otra estrategia de configuraci\u00f3n es el uso de ficheros de configuraci\u00f3n que no se guardan en el control de versiones, como ocurre con el config\/database.yml de Rails. Esto supone una gran mejora con respecto a las constantes que se guardan en el repositorio, aunque todav\u00eda tiene ciertas debilidades: es f\u00e1cil guardar un fichero de configuraci\u00f3n en el repo por error; se tiende a desperdigar los ficheros de configuraci\u00f3n en diferentes sitios y con distintos formatos, siendo m\u00e1s dif\u00edcil la tarea de ver y gestionar toda la configuraci\u00f3n en un solo sitio. Adem\u00e1s, el formato tiende a ser espec\u00edfico del lenguaje o del framework.<\/p>\n\n\n\n

Las aplicaciones \u201ctwelve-factor\u201d almacenan la configuraci\u00f3n en variables de entorno (abreviadas normalmente como env vars o env). Las variables de entorno se modifican f\u00e1cilmente entre despliegues sin realizar cambios en el c\u00f3digo; a diferencia de los ficheros de configuraci\u00f3n, en los que existe una peque\u00f1a posibilidad de que se guarden en el repositorio de c\u00f3digo accidentalmente; y a diferencia de los ficheros de configuraci\u00f3n personalizados u otros mecanismos de configuraci\u00f3n, como los System Properties de Java, son un est\u00e1ndar independiente del lenguaje y del sistema operativo.<\/p>\n\n\n\n

Otro aspecto de la gesti\u00f3n de la configuraci\u00f3n es la clasificaci\u00f3n. A veces, las aplicaciones clasifican las configuraciones en grupos identificados (a menudo llamados \u201centornos\u201d o \u201cenvironments\u201d) identificando despu\u00e9s despliegues espec\u00edficos, como ocurre en Rails con los entornos development, test, y production. Este m\u00e9todo no escala de una manera limpia: seg\u00fan se van creando despliegues de la aplicaci\u00f3n, se van necesitando nuevos entornos, tales como staging o qa. Seg\u00fan va creciendo el proyecto, los desarrolladores van a\u00f1adiendo sus propios entornos especiales como joes-staging, resultando en una explosi\u00f3n de combinaciones de configuraciones que hacen muy fr\u00e1gil la gesti\u00f3n de despliegues de la aplicaci\u00f3n.<\/p>\n\n\n\n

En una aplicaci\u00f3n \u201ctwelve-factor\u201d, las variables de entorno son controles granulares, cada una de ellas completamente ortogonales a las otras. Nunca se agrupan juntas como \u201centornos\u201d, pero en su lugar se gestionan independientemente para cada despliegue. Este es un modelo que escala con facilidad seg\u00fan la aplicaci\u00f3n se ampl\u00eda, naturalmente, en m\u00e1s despliegues a lo largo de su vida.<\/p>\n\n\n\n

IV. Backing services<\/strong><\/p>\n\n\n\n

Tratar a los \u201cbacking services\u201d como recursos conectables<\/p>\n\n\n\n

Un backing service es cualquier recurso que la aplicaci\u00f3n puede consumir a trav\u00e9s 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\u00eda y de colas (como RabbitMQ o Beanstalkd), los servicios SMTP de email (como Postfix), y los sistemas de cache (como Memcached).<\/p>\n\n\n\n

Tradicionalmente, los \u201cbacking services\u201d (como las bases de datos) han sido gestionadas por los mismos administradores de sistemas que despliegan la aplicacion en producci\u00f3n. Adem\u00e1s de esos servicios gestionados localmente, las aplicaciones tambi\u00e9n pueden usar servicios proporcionados y gestionados por terceros, como por ejemplo los servicios SMTP (Postmark), los servicios de recopilaci\u00f3n de m\u00e9tricas (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).<\/p>\n\n\n\n

El c\u00f3digo de una aplicaci\u00f3n \u201ctwelve-factor\u201d no hace distinciones entre servicios locales y de terceros. Para la aplicaci\u00f3n, ambos son recursos conectados, accedidos mediante una URL u otro localizador o credencial almacenado en la config. Un despliegue de una aplicaci\u00f3n \u201ctwelve-factor\u201d deber\u00eda ser capaz de reemplazar una base de datos local MySQL por una gestionada por un tercero (como Amazon RDS) sin ning\u00fan cambio en el c\u00f3digo de la aplicaci\u00f3n. Igualmente, un servidor SMTP local se podr\u00eda cambiar por un servicio de terceros (como Postmark) sin modificaciones en el c\u00f3digo. En ambos casos, solo el manejador del recurso necesita cambiar en la configuraci\u00f3n.<\/p>\n\n\n\n

Cada \u201cbacking service\u201d distinto es un recurso. Por ejemplo, una base de datos MySQL es un recurso; dos bases de datos MySQL (usadas para \u201csharding\u201d en la capa de aplicaci\u00f3n) les convierte en dos recursos distintos. Una aplicaci\u00f3n \u201ctwelve factor\u201d trata esas bases de datos como recursos conectados, lo que demuestra su bajo acoplamiento al despliegue al que se unen.<\/p>\n\n\n\n

Un despliegue en producci\u00f3n conectado a cuatro backing services.<\/p>\n\n\n\n

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\u00f3n 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\u00f3n se puede desconectar, y conectar una nueva<\/p>\n\n\n\n

V. Construir, distribuir, ejecutar<\/strong><\/p>\n\n\n\n

Separar completamente la etapa de construcci\u00f3n de la etapa de ejecuci\u00f3n<\/p>\n\n\n\n

El c\u00f3digo base se transforma en un despliegue (que no es de desarrollo) al completar las siguientes tres etapas:<\/p>\n\n\n\n

La etapa de construcci\u00f3n es una transformaci\u00f3n que convierte un repositorio de c\u00f3digo en un paquete ejecutable llamado construcci\u00f3n (una \u201cbuild\u201d). En la etapa de construcci\u00f3n se traen todas las dependencias y se compilan los binarios y las herramientas usando una versi\u00f3n concreta del c\u00f3digo correspondiente a un commit especificado por el proceso de despliegue.<\/p>\n\n\n\n

En la fase de distribuci\u00f3n se usa la construcci\u00f3n creada en la fase de construcci\u00f3n y se combina con la configuraci\u00f3n del despliegue actual. Por tanto, la distribuci\u00f3n resultante contiene tanto la construcci\u00f3n como la configuraci\u00f3n y est\u00e1 lista para ejecutarse inmediatamente en el entorno de ejecuci\u00f3n.<\/p>\n\n\n\n

La fase de ejecuci\u00f3n (tambi\u00e9n conocida como \u201cruntime\u201d) ejecuta la aplicaci\u00f3n en el entorno de ejecuci\u00f3n, lanzando un conjunto de procesos de una distribuci\u00f3n concreta de la aplicaci\u00f3n.<\/p>\n\n\n\n

El c\u00f3digo se convierte en una construcci\u00f3n, que se combina con la configuraci\u00f3n para crear una distribuci\u00f3n.<\/p>\n\n\n\n

Las aplicaciones \u201ctwelve-factor\u201d hacen una separaci\u00f3n completa de las fases de construcci\u00f3n, de distribuci\u00f3n y de ejecuci\u00f3n. Por ejemplo, es imposible hacer cambios en el c\u00f3digo en la fase de ejecuci\u00f3n, porque no hay una manera de propagar dichos cambios a la fase de construcci\u00f3n.<\/p>\n\n\n\n

Las herramientas de despliegue ofrecen, normalmente, herramientas de gesti\u00f3n de distribuciones (releases). La capacidad de volver a una versi\u00f3n anterior es especialmente \u00fatil. Por ejemplo, la herramienta de despliegues Capistrano almacena distribuciones en un subdirectorio llamado releases, donde la distribuci\u00f3n actual es un enlace simb\u00f3lico al directorio de la distribuci\u00f3n actual. Su mandato rollback hace f\u00e1cil y r\u00e1pidamente el trabajo de volver a la versi\u00f3n anterior.<\/p>\n\n\n\n

Cada distribuci\u00f3n deber\u00eda tener siempre un identificador \u00fanico de distribuci\u00f3n, como por ejemplo una marca de tiempo (timestamp) de la distribuci\u00f3n (2011-04-06-20:32:17) o un n\u00famero incremental (como v100). Las distribuciones son como un libro de contabilidad, al que solo se le pueden agregar registros y no pueden ser modificados una vez son creados. Cualquier cambio debe crear una nueva distribuci\u00f3n.<\/p>\n\n\n\n

Cada vez que un desarrollador despliega c\u00f3digo nuevo se crea una construcci\u00f3n nueva de la aplicaci\u00f3n. La fase de ejecuci\u00f3n, en cambio, puede suceder autom\u00e1ticamente, por ejemplo, cuando se reinicia un servidor, o cuando un proceso termina inesperadamente siendo reiniciado por el gestor de procesos. Por tanto, la fase de ejecuci\u00f3n deber\u00eda mantenerse lo m\u00e1s est\u00e1tica posible, ya que evita que una aplicaci\u00f3n en ejecuci\u00f3n pueda causar una interrupci\u00f3n inesperada, en mitad de la noche, cuando no hay desarrolladores a mano. La fase de construcci\u00f3n puede ser m\u00e1s compleja, ya que los errores siempre est\u00e1n en la mente de un desarrollador que dirige un despliegue.<\/p>\n\n\n\n

VI. Procesos<\/strong><\/p>\n\n\n\n

Ejecutar la aplicaci\u00f3n como uno o m\u00e1s procesos sin estado<\/p>\n\n\n\n

La aplicaci\u00f3n se ejecuta como uno o m\u00e1s procesos en el entorno de ejecuci\u00f3n.<\/p>\n\n\n\n

El caso m\u00e1s sencillo que podemos plantear es que el c\u00f3digo es un script independiente, el entorno de ejecuci\u00f3n es un port\u00e1til de un desarrollador, el compilador o interprete correspondiente del lenguaje est\u00e1 instalado, y el proceso se lanza mediante la linea de mandatos (por ejemplo, python my_script.py). Por otro lado podemos encontrar el caso de un despliegue en producci\u00f3n de una aplicaci\u00f3n compleja que puede usar muchos tipos de procesos, instanciados como cero o m\u00e1s procesos en ejecuci\u00f3n.<\/p>\n\n\n\n

Los procesos \u201ctwelve-factor\u201d no tienen estado y son \u201cshare-nothing\u201d. Cualquier informaci\u00f3n que necesite persistencia se debe almacenar en un \u2018backing service\u2019 con estado, habitualmente una base de datos.<\/p>\n\n\n\n

Tanto el espacio de memoria de un proceso como el sistema de ficheros se pueden usar como si fueran una cache temporal para hacer transacciones. Por ejemplo, descargar un fichero de gran tama\u00f1o, realizar alguna operaci\u00f3n sobre \u00e9l, y almacenar sus resultados en una base de datos. Las aplicaciones \u201ctwelve-factor\u201d nunca dan por hecho que cualquier cosa cacheada en memoria o en el disco vaya a estar disponible al realizar una petici\u00f3n al ejecutar diferentes procesos. Con muchos procesos de cada tipo ejecut\u00e1ndose al mismo tiempo, existe una gran probabilidad de que otro proceso distinto sirva una petici\u00f3n en el futuro. Incluso cuando solo est\u00e1 corriendo un solo proceso, un reinicio (provocado por el despliegue de c\u00f3digo, un cambio de configuraci\u00f3n o un cambio de contexto del proceso) normalmente elimina todo el estado local (e.g. memoria y sistema de ficheros).<\/p>\n\n\n\n

Los compresores de est\u00e1ticos (como Jammit o django-compressor) usan el sistema de ficheros como una cache para ficheros compilados. En las aplicaciones \u201ctwelve-factor\u201d es preferible realizar esta compilaci\u00f3n durante la fase de construcci\u00f3n, como con el asset pipeline de Rails, en lugar de hacerlo en tiempo de ejecuci\u00f3n.<\/p>\n\n\n\n

Algunos sistemas webs dependen de \u201csticky sessions\u201d, esto quiere decir que cachean la informaci\u00f3n de la sesi\u00f3n de usuario en la memoria del proceso de la aplicaci\u00f3n y esperan peticiones futuras del mismo visitante para redirigirle al mismo proceso. Las \u201csticky sessions\u201d son una violaci\u00f3n de \u201ctwelve-factor\u201d y no deber\u00edan usarse nunca ni depender de ellas. La informaci\u00f3n del estado de la sesi\u00f3n es un candidato perfecto para almacenes de informaci\u00f3n que ofrecen mecanismos de tiempo de expiraci\u00f3n, como Memcached o Redis.<\/p>\n\n\n\n

VII. Asignaci\u00f3n de puertos<\/strong><\/p>\n\n\n\n

Publicar servicios mediante asignaci\u00f3n de puertos<\/p>\n\n\n\n

Las aplicaciones web se ejecutan a menudo mediante contenedores web. Por ejemplo, las aplicaciones de PHP se suelen ejecutar como m\u00f3dulos del HTTPD de Apache, y las aplicaciones Java en Tomcat.<\/p>\n\n\n\n

Las aplicaciones \u201ctwelve factor\u201d son completamente auto-contenidas y no dependen de un servidor web en ejecuci\u00f3n para crear un servicio web p\u00fablico. Una aplicaci\u00f3n web usa HTTP como un servicio al que se le asigna un puerto, y escucha las peticiones que recibe por dicho puerto.<\/p>\n\n\n\n

En los entornos de desarrollo, los desarrolladores usan una URL del servicio (por ejemplo http:\/\/localhost:5000\/), para acceder al servicio que ofrece la aplicaci\u00f3n. En la fase de despliegue, existe una capa de enrutamiento que se encarga de que las peticiones que llegan a una direcci\u00f3n p\u00fablica se redirijan hacia el proceso web que tiene asignado su puerto correspondiente.<\/p>\n\n\n\n

Esto se implementa, normalmente, usando una declaraci\u00f3n de dependencias donde se incluyen librer\u00edas de las aplicaciones web, como Tornado para Python, Thin para Ruby, o Jetty para Java y otros lenguajes basados en la M\u00e1quina Virtual de Java (JVM). Esto ocurre totalmente en el entorno del usuario, es decir, dentro del c\u00f3digo de la aplicaci\u00f3n. El contrato con el entorno de ejecuci\u00f3n obliga al puerto a servir las peticiones.<\/p>\n\n\n\n

HTTP no es el \u00fanico servicio que usa asignaci\u00f3n de puertos. La verdad, es que cualquier servicio puede ejecutarse mediante un proceso al que se le asigna un puerto y queda a la espera de peticiones. Entre otros ejemplos podemos encontrar ejabberd (que usa XMPP), y Redis (que usa el protocolo Redis).<\/p>\n\n\n\n

Tambi\u00e9n es cierto que la aproximaci\u00f3n de asignaci\u00f3n de puertos ofrece la posibilidad de que una aplicaci\u00f3n pueda llegar a ser un \u201cbacking service\u201d para otra aplicaci\u00f3n, usando la URL de la aplicaci\u00f3n correspondiente como un recurso declarado en la configuraci\u00f3n de la aplicaci\u00f3n que consume este \u201cbacking service\u201d.<\/p>\n\n\n\n

VIII. Concurrencia<\/strong><\/p>\n\n\n\n

Escalar mediante el modelo de procesos<\/p>\n\n\n\n

Todo programa de ordenador, al ejecutarse, se encuentra representado en memoria por uno o m\u00e1s procesos. Las aplicaciones web se pueden ejecutar de diferentes formas desde el punto de vista del modelo de procesos que usan. Por ejemplo, los procesos PHP se ejecutan como procesos pesados (o simplemente procesos), hijos del proceso Apache, cre\u00e1ndolos bajo demanda a causa de la cantidad de peticiones si es necesario. Los procesos Java funcionan de forma distinta, la M\u00e1quina Virtual de Java (JVM) proporciona un conjunto de procesos que reservan al principio una gran cantidad de recursos del sistema (CPU y memoria), gestionando la concurrencia internamente mediante procesos ligeros (threads). En ambos casos, los procesos en ejecuci\u00f3n son pr\u00e1cticamente transparentes para los desarrolladores de la aplicaci\u00f3n.<\/p>\n\n\n\n

La escalabilidad est\u00e1 representada por el n\u00famero de procesos en ejecuci\u00f3n, mientras que la diversidad de carga de trabajo lo est\u00e1 por los tipos de procesos.<\/p>\n\n\n\n

En las aplicaciones \u201ctwelve-factor\u201d, los procesos son ciudadanos de primera clase. Los procesos de las aplicaciones \u201ctwelve-factor\u201d se inspiran en el modelo de procesos de unix para ejecutar demonios. Usando este modelo, el desarrollador puede distribuir la ejecuci\u00f3n de su aplicaci\u00f3n para gestionar diversas cargas de trabajo asignando cada tipo de trabajo a un tipo de proceso. Por ejemplo, las peticiones HTTP se pueden procesar con un proceso y las tareas con mucha carga de trabajo con hilos.<\/p>\n\n\n\n

Esto no exime a los procesos de gestionar su propia divisi\u00f3n interna mediante threads en la ejecuci\u00f3n de la m\u00e1quina virtual o mediante un modelo as\u00edncrono o por eventos con herramientas como EventMachine, Twisted, o Node.js. No obstante, una m\u00e1quina virtual aislada tiene una capacidad de crecimiento limitada, as\u00ed que la aplicaci\u00f3n debe ser capaz de dividirse en multiples procesos que se puedan ejecutar en m\u00faltiples m\u00e1quinas f\u00edsicas.<\/p>\n\n\n\n

El modelo de procesos muestra todo su potencial cuando llega el momento de escalar. La naturaleza \u201cshare-nothing\u201d, divide horizontalmente los procesos de las aplicaciones \u201ctwelve-factor\u201d y se traduce en un aumento de la concurrencia como una operaci\u00f3n simple y fiable. El conjunto de tipos de procesos y el n\u00famero de procesos de cada tipo es conocido como juego de procesos.<\/p>\n\n\n\n

Los procesos de las aplicaciones \u201ctwelve-factor\u201d nunca deber\u00edan ser demonios ni escribir ficheros de tipo PID. En su lugar, se deber\u00eda confiar en un gestor de procesos del sistema operativo (como systemd, un gestor de procesos distribuido en una plataforma en la nube, o una herramienta como Foreman en desarrollo) para gestionar los historiales, responder a procesos que terminen inesperadamente, y gestionar los reinicios y apagados provocados por los usuarios.<\/p>\n\n\n\n

IX. Desechabilidad<\/strong><\/p>\n\n\n\n

Hacer el sistema m\u00e1s robusto intentando conseguir inicios r\u00e1pidos y finalizaciones seguras<\/p>\n\n\n\n

Los procesos de las aplicaciones \u201ctwelve-factor\u201d son desechables, lo que significa que pueden iniciarse o finalizarse en el momento que sea necesario. Esto permite un escalado r\u00e1pido y flexible, un despliegue r\u00e1pido del c\u00f3digo y de los cambios de las configuraciones, y despliegues m\u00e1s robustos en producci\u00f3n.<\/p>\n\n\n\n

Los procesos deber\u00edan intentar conseguir minimizar el tiempo de arranque. En el mejor de los casos, un proceso necesita unos pocos segundos desde que se ejecuta el mandato hasta que arranca y est\u00e1 preparado para recibir peticiones o trabajos. Mejorar el tiempo de arranque proporciona mayor agilidad en el proceso de distribuci\u00f3n y escalado; y lo hace m\u00e1s robusto, porque el gestor de procesos puede mover procesos de forma segura entre m\u00e1quinas f\u00edsicas m\u00e1s f\u00e1cilmente.<\/p>\n\n\n\n

Los procesos se paran de manera segura cuando reciben una se\u00f1al SIGTERM desde el gestor de procesos. Un proceso web para de manera segura cuando deja de escuchar el puerto asociado al servicio (as\u00ed rechaza cualquier nueva petici\u00f3n), permitiendo que cualquier petici\u00f3n termine de procesarse y pueda finalizar sin problemas. Impl\u00edcitamente, seg\u00fan este modelo, las peticiones HTTP son breves (no duran m\u00e1s de unos pocos segundos) y, en el caso de un sondeo largo, el cliente deber\u00eda intentar reconectar una y otra vez cuando se pierda la conexi\u00f3n.<\/p>\n\n\n\n

Para finalizar de manera segura, un trabajador (o \u201cworker\u201d) debe devolver el trabajo actual a una cola de trabajos. Por ejemplo, en RabbitMQ un trabajador puede mandar un NACK; en Beanstalkd, el trabajo se devuelve a una cola autom\u00e1ticamente en el momento en el que el trabajador finaliza. Los sistemas de exclusi\u00f3n mutua como Delayed Job necesitan estar seguros para liberar su candado en el registro de trabajos. Impl\u00edcitamente, seg\u00fan este modelo, todos los trabajos son reentrantes, lo que se consigue normalmente generando los resultados de manera transaccional, o convirtiendo la operaci\u00f3n en idempotente.<\/p>\n\n\n\n

Los procesos deber\u00edan estar preparados contra finalizaciones inesperadas, como en el caso de un fallo a nivel hardware. Aunque es un caso m\u00e1s raro que una finalizaci\u00f3n mediante la se\u00f1al SIGTERM, se puede dar el caso. Lo recomendable es usar un sistema de colas robusto, como Beanstalkd, que devuelve los trabajos a su cola cuando los clientes se desconectan o expira su tiempo de espera (\u201ctimeout\u201d). En cualquier caso, una aplicaci\u00f3n \u201ctwelve-factor\u201d es una arquitectura que trata finalizaciones inesperadas y peligrosas. El dise\u00f1o Crash-only lleva este concepto a su conclusi\u00f3n l\u00f3gica.<\/p>\n\n\n\n

X. Igualdad entre desarrollo y producci\u00f3n<\/strong><\/p>\n\n\n\n

Mantener desarrollo, preproducci\u00f3n y producci\u00f3n tan parecidos como sea posible<\/p>\n\n\n\n

Hist\u00f3ricamente, han existido dos tipos de entorno muy diferenciados: desarrollo (donde un desarrollador puede editar en vivo en un despliegue local de la aplicaci\u00f3n) y producci\u00f3n (un despliegue en el que la aplicaci\u00f3n est\u00e1 en ejecuci\u00f3n disponible para que lo usen los usuarios). Estas diferencias se pueden clasificar en tres tipos:<\/p>\n\n\n\n

Diferencias de tiempo: Un desarrollador puede estar trabajando en un c\u00f3digo durante d\u00edas, semanas o incluso meses antes de que llegue a producci\u00f3n.<\/p>\n\n\n\n

Diferencias de personal: Los desarrolladores escriben el c\u00f3digo y los ingenieros de operaciones lo despliegan.<\/p>\n\n\n\n

Diferencias de herramientas: Los desarrolladores pueden usar una pila como Nginx, SQLite y OS X, mientras que en producci\u00f3n se usa Apache, MySQL y Linux.<\/p>\n\n\n\n

** Las aplicaciones \u201ctwelve-factor\u201d est\u00e1n dise\u00f1adas para hacer despliegues continuos que reducen las diferencias entre los entornos de desarrollo y producci\u00f3n.** Teniendo en cuenta las tres diferencias descritas anteriormente:<\/p>\n\n\n\n

Reducir las diferencias de tiempo: Un desarrollador puede escribir c\u00f3digo y tenerlo desplegado en tan solo unas horas, o incluso, minutos m\u00e1s tarde.<\/p>\n\n\n\n

Reducir las diferencias de personal: Los desarrolladores que escriben el c\u00f3digo est\u00e1n muy involucrados en el despliegue y observan su comportamiento en producci\u00f3n.<\/p>\n\n\n\n

Reducir las diferencias de herramientas: tratar de hacer que desarrollo y producci\u00f3n sean tan parecidos como sea posible.<\/p>\n\n\n\n

Resumiendo lo anterior en una tabla:<\/p>\n\n\n\n

Aplicaciones tradicionales           Aplicaciones \u00abtwelve-factor\u00bb<\/p>\n\n\n\n

Tiempo entre despliegues           Semanas             Horas<\/p>\n\n\n\n

Desarrolladores vs Ingenieros de operaciones   Diferentes personas      Mismas personas<\/p>\n\n\n\n

Entorno de desarrollo vs entorno de producci\u00f3n              Divergentes       Lo m\u00e1s parecidos posibles<\/p>\n\n\n\n

Los \u201cbacking services\u201d, como la base de datos de la aplicaci\u00f3n, el sistema de colas, o la cach\u00e9, es donde la igualdad en los entornos de desarrollo y producci\u00f3n es importante. Muchos lenguajes ofrecen librer\u00edas en las que se simplifica el acceso a los servicios de respaldo, incluidos adaptadores para diferentes tipos de servicios. Se pueden observar algunos ejemplos en la siguiente tabla.<\/p>\n\n\n\n

Tipo       Lenguaje             Librer\u00eda Adaptador<\/p>\n\n\n\n

Base de datos   Ruby\/Rails          ActiveRecord    MySQL, PostgreSQL, SQLite<\/p>\n\n\n\n

Colas     Python\/Django Celery   RabbitMQ, Beanstalkd, Redis<\/p>\n\n\n\n

Cach\u00e9   Ruby\/Rails          ActiveSupport::Cache   Memoria, sistema de ficheros, Memcached<\/p>\n\n\n\n

Los desarrolladores, a veces, caen en la tentaci\u00f3n de usar \u201cbacking services\u201d ligeros en sus entornos de desarrollo, mientras que en producci\u00f3n se usan los m\u00e1s serios y robustos. Por ejemplo, se usa SQLite en desarrollo y PostgreSQL en producci\u00f3n; o memoria local para la cach\u00e9 en desarrollo y Memcached en producci\u00f3n.<\/p>\n\n\n\n

Un desarrollador \u201ctwelve-factor\u201d no cae en la tentaci\u00f3n de usar diferentes \u201cbacking services\u201d en desarrollo y producci\u00f3n, incluso cuando los adaptadores te\u00f3ricamente abstractos est\u00e1n lejos de cualquier diferencia en \u201cbacking services\u201d. Las diferencias entre los servicios de respaldo tienen que ver con las peque\u00f1as incompatibilidades que surgen de la nada, causando que el c\u00f3digo que funciona y pasa los tests en desarrollo o en preproducci\u00f3n, falle en producci\u00f3n. Este tipo de errores provocan conflictos que desincentivan la filosof\u00eda del despliegue continuo. El coste de estos conflictos y el enfriamiento subsiguiente del despliegue continuo es extremadamente alto cuando se hace balance del total de tiempo de vida de una aplicaci\u00f3n.<\/p>\n\n\n\n

Los servicios ligeros locales son menos atractivos que antes. Los \u201cbacking services\u201d modernos como Memcached, PostgreSQL, y RabbitMQ no son dif\u00edciles de instalar y ejecutar gracias a los sistemas de gesti\u00f3n de paquetes modernos, como Homebrew y apt-get. Al mismo tiempo, las herramientas de gesti\u00f3n de la configuraci\u00f3n como Chef y Puppet combinadas con entornos virtuales ligeros como Docker o Vagrant permiten a los desarrolladores ejecutar entornos locales que son muy parecidos a los entornos de producci\u00f3n. El coste de instalar y usar estos sistemas es bajo comparado con el beneficio que se puede obtener de la paridad entre desarrollo y producci\u00f3n y del despliegue continuo.<\/p>\n\n\n\n

Los adaptadores de los \u201cbacking services\u201d todav\u00eda son de gran utilidad, porque hacen que cambiar de unos a otros sea un tr\u00e1mite relativamente poco doloroso. No obstante, todos los despliegues de una aplicaci\u00f3n (en entornos de desarrollo, preproducci\u00f3n y producci\u00f3n) deber\u00edan usar el mismo tipo y versi\u00f3n de cada uno de los \u201cbacking services\u201d.<\/p>\n\n\n\n

XI. Historiales<\/strong><\/p>\n\n\n\n

Tratar los historiales como una transmisi\u00f3n de eventos<\/p>\n\n\n\n

Los historiales permiten observar el comportamiento de la aplicaci\u00f3n durante su ejecuci\u00f3n. En entornos basados en servidores es muy com\u00fan escribir un fichero en disco (un \u201cfichero de hist\u00f3rico\u201d) pero este, es tan solo un posible formato de salida.<\/p>\n\n\n\n

Los historiales son la transmisi\u00f3n de un conjunto de eventos ordenados y capturados de la salida de todos los procesos en ejecuci\u00f3n y de los \u201cbacking services\u201d. En bruto, los historiales suelen estar en formato texto y tienen un evento por l\u00ednea (aunque las trazas de excepciones suelen estar en varias l\u00edneas). Los historiales no tienen un principio y un final fijo, sino que fluyen continuamente mientras la aplicaci\u00f3n est\u00e1 en funcionamiento.<\/p>\n\n\n\n

Una aplicaci\u00f3n \u201ctwelve-factor\u201d nunca se preocupa del direccionamiento o el almacenamiento de sus transmisiones de salida. No deber\u00eda intentar escribir o gestionar ficheros de historial. En su lugar, cada proceso en ejecuci\u00f3n escribe sus eventos a la salida est\u00e1ndar (o stdout). Durante el desarrollo, los desarrolladores ver\u00e1n el flujo en su terminal para observar el comportamiento de la aplicaci\u00f3n.<\/p>\n\n\n\n

En despliegues de preproducci\u00f3n y producci\u00f3n, cada transmisi\u00f3n del proceso ser\u00e1 capturada por el entorno de ejecuci\u00f3n, siendo capturadas junto con todos los otros flujos de la aplicaci\u00f3n, y redirigidas a uno o m\u00e1s destinos finales para ser revisadas y archivadas. Estos destinos donde se archivan no son visibles o configurables por la aplicaci\u00f3n, se gestionan totalmente por el entorno de ejecuci\u00f3n. Las herramientas de c\u00f3digo abierto que capturan y almacenan los historiales (como Logplex y Fluentd) se usan con este objetivo.<\/p>\n\n\n\n

Las transmisiones de eventos para una aplicaci\u00f3n pueden ser redirigidas a un fichero u observadas en tiempo real mediante un \u201ctail\u201d en un terminal. Cabe destacar que la transmisi\u00f3n se puede enviar a un sistema de an\u00e1lisis e indexado como Splunk, o a un sistema de almacenamiendo de datos de prop\u00f3sito general como Hadoop\/Hive. Estos sistemas se tienen en cuenta por el gran poder y la flexibilidad para inspeccionar el comportamiento de la aplicaci\u00f3n a lo largo del tiempo, incluyendo:<\/p>\n\n\n\n

Encontrar eventos espec\u00edficos del pasado.<\/p>\n\n\n\n

Gr\u00e1ficas de tendencia a gran escala (como las peticiones por minuto).<\/p>\n\n\n\n

Activaci\u00f3n de alertas de acuerdo con heur\u00edsticas definidas por el usuario (como una alerta cuando la cantidad de errores por minuto sobrepasa un cierto l\u00edmite).<\/p>\n\n\n\n

XII. Administraci\u00f3n de procesos<\/strong><\/p>\n\n\n\n

Ejecutar las tareas de gesti\u00f3n\/administraci\u00f3n como procesos que solo se ejecutan una vez<\/p>\n\n\n\n

El juego de procesos es el conjunto de procesos que se usa para hacer las tareas habituales de la aplicaci\u00f3n (como procesar las peticiones web). Por otro lado, es frecuente que los desarrolladores quieran ejecutar procesos de administraci\u00f3n o mantenimiento una sola vez, como por ejemplo:<\/p>\n\n\n\n

\u2022             Ejecutar migraciones de las bases de datos (e.g. manage.py migrate de Django, rake db:migrate de Rails).<\/p>\n\n\n\n

\u2022             Ejecutar una consola (tambi\u00e9n conocidas como REPL) para ejecutar c\u00f3digo arbitrario o inspeccionar los modelos de la aplicaci\u00f3n en una base de datos con datos reales. La mayor\u00eda de los lenguajes proporcionan un interprete del tipo REPL si se ejecuta el mismo mandato sin ning\u00fan argumento (e.g. python o perl) pero en algunos casos tienen un mandato distinto (e.g. irb en Ruby, rails console en Rails).<\/p>\n\n\n\n

\u2022             Ejecutar scripts incluidos en el repositorio de la aplicaci\u00f3n (e.g. php scripts\/fix_bad_records.php).<\/p>\n\n\n\n

Los procesos de este tipo deber\u00edan ejecutarse en un entorno id\u00e9ntico al que se usa normalmente en los procesos habituales de la aplicaci\u00f3n. Estos procesos se ejecutan en una distribuci\u00f3n concreta, usando el mismo c\u00f3digo base y la misma configuraci\u00f3n que cualquier otro proceso que ejecuta esa distribuci\u00f3n. El c\u00f3digo de administraci\u00f3n se debe enviar con el c\u00f3digo de la aplicaci\u00f3n para evitar problemas de sincronizaci\u00f3n.<\/p>\n\n\n\n

Se deber\u00edan usar las mismas t\u00e9cnicas de aislamiento de dependencias en todos los tipos de procesos. Por ejemplo, si un proceso web Ruby usa el mandato bundle exec thin start, entonces una migraci\u00f3n de la base de datos deber\u00eda usar bundle exec rake db:migrate. De la misma manera, un programa Python que usa Virtualenv deber\u00eda usar bin\/python para ejecutar tanto el servidor web Tornado como cualquier proceso de administraci\u00f3n manage.py.<\/p>\n\n\n\n

\u201cTwelve-factor\u201d recomienda encarecidamente lenguajes que proporcionan una consola del tipo REPL, ya que facilitan las tareas relacionadas con la ejecuci\u00f3n de scripts que solo han de usarse una vez. En un despliegue local, se invocar\u00e1n los procesos de administraci\u00f3n con un mandato directo en la consola dentro del directorio de la aplicaci\u00f3n. En un despliegue de producci\u00f3n, se puede usar ssh u otro mecanismo de ejecuci\u00f3n de mandatos remoto proporcionado por el entorno de ejecuci\u00f3n del despliegue para ejecutar dichos procesos.<\/p>\n\n\n\n

Conoce como Mendix te puede ayudar implementando est\u00e1 metodolog\u00eda<\/strong><\/p>\n\n\n\n

\n
\n

<\/p>

    <\/ul><\/div>\n
    \n
    \n<\/fieldset>\n