Puntos clave: La metodología de la aplicación de 12 factores proporciona directrices para construir aplicaciones en la nube escalables, enfatizando la facilidad de despliegue y mantenimiento. Los principios clave incluyen el aislamiento de dependencias, la gestión de configuración y la desechabilidad de procesos, que mejoran la robustez y adaptabilidad de las aplicaciones.
- Céntrate en aplicaciones autónomas con dependencias aisladas.
- Fomenta un arranque rápido y un cierre eficiente de los procesos.
Escribir código de aplicaciones es anterior a la mayoría de las soluciones en la nube, soluciones para las que la mayoría de los programadores de aplicaciones escriben específicamente hoy en día.
Para manejar esta disonancia, ha surgido la metodología de la aplicación de 12 factores. Los 12 factores están un enfoque que ayuda a los programadores a escribir aplicaciones modernas de forma declarativa, usando contratos claros desplegados vía nube.
En este artículo, presentaré la metodología de aplicaciones de 12 factores y ofreceré un resumen general de sus principios.
¿Qué están la metodología de la aplicación de 12 factores?
En 2012, los programadores de Heroku presentaron la metodología de aplicaciones de 12 factores. Estos programadores han desarrollado y desplegado cientos de aplicaciones que han escrito esta metodología, basándose en su experiencia de ver aplicaciones SaaS "en la naturaleza".
Este grupo considera la metodología como una triangulación de:
- Prácticas ideales para apoyar el desarrollo de aplicaciones
- La dinámica que se produce cuando una app crece de forma orgánica
- La relación y colaboración entre desarrolladores de bases de código
[vídeo de hélice]
Sus objetivos son dos:
- Para ayudar a evitar costes de erosión del software
- Para concienciar sobre los problemas sistémicos que han observado en el desarrollo moderno de aplicaciones
El grupo señala dos fuentes inspiradoras, Patterns of Enterprise Application Architecture y Refactoring, ambas del desarrollador profesional Martin Fowler.
Y ahora, voy a presentar cada uno de los 12 factores.
Principio I. Base de código
"Una base de código rastreada en control de versiones, muchos despliegues"
Tu base de código debería tener un sistema lógico de control de versiones fácil de entender.
Cada despliegue debería tener su propio repositorio de código que pueda desplegarse en varios entornos. Evita alojar varias aplicaciones en el mismo repositorio. Esto hace que el control de versiones sea casi imposible de entender y las versiones se Obtén enredadas, resultando en trabajo sin valor añadido.
Principio II. Dependencias
"Declarar y aislar explícitamente dependencias"
Este principio sostiene que te nunca debería depender de la existencia implícita de paquetes a nivel de sistema. En su lugar"
- Haz seguro de que son disponibles bibliotecas específicas de cada app
- Verifica el pago al sistema operativo
- Verifica que las bibliotecas de sistema necesarias, como curl o ImageMagick, son disponibles. (No hay garantía de que existan en todos los sistemas donde la app pueda funcionar en el futuro.)
En general, una aplicación de 12 factores debe ser autónoma. La aplicación debe estar suficientemente aislada para evitar interacciones con bibliotecas en conflicto que son instaladas en la máquina anfitriona.
Veamos un ejemplo. En Python, te puedes lograr declaración y aislamiento usando Pip y Virtualenv respectivamente. Para cumplir este principio, te debes utilizar siempre tanto declaración de dependencia como aislamiento. Gestiona las 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. Configuración
"Almacena la configuración en el entorno"
Una aplicación y su configuración deben ser completamente independientes. Además, almacenar configuraciones constantemente en el código debe evitarse por completo.
Tus configuraciones deberían tener un archivo separado y no deberían estar alojadas dentro del repositorio de código. Un archivo de configuración separado facilita actualizar los valores de configuración sin tocar la base de código real, eliminando la necesidad de volver a desplegar tus aplicaciones cuando te cambiar ciertos valores de configuración.
Cuando las configuraciones son en el entorno, no en la app, como variables, te puede moverlas fácilmente a otro entorno sin tocar el código fuente. Las apps de doce factores almacena configuraciones como variables para que son "poco probable que se registren accidentalmente en el repositorio". Otro plus: entonces tus configuraciones son independientes del lenguaje y del sistema operativo.
Principio IV. Servicios de respaldo
"Tratar los servicios de respaldo como recursos vinculados"
En una aplicación de 12 pasos, cualquier servicio que no soporte la aplicación central debe ser accedido como un servicio. Estos servicios esenciales no esenciales pueden incluir:
- Bases de datos
- Almacenamiento externo
- Colas de mensajes
- Etcétera.
Estos pueden tratarse como un recurso. Deben accederse a estos como un servicio mediante HTTP o una solicitud similar, y luego especificarse en la configuración. De este modo, el código fuente del servicio puede cambiarse sin afectar al código central de la aplicación.
Por ejemplo, una aplicación que utiliza un sistema de cola de mensajes están mejor si puede cambiar fácilmente de RabbitMQ a ZeroMQ y luego a ActiveMQ solo cambiando la información de configuración.
Principio V. Construir, soltar, correr
"Etapas de construcción y ejecución estrictamente separadas"
Una aplicación de 12 factores está estricta separando las tres etapas de construcción, lanzamiento y ejecución.
Comienza el proceso de compilación almacenando la app en control de versiones y luego desarrollando sus dependencias. Separar la información de configuración significa que te puedes combinarla con la compilación para la etapa de lanzamiento—y entonces estará 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"
Almacena cualquier dato que están necesario para persistir en un servicio de respaldo con estado, como bases de datos. La idea está que el proceso están sin estado y no comparte absolutamente nada.
Aunque muchos desarrolladores son acostumbrados a las "sesiones fijas", almacenar información en la sesión esperando que la siguiente petición venga del mismo servicio contradice esta metodología.
Principio VII. Principio de enlace de puerto
"Exportar servicios mediante enlace de puertos"
Las aplicaciones de 12 factores deben ser siempre independientes de aplicaciones adicionales. Cada función debe ser un proceso propio—en total aislamiento.
En un entorno tradicional, asumimos que diferentes procesos manejan distintas funcionalidades. Por tanto, es fácil asumir aún más que estas funcionalidades son disponibles a través de un protocolo web, como HTTP, lo que hace probable que las aplicaciones se ejecuten detrás de servidores web, como Apache o Tomcat. Pero esto está en contra de la metodología de los 12 pasores.
En su lugar, añade una biblioteca de servidor web o similar a la aplicación principal. Esto significa que la app puede esperar solicitudes en un puerto definido, ya sea HTTP o otro protocolo.
Principio VIII. Concurrencia
"Escalar a través del modelo de proceso"
Una verdadera aplicación de 12 factores están diseñada para escalar. Construye tus aplicaciones de modo que el escalado en la nube están fluido. Cuando te desarrollar la app para que sea concurrente, te puedes lanzar nuevas instancias a la nube sin esfuerzo.
Para añadir más capacidad (Comienza procesos adicionales en más máquinas), tu app debería poder añadir más instancias en lugar de más memoria o CPU en la máquina local.
Principio IX. Descartabilidad
"Maximiza 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 app puede ser reemplazada por otras apps, o puede Comienza de nuevo. Incorporar la desechabilidad en tu app garantiza que la app se cierre con elegancia: debe limpiar todos los recursos utilizados y cerrarse de forma fluida.
Cuando se diseña así, la app vuelve a funcionar rápidamente. Del mismo modo, cuando los procesos terminan, deben terminar su solicitud actual, rechazar cualquier solicitud entrante y salir.
Principio X. Paridad desarrollo/producción
"Mantén el desarrollo, la puesta en escena y la producción lo más similares posible"
Las aplicaciones desplegadas para desarrollo y producción deberían tener paridad. Esencialmente, debería haber solo una mínima diferencia entre ambos despliegues.
Una gran diferencia puede provocar problemas de compatibilidad no intencionados entre el código de desarrollo y el de producción. Al construir una aplicación de 12 pasos, los servicios de respaldo entre desarrollador y producción deben ser los mismos; una diferencia aquí podría causar problemas importantes más adelante.
Principio XI. Registros
"Trata los registros como flujos de eventos"
A diferencia de las aplicaciones monolíticas y tradicionales que almacena información de registro en un archivo, este principio sostiene que te debe transmitir los registros a una ubicación elegida, no simplemente volcarlos en un archivo de registro.
Normalmente, los logs no residen en el mismo lugar dentro de entornos en la nube tras cada quemado. A medida que Comienza nuevos procesos o tu app se bloquea, los logs se distribuyen entre varias máquinas en la nube; no se quedarán en una sola máquina o host.
Soluciona este problema nombrando un lugar común para que los logs se transmitan. En algunos casos, te simplemente redirigir Stdout a un archivo. Sin embargo, lo más probable es que te quieras desplegar un router de logs como Fluentd y guardar los logs en Hadoop o en un servicio específico, como Splunk.
Principio XII. Procesos administrativos
"Ejecutar tareas administrativas/de gestión como procesos puntuales"
El principio final de la aplicación de 12 factores propone separar las tareas administrativas del resto de tu aplicación. Estas tareas pueden incluir migrar una base de datos o inspeccionar registros.
Aunque los procesos administrativos son separados, te debe seguir ejecutándolos en el mismo entorno y contra el código base y la configuración de la propia aplicación. Enviar el código de tareas administrativas junto con la aplicación evita la deriva.
Lecturas relacionadas
Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.