12-factores-metologías-equipo-desarrollo-itequia

La metodología de los 12 factores para la creación de aplicaciones

En el mundo actual de la tecnología, es fundamental adaptarse a las demandas del mercado y ofrecer soluciones eficientes. En este sentido, el concepto de los 12 factores es la guía clave para construir aplicaciones eficientes y adaptables. Estos factores proporcionan pautas claras y prácticas que permiten el desarrollo de aplicaciones con un despliegue fácil y escalable en diferentes entornos. Al seguir estas directrices, los equipos de desarrollo pueden garantizar la entrega rápida y frecuente de aplicaciones, satisfaciendo las necesidades cambiantes de los usuarios en un entorno tecnológico en constante evolución. 

En este artículo, exploraremos cómo los 12 factores (The Twelve-Factor App) pueden potenciar y evolucionar nuestras aplicaciones. Descubriremos cómo cada factor desencadena cambios significativos en el diseño y desarrollo de software. Construyendo aplicaciones más resilientes, escalables y fáciles de mantener.  

Acompáñanos en este viaje para transformar la forma en que construimos y desplegamos aplicaciones con los 12 factores.

Metología-de-los-12-factores

Los desafíos de la entrega rápida

En un entorno dinámico, los equipos de desarrollo enfrentan desafíos significativos para la entrega rápida de valor. Estos incluyen mantener la calidad del código, gestionar dependencias externas y garantizar una implementación fluida. Es en este contexto que los 12 factores se destacan como una guía invaluable. 

Los 12 factores proporcionan directrices claras y prácticas para abordar estos desafíos específicos. Los factores abordan la necesidad de adoptar arquitecturas y prácticas para un despliegue fácil y escalable en diversos entornos. Están alineados con los principios de entrega iterativa, colaboración y adaptabilidad.

En este artículo exploraremos cómo los 12 factores abordan los desafíos, mejoran la calidad del código y la gestión de dependencias externas. También veremos cómo facilitan las implementaciones sin problemas. Únete a nosotros en este viaje para comprender la importancia de los 12 factores. Descubre cómo pueden transformar la forma en que construimos y desplegamos aplicaciones en un entorno altamente competitivo.

Factor 1: Código base (Codebase) 

En la metodología twelve-factor, el código base es el repositorio utilizado para controlar versiones y realizar múltiples despliegues de una aplicación. Se gestiona a través de un sistema de control de versiones como Git, Mercurial o Subversion. 

Cada aplicación twelve-factor tiene un único código base. Compartir código entre diferentes aplicaciones se considera una violación de esta metodología y se recomienda separar el código compartido en bibliotecas. 

Aunque puede haber múltiples despliegues de una aplicación, todos se basan en el mismo código base. Pueden existir diferentes versiones del código en cada despliegue, pero siguen siendo identificados como despliegues de la misma aplicación. 

El código base es fundamental para garantizar la consistencia y escalabilidad de la aplicación a lo largo del tiempo. 

Factor 2: Dependencias 

En la metodología twelve-factor, es esencial declarar y aislar explícitamente las dependencias de una aplicación. Esto se logra mediante la declaración completa y explícita de las bibliotecas y dependencias en un archivo de manifiesto. Además, se utilizan herramientas de aislamiento durante la ejecución para evitar conflictos con otras partes del sistema. 

Declarar las dependencias de manera explícita facilita la configuración de nuevos desarrolladores. Solo necesitan instalar el entorno de ejecución del lenguaje y las herramientas de gestión de dependencias. Además, las aplicaciones twelve-factor no deben depender de herramientas externas del sistema. En su lugar, deben incluirlas internamente para garantizar su disponibilidad en cualquier entorno.

En twelve-factor, el factor de dependencias implica declarar y aislar explícitamente las dependencias de la aplicación para garantizar consistencia y portabilidad.

Factor-2-Dependencias

Factor 3: Configuración

En la metodología twelve-factor, se enfatiza en separar la configuración de la aplicación del código base. La configuración incluye todo lo que puede variar entre los diferentes despliegues. Esto abarca recursos de bases de datos, credenciales para servicios externos y valores específicos del entorno.

Es importante evitar guardar configuraciones como constantes en el código, ya que esto viola el principio de separación entre configuración y código. En su lugar, se recomienda almacenar la configuración en variables de entorno, que pueden modificarse fácilmente sin necesidad de realizar cambios en el código. Las variables de entorno son estándar en todos los lenguajes y sistemas operativos, y su uso evita la posibilidad de que la configuración sensible se guarde accidentalmente en el repositorio de código. 

En lugar de clasificar la configuración en grupos o entornos predefinidos, como development, test y production, en la metodología twelve-factor se gestionan las variables de entorno de manera independiente para cada despliegue. Esto evita la necesidad de crear constantemente nuevos entornos a medida que la aplicación crece, lo que puede generar una gestión complicada y frágil de la configuración. 

Factor 4: ”Backing services”

En la metodología twelve-factor, los backing services son recursos conectables para la aplicación, como bases de datos, sistemas de mensajería, servicios de email y sistemas de cache, que se consumen a través de la red.

No hay distinción entre servicios locales y servicios de terceros; ambos se consideran recursos conectados y se acceden a través de una URL o una identificación almacenada en la configuración. Esto facilita la sustitución de servicios locales por servicios de terceros sin modificar el código. Por ejemplo, se puede cambiar una base de datos local por una gestionada por un proveedor externo mediante la actualización de la configuración.

Cada “backing service” se trata como un recurso separado. Por ejemplo, dos bases de datos MySQL utilizadas para el sharding se consideran recursos distintos. Una aplicación twelve-factor trata estos recursos como entidades conectadas, lo que demuestra un bajo acoplamiento con el despliegue específico.

Los recursos pueden conectarse y desconectarse según sea necesario. Por ejemplo, si una base de datos tiene problemas, se puede cambiar a un nuevo servidor de bases de datos restaurado desde una copia de seguridad sin modificar el código.

El factor de los backing services en twelve-factor implica tratar los servicios utilizados por la aplicación como recursos conectables, sin importar si son locales o de terceros. Esto brinda flexibilidad y agilidad en la gestión de los servicios subyacentes sin afectar al código de la aplicación.

Factor 5: Construir, distribuir, ejecutar

En la metodología twelve-factor, se separan claramente las etapas de construcción, distribución y ejecución del código. 

Construcción: Se convierte el código en un paquete ejecutable con todas las dependencias necesarias. 

Distribución: Se combina la construcción con la configuración para crear una distribución lista para ejecutarse. 

Ejecución: Se ejecuta la aplicación utilizando una distribución específica. 

Estas etapas se mantienen separadas y no se realizan cambios en el código durante la ejecución. Se utilizan herramientas de gestión de distribuciones para facilitar la reversión a versiones anteriores. 

Cada vez que se despliega nuevo código, se crea una nueva construcción. La fase de ejecución es estable y puede ocurrir automáticamente, mientras que la fase de construcción es más compleja y requiere atención. 

“Construir, distribuir, ejecutar” en twelve-factor implica separar las etapas de construcción, distribución y ejecución, garantizando un despliegue ordenado y controlado de la aplicación. 

Factor 6: Procesos 

En la metodología twelve-factor, la aplicación se ejecuta como uno o más procesos sin estado en el entorno de ejecución. Los procesos son independientes y no comparten información entre sí. 

Los procesos twelve-factor no mantienen estado. Cualquier información que necesite persistencia se guarda en un backing service con estado, como una base de datos.

El espacio de memoria y el sistema de archivos se utilizan como una cache temporal para transacciones. Pero nunca se asume que esta información estará disponible para procesos posteriores. Incluso un reinicio del proceso eliminará todo el estado local. 

En lugar de depender de sticky sessions para mantener información de sesión, se recomienda utilizar almacenes de información con mecanismos de expiración, como Memcached o Redis. 

En twelve-factor los procesos se ejecutan sin estado y cualquier información persistente se guarda en un backing service. Se evita depender de la memoria o el sistema de archivos para almacenar datos, y se utiliza almacenamiento externo adecuado para la información de sesión.  

Factor 7: Asignación de puertos (Port binding) 

En el factor Port binding de twelve-factor, las aplicaciones web se ejecutan como servicios independientes sin depender de un servidor web.  

La aplicación misma escucha las solicitudes en un puerto asignado y se accede a ella a través de una URL específica.  

Esta asignación de puertos permite que las aplicaciones sean autocontenidas y puedan actuar como servicios web públicos.  

Además, diferentes servicios también pueden utilizar la asignación de puertos para ofrecer sus funcionalidades a otras aplicaciones. 

Factor 8: Concurrencia 

En el factor Concurrencia de “twelve-factor”, las aplicaciones se ejecutan mediante un modelo de procesos que permite escalar y manejar cargas de trabajo diversificadas. Los procesos en ejecución representan la escalabilidad de la aplicación, mientras que los diferentes tipos de procesos representan la diversidad de la carga de trabajo. 

En las aplicaciones twelve-factor, los procesos son tratados como ciudadanos de primera clase. El modelo de procesos se basa en el modelo de procesos de Unix y permite distribuir la ejecución de la aplicación asignando cada tipo de trabajo a un tipo de proceso específico. Por ejemplo, las solicitudes HTTP pueden ser procesadas por un tipo de proceso, mientras que las tareas intensivas pueden ser manejadas por hilos. 

Es importante tener en cuenta que los procesos deben gestionar su propia división interna mediante threads o modelos asíncronos. Además, el modelo de procesos permite escalar horizontalmente dividiendo los procesos en múltiples máquinas físicas. 

Factor 9: Desechabilidad

En las aplicaciones twelve-factor, los procesos son desechables, lo que significa que pueden iniciar y finalizar rápidamente según sea necesario. Esto permite una escalabilidad ágil, un despliegue rápido de cambios y una mayor robustez en producción. 

Los procesos deben minimizar el tiempo de arranque para facilitar la distribución y el escalado. Se detienen de manera segura al dejar de escuchar en el puerto asociado al servicio. 

Los trabajadores devuelven los trabajos en curso a una cola para una finalización segura. Los procesos deben estar preparados para enfrentar finalizaciones inesperadas, utilizando sistemas de colas robustos. 

Es importante poder iniciar y detener los procesos sin afectar la aplicación en su conjunto. El uso de herramientas de gestión de procesos o contenedores facilita el control. También brinda agilidad en la entrega y manejo de errores. En resumen, la desechabilidad hace que el sistema sea más robusto al lograr inicios rápidos y finalizaciones seguras. 

Factor 10: Igualdad entre desarrollo y producción 

En las aplicaciones twelve-factor, se busca igualar los entornos de desarrollo y producción mediante despliegues continuos y el uso de los mismos backing services.

Esto implica reducir el tiempo entre despliegues, involucrar a los desarrolladores en producción y minimizar las diferencias de herramientas.  

Es importante evitar la práctica de usar servicios diferentes en desarrollo y producción, ya que puede generar errores y afectar la estabilidad de la aplicación.  

Los sistemas de gestión de paquetes y las herramientas de virtualización facilitan la creación de entornos similares a producción.  

Se recomienda utilizar el mismo tipo y versión de cada servicio en todos los despliegues.  

En resumen, el factor 10 busca la paridad entre desarrollo y producción. 

Factor 11: Historiales 

Los historiales en una aplicación twelve-factor se tratan como transmisiones de eventos que permiten observar el comportamiento durante la ejecución. En lugar de gestionar ficheros de historial, cada proceso escribe sus eventos en la salida estándar. Durante el desarrollo, los desarrolladores pueden ver el flujo en su terminal. 

En despliegues de preproducción y producción, las transmisiones de eventos son capturadas por el entorno de ejecución. Posteriormente, son redirigidas a destinos finales para su revisión y archivo. Estos destinos son gestionados por el entorno de ejecución y pueden ser herramientas de código abierto como Logplex y Fluentd. 

Los historiales pueden ser redirigidos a ficheros o visualizados en tiempo real. Además, pueden ser enviados a sistemas de análisis como Splunk o a sistemas de almacenamiento de datos como Hadoop/Hive. Estos sistemas ofrecen la capacidad de buscar eventos pasados, crear gráficas de tendencia y activar alertas personalizadas. 

El factor 11 trata los historiales como transmisiones de eventos. Esto elimina la necesidad de gestionar ficheros de historial y permite su revisión y análisis en tiempo real.

Factor-11-Historiales

Factor 12: Administrador de procesos 

En las aplicaciones twelve-factor, las tareas de gestión y administración se ejecutan como procesos independientes que se ejecutan una sola vez. Estos procesos incluyen migraciones de bases de datos, consolas interactivas y scripts de mantenimiento. 

Se utilizan las mismas técnicas de aislamiento y entorno que los procesos habituales de la aplicación. El código de administración se envía junto con el código de la aplicación para mantener la sincronización. 

Se recomienda el uso de lenguajes con consolas REPL para facilitar la ejecución de scripts de administración. En entornos locales, se ejecutan desde la consola del directorio de la aplicación. En producción, se utilizan mecanismos remotos como SSH. 

El factor 12 establece que las tareas de administración se ejecutan como procesos independientes, utilizando el mismo entorno y técnicas de aislamiento que los procesos habituales. 

Beneficios de seguir los 12 factores:  

Seguir los 12 factores ofrece una serie de beneficios significativos. Estos beneficios incluyen: 

  • Mayor flexibilidad: Los 12 factores proporcionan directrices claras para construir aplicaciones adaptables. Al seguir estos principios, las aplicaciones se vuelven más flexibles. Pueden adaptarse fácilmente a cambios en los requisitos del negocio. También pueden ajustarse a cambios en el entorno operativo.
  • Facilidad para escalar: Los 12 factores promueven la separación de preocupaciones. También fomentan el uso de servicios escalables, facilitando la escalabilidad de las aplicaciones. Al diseñar la arquitectura de acuerdo con estos factores, las aplicaciones pueden crecer y adaptarse sin problemas. Pueden manejar un mayor volumen de usuarios o demanda.
  • Mejor mantenibilidad: Los 12 factores enfatizan la modularidad, la claridad en el código y la gestión adecuada de las dependencias. Estas prácticas conducen a aplicaciones más mantenibles. Es más fácil identificar y solucionar problemas, realizar actualizaciones y realizar cambios sin afectar otras partes del sistema.
  • Despliegue más rápido: Los 12 factores promueven el desacoplamiento de la configuración del entorno. Esto facilita el despliegue rápido y consistente de las aplicaciones en diferentes entornos. Al seguir estas pautas, el proceso de despliegue se vuelve más automatizado y repetible. Esto permite entregar nuevas versiones de la aplicación de manera más eficiente.
  • Mayor eficiencia operativa: Los 12 factores fomentan prácticas como el monitoreo, el registro y la administración de recursos. Al implementar estos factores, las aplicaciones se vuelven más eficientes en términos de uso de recursos, detección de problemas y optimización del rendimiento. Esto resulta en una mejor eficiencia operativa y un menor tiempo de inactividad. 

En definitiva, los 12 factores son cruciales para la entrega escalable de aplicaciones

En la era actual, la aplicación de los conceptos de los 12 factores se ha vuelto crucial para garantizar una entrega rápida, escalable y sin problemas de aplicaciones. 

Al seguir estas pautas, los equipos de desarrollo pueden evolucionar sus aplicaciones de manera efectiva y adaptarse a los cambios constantes del entorno tecnológico actual.  

La adopción de prácticas como el control de versiones, la gestión de dependencias, la separación de etapas y el uso de herramientas modernas de automatización e infraestructura contribuye a construir aplicaciones robustas y flexibles. 

La implementación de los 12 factores allana el camino para el éxito en la entrega de aplicaciones en la era digital en constante evolución. 

Si tu organización busca apoyo para implementar proyectos de desarrollo de aplicaciones con expertos en la materia, te invitamos cordialmente a que nos contactes.

Itequia Team