Escribir código de aplicación es anterior a la mayoría de las soluciones en la nube, soluciones que la mayoría de los programadores de aplicaciones escriben específicamente para estos días.

Para manejar esta disonancia, ha surgido la metodología de la aplicación de 12 Factores. Los 12 factores es un enfoque que ayuda a los programadores a escribir aplicaciones modernas de forma declarativa, utilizando contratos claros implementados a través de la nube.

En este artículo, presentaré la metodología de la aplicación de 12 factores y ofreceré un resumen de alto nivel de sus principios.

¿Qué es la metodología de la aplicación de 12 factores?

En 2012, los programadores de Heroku estrenaron la metodología de la aplicación de 12 factores. Estos programadores han desarrollado y desplegado cientos de aplicaciones que escribieron esta metodología, basándose en su experiencia de ver aplicaciones SaaS «en la naturaleza».

Este grupo considera la metodología una triangulación de:

• Prácticas ideales para apoyar el desarrollo de aplicaciones
• Las dinámicas que ocurren a medida que una aplicación crece orgánicamente
• La relación y colaboración entre desarrolladores de base de código

:

• Para ayudar a evitar los costos de erosión del software
• Para crear conciencia de los problemas sistémicos que han observado en el desarrollo de aplicaciones modernas

El grupo apunta a dos fuentes de inspiración, los Patrones de Arquitectura de Aplicaciones Empresariales y la Refactorización, ambos a cargo del desarrollador profesional Martin Fowler.

Y ahora, presentaré cada uno de los 12 factores.

Principio I. Base de código

«Una base de código rastreada en el control de revisiones, muchas implementaciones»

Su base de código debe tener un sistema de control de versiones lógico que sea fácil de entender.

Cada implementación debe tener su propio repositorio de código que se pueda implementar en múltiples entornos. Evite alojar varias aplicaciones en el mismo repositorio. Esto hace que el control de versiones sea casi imposible de entender y las versiones se enredarán, lo que resultará en un trabajo sin valor agregado.

Principio II. Dependencias

«Declarar y aislar dependencias explícitamente»

Este principio mantiene que nunca debe confiar en la existencia implícita de paquetes para todo el sistema. En su lugar,»

• Asegúrese de que las bibliotecas específicas de la aplicación estén disponibles
• Verificar la descarga en el sistema operativo
• Verificar que las bibliotecas del sistema necesarias, como curl o ImageMagick, estén disponibles. (No hay garantía de que existan en todos los sistemas en los que la aplicación pueda ejecutarse en el futuro.)

En general, una aplicación de 12 factores debe contener automáticamente. La aplicación debe aislarse lo suficiente para evitar interacciones con bibliotecas conflictivas instaladas en la máquina host.

veamos un ejemplo. En Python, puede lograr la declaración y el aislamiento mediante el uso de Pip y Virtualenv, respectivamente. Para satisfacer este principio, siempre debe usar tanto la declaración de dependencia como el aislamiento. Administrar dependencias dentro de la aplicación, no desde una fuente externa. Las dependencias deben estar alojadas en un repositorio dentro de la aplicación

Principio III. Config

«Almacenar configuración en el entorno»

Una aplicación y su configuración debe ser completamente independiente. Además, se debe evitar por completo almacenar configuraciones constantemente en código.

Sus configuraciones deben tener un archivo separado y no deben estar alojadas en el repositorio de código. Un archivo de configuración independiente facilita la actualización de los valores de configuración sin tocar la base de código real, lo que elimina la necesidad de volver a desplegar sus aplicaciones cuando cambia ciertos valores de configuración.

Cuando las configuraciones se encuentran en el entorno, no en la aplicación, como variables, puede moverla fácilmente a otro entorno sin tocar el código fuente. La tienda de aplicaciones de doce factores se configura como variables para que sea «poco probable que se registren en el repositorio» accidentalmente. Otra ventaja: sus configuraciones son independientes del idioma y el sistema operativo.

Principio IV. Servicios de respaldo

«Tratar los servicios de respaldo como recursos adjuntos»

En una aplicación de 12 factores, se debe acceder como servicio a cualquier servicio que no admita la aplicación principal. Estos servicios esenciales no esenciales pueden incluir:

• Bases de datos
• Almacenamiento externo
• Colas de mensajes
• , Etc.

Estos pueden tratarse como un recurso. Se debe acceder a ellos como un servicio a través de HTTP o una solicitud similar, y luego se especifica en la configuración. De esta manera, la fuente del servicio se puede cambiar sin afectar el código central de la aplicación.

Por ejemplo, una aplicación que utiliza un sistema de colas de mensajes es mejor si puede cambiar fácilmente de RabbitMQ a ZeroMQ a ActiveMQ solo cambiando la información de configuración.

Principio V. Build, release, run

«Etapas de compilación y ejecución estrictamente separadas»

Una aplicación de 12 factores es estricta al separar las tres etapas de construcción, liberación y ejecución.

Inicie el proceso de compilación almacenando la aplicación en control de código fuente y, a continuación, cree sus dependencias. Separar la información de configuración significa que puede combinarla con la compilación para la etapa de lanzamiento—y luego está lista para la etapa de ejecución. También es importante que cada versión tenga un ID único.

Principio VI. Procesos

«Ejecutar la aplicación como uno o más procesos sin estado»

Almacenar los datos necesarios para persistir en un servicio de respaldo con estado, como las bases de datos. La idea es que el proceso es apátrida y no comparte absolutamente nada.

Mientras que muchos desarrolladores están acostumbrados a» sesiones adhesivas», almacenar información en la sesión que espera la siguiente solicitud será del mismo servicio contradice esta metodología.

Principio VII. Principio de enlace de puertos

«Exportar servicios a través de enlace de puertos»

Las aplicaciones de 12 factores siempre deben ser independientes de las aplicaciones adicionales. Cada función debe ser su propio proceso, en total aislamiento.

En un entorno tradicional, asumimos que diferentes procesos manejan diferentes funcionalidades. Como tal, es fácil asumir que estas funcionalidades están disponibles a través de un protocolo web, como HTTP, por lo que es probable que las aplicaciones se ejecuten detrás de servidores web, como Apache o Tomcat. Pero esto es contrario a la metodología de 12 factores.

En su lugar, agregue una biblioteca de servidor web o similar a la aplicación principal. Esto significa que la aplicación puede esperar solicitudes en un puerto definido, ya sea HTTP o un protocolo diferente.

Principio VIII. Concurrencia

«Escalar a través del modelo de proceso»

Una aplicación de 12 factores está diseñada para escalar. Cree sus aplicaciones para que el escalado en la nube sea perfecto. Al desarrollar la aplicación para que sea simultánea, puede activar nuevas instancias en la nube sin esfuerzo.

Para agregar más capacidad (iniciar procesos adicionales en máquinas adicionales), la aplicación debería poder agregar más instancias en lugar de más memoria o CPU en la máquina local.

Principio IX. Desechabilidad

«Maximice la robustez con un arranque rápido y un apagado elegante»

El concepto de procesos desechables significa que una aplicación puede morir en cualquier momento, pero no afectará al usuario: la aplicación se puede reemplazar por otras aplicaciones o se puede volver a iniciar de inmediato. La incorporación de la capacidad de eliminación en su aplicación garantiza que la aplicación se apague correctamente: debe limpiar todos los recursos utilizados y apagarse sin problemas.

Cuando se diseña de esta manera, la aplicación vuelve a funcionar rápidamente. Del mismo modo, cuando los procesos terminan, deben finalizar su solicitud actual, rechazar cualquier solicitud entrante y salir.

Principio de paridad X. Dev/prod

«Mantener el desarrollo, la preparación y la producción lo más similares posible»

Las aplicaciones desplegadas en desarrollo y producción deben tener paridad. En esencia, solo debería haber la más mínima diferencia entre ambos despliegues.

Una gran diferencia puede dar lugar a problemas de compatibilidad involuntarios entre el código de desarrollo y el de producción. Al crear una aplicación de 12 factores, los servicios de respaldo entre dev y prod deben ser los mismos; una diferencia aquí podría causar problemas significativos en el futuro.

Principio XI. Logs

«Tratar los registros como flujos de eventos»

A diferencia de las aplicaciones monolíticas y tradicionales que almacenan información de registro en un archivo, este principio mantiene que debe transmitir registros a una ubicación elegida, no simplemente volcarlos en un archivo de registro.

Normalmente, los registros no residen en el mismo lugar dentro de entornos basados en la nube después de cada grabación. A medida que se inician nuevos procesos o su aplicación se bloquea, los registros se distribuirán en varias máquinas en la nube; no se instalarán en una sola máquina o host.

Resuelva este problema nombrando un lugar común para que los registros se transmitan. En algunos casos, simplemente puede redirigir la salida estándar a un archivo. Sin embargo, es más probable que desee implementar un enrutador de registros como Fluentd y guardar los registros en Hadoop o en un servicio específico, como Splunk.

Principio XII. Procesos de administración

«Ejecutar tareas de administración/administración como procesos únicos»

El principio final de la aplicación de 12 factores propone separar las tareas administrativas del resto de su aplicación. Estas tareas pueden incluir la migración de una base de datos o la inspección de registros.

Aunque los procesos de administración son independientes, debe continuar ejecutándolos en el mismo entorno y en función del código base y la configuración de la propia aplicación. Enviar el código de tareas de administración junto con la aplicación evita la deriva.

Lectura relacionada

• Blog de desarrollo de BMC
• SDLCs Ágil frente a Cascada: ¿Cuál es la diferencia?
• Canalizaciones de implementación (CI/CD) en Ingeniería de Software
• ¿Qué es la Programación Extrema (XP)?
• Cómo & Por qué Convertirse en una Fábrica de Software
• Principales Conferencias para la programación & Desarrollo de software