Principios de aplicaciones de doce factores para desarrolladores

A medida que las aplicaciones web se hicieron populares en las últimas dos décadas, surgieron muchas mejores prácticas y principios para desarrollar y mantener aplicaciones web, incluido el conjunto de principios de aplicaciones de doce factores para crear aplicaciones web resistentes, escalables y de alto rendimiento.

Como sugiere el nombre, los principios de la aplicación de doce factores proporcionan 12 principios para crear aplicaciones web nativas de la nube modernas y basadas en microservicios. Fue presentado originalmente por Adam Wiggins en 2011. También es el cofundador de Heroku, que alguna vez fue una plataforma como servicio (PaaS) muy popular para ejecutar aplicaciones empresariales.

En esta publicación, exploraremos los 12 principios.

1 base de código

El principio del código base establece que los recursos de la aplicación deben tener un repositorio de código fuente administrado por versión, como Git o Subversión. Múltiples aplicaciones que comparten el mismo código es una violación de los principios de la aplicación de doce factores. La solución aquí es factorizar el código compartido en las bibliotecas que se pueden incluir a través del administrador de dependencias.

Según la metodología de aplicaciones de doce factores, una implementación es una instancia de una aplicación en el sistema del desarrollador, el sistema de desarrollo, el sistema de calidad y el sistema de producción, aunque pueden estar activas diferentes versiones en cada implementación (consulte la figura a continuación). Se puede acceder al código base para la integración continua/entrega continua (CI/CD) como parte del ciclo de desarrollo de software. El código base de un sistema puede estar sincronizado con cierto nivel de automatización mediante CI/CD.

2 dependencias

Cuando crea una aplicación, es común usar otros repositorios y herramientas reutilizables dentro de la aplicación que crea. Una forma fácil de manejar las dependencias es incluir esos códigos de biblioteca dependientes en su propia aplicación. Sin embargo, eso tiene la desventaja de mezclar el ciclo de vida del código de la aplicación y el código de la biblioteca dependiente.

Este principio especifica que las dependencias deben establecerse en el manifiesto de la aplicación o el archivo de configuración y administrarse externamente en lugar de incluirlas directamente en el código fuente.

si estás usando Nodo.jsespecificas las dependencias dentro de un paquete.json archivo (ver abajo). El administrador de paquetes de nodos (NPM) se encarga de descargar las versiones especificadas e instalarlas para que estén disponibles para que las use la aplicación. Del mismo modo, en un Java aplicación, establece las dependencias en un construir.gradle y el administrador de dependencias de Gradle se encarga de esas dependencias.

3 Configuración

Este principio establece que las configuraciones de una aplicación deben almacenarse independientemente del propio código, como variables de entorno o en un archivo de configuración.

Algunos ejemplos de datos de configuración son el nombre de host, el número de puerto y las credenciales. Estos datos de configuración son diferentes para cada uno de los entornos de despliegue donde se va a ejecutar la aplicación. Al separar dichos datos de configuración, facilitamos la ejecución de la aplicación en diferentes entornos simplemente aplicando los datos de configuración mantenidos de forma independiente al tiempo de ejecución.

La siguiente figura muestra que cuando se ejecuta en diferentes entornos, se ejecuta el mismo código base, pero se aplican diferentes conjuntos de datos de configuración en diferentes entornos.

4 servicios de respaldo

El principio del servicio de respaldo sugiere que los servicios como las bases de datos, los sistemas de mensajería, los servicios del Protocolo simple de transferencia de correo (SMTP), etc., deben diseñarse como recursos externos. La aplicación consume estos servicios de respaldo a través de la red.

Estos servicios pueden ser administrados localmente o proporcionados por terceros, como Amazon Simple Storage Service (Amazon S3) o Google Maps. Las direcciones URL, las credenciales, etc. deben mantenerse en un archivo de configuración y, cuando sea necesario reemplazar un servicio existente por otro, puede cambiar fácilmente los detalles en el archivo de configuración. Cada uno de estos servicios de respaldo se denomina recurso. En la figura a continuación, puede ver un ejemplo de una aplicación del modelo de programación de aplicaciones en la nube de SAP que accede a tres recursos diferentes.

5 Construya, Lance y Ejecute

Este principio establece que debe haber tres pasos independientes en su proceso de implementación (consulte la figura a continuación):

• El etapa de construcción convierte el repositorio de código en un paquete ejecutable. En esta etapa, todas las dependencias también se buscarán y compilarán en el paquete ejecutable.
• El etapa de lanzamiento combina las configuraciones de los archivos de configuración y las variables de entorno con el paquete ejecutable. La compilación resultante será un archivo ejecutable listo para ejecutarse en el entorno de ejecución.
• El etapa de carrera ejecuta la aplicación en el entorno de ejecución, que puede ser desarrollo, calidad o producción.

6 procesos sin estado

Este principio establece que las solicitudes deben tener la disposición de ser atendidas por múltiples procesos independientes sin estado, como se muestra en esta figura.

Considere que la solicitud de un usuario es atendida por el proceso 1. Las solicitudes subsiguientes deberían poder ser atendidas por el proceso 2 o cualquier otro proceso también. No se mantendrán datos de sesión en ninguno de los procesos, y cada proceso atiende la solicitud de forma independiente sin comunicarse con otros procesos. Cualquier dato que deba persistir debe usar un servicio de respaldo, como una base de datos.

Seguir este principio facilita la ampliación y reducción de la infraestructura, lo que la hace ideal para implementaciones en la nube.

Unión de 7 puertos

La aplicación de doce factores es una aplicación independiente que no requiere un servidor web para crear un servicio orientado a la web. En lugar de tener un servidor web para manejar las solicitudes y enviarlas a los servicios individuales, donde se crea la dependencia con el servidor web, una aplicación de doce factores se vincula directamente a un puerto y responde a las solicitudes entrantes (ver más abajo).

Un servicio individual puede actuar como un servicio de respaldo para otra aplicación proporcionando la URL del servicio de respaldo en la configuración de la aplicación de consumo.

8 Concurrencia

Este principio establece que la aplicación debe dividirse en varios módulos para que cada uno de esos módulos se pueda ampliar o reducir de forma independiente. Por ejemplo, las solicitudes HTTP pueden ser manejadas por un proceso web y un proceso de trabajo puede encargarse de los trabajos en segundo plano. Una vez más, estos procesos individuales se pueden escalar hacia arriba o hacia abajo para manejar el aumento de las cargas de trabajo de forma independiente.

9 Desechabilidad

Una aplicación de doce factores debería maximizar la solidez con un inicio rápido y un apagado ordenado. Los procesos deberían minimizar el tiempo de inicio e, idealmente, tardar unos segundos en iniciarse y recibir las solicitudes entrantes; ayuda mientras se amplían los procesos. Al mismo tiempo, los procesos deben cerrarse correctamente y dejar de escuchar en el puerto de servicio sin permitir ninguna solicitud entrante; en tales casos, si hay un sistema de colas, las solicitudes pueden ponerse en cola y procesarse una vez que los procesos están activos.

10 Paridad DEV/PROD

La metodología de aplicación de doce factores sugiere que el desarrollo, la puesta en escena y la producción de una aplicación se mantengan lo más similares posible. Una aplicación de doce factores debe diseñarse con el enfoque de CI/CD al hacer que la brecha de tiempo sea pequeña, donde el desarrollador escribe un código y lo implementa en horas o incluso minutos, y manteniendo DEV y PROD lo más similares posible. Esto elimina el riesgo de errores en la producción cuando se mueven nuevos cambios con diferentes versiones.

11 registros

Esta regla sugiere tratar los registros como flujos de eventos. Los registros suelen ser información de eventos ordenados por tiempo, o los registros pueden ser mensajes de error o éxito registrados por una aplicación. Una aplicación de doce factores nunca se preocupa por almacenar la información de registro en la aplicación, ya que puede morir y, como resultado, perder la información. En su lugar, la aplicación debe tratar las entradas de registro como secuencias de eventos y usar un servicio independiente para guardarlas. Estos pueden ser consumidos por partes interesadas para realizar análisis o para monitoreo.

12 procesos administrativos

El desarrollador a menudo necesita realizar actividades administrativas o de mantenimiento para aplicaciones que necesitan migración de datos, procesos en ejecución o scripts únicos. Estos también deben ser idénticos en diferentes entornos (DEV, QA y PROD). Estos procesos también deben enviarse junto con el código de la aplicación para evitar problemas de sincronización.

Nota del editor: Esta publicación ha sido adaptada de una sección del libro. Guía de certificación de SAP Extension Suite: examen de asociado de desarrollo por Krishna Kishor Kammaje, Mahesh y Kumar Palavalli.