La arquitectura de software está experimentando una revolución en la era del cloud computing y el desarrollo de aplicaciones modernas. El enfoque Twelve-Factor ha emergido como una metodología clave para diseñar sistemas robustos y escalables, adaptados a las exigencias del entorno digital actual. Esta metodología propone un conjunto de principios que guían la creación de aplicaciones nativas de la nube, mejorando la portabilidad y reduciendo la fricción en el despliegue de software.
El artículo explora la evolución de la arquitectura de software y cómo el Twelve-Factor se integra en las prácticas modernas de desarrollo. Se analizan los fundamentos de este enfoque, los desafíos en su adopción y las soluciones propuestas. Además, se examina el impacto del Twelve-Factor en DevOps y CI/CD, así como su relación con la arquitectura cloud-native. Esta guía ofrece una visión completa para los profesionales que buscan mejorar sus estrategias de desarrollo de aplicaciones y adaptarse a las tendencias actuales en la arquitectura empresarial.
Evolución de la Arquitectura de Software
De monolíticos a microservicios
Una aplicación monolítica se compila como una sola unidad unificada, mientras que una arquitectura de microservicios es una serie de servicios pequeños que se pueden implementar de forma independiente [1]. En 2009, Netflix tuvo problemas de crecimiento, ya que su infraestructura no podía seguir el ritmo de la demanda de sus servicios de streaming de video. En esta situación, la empresa decidió migrar su infraestructura de TI a una nube pública y reemplazar la arquitectura monolítica por otra de microservicios [1].
Una arquitectura monolítica es un modelo tradicional donde un programa de software se compila como una unidad unificada y autónoma [1]. Para hacer cambios, hay que actualizar toda la pila, lo que requiere acceder al código base, compilar e implementar una versión actualizada, haciendo que las actualizaciones sean restrictivas y lentas [1].
Por otro lado, una arquitectura de microservicios consiste en una serie de servicios que se pueden implementar de forma independiente, cada uno con su propia lógica empresarial y base de datos [1]. La actualización, las pruebas, la implementación y el escalado se llevan a cabo dentro de cada servicio [1]. En Atlassian, se pasó a la arquitectura de microservicios en 2018 debido a los desafíos de escalar sus productos monolíticos [1].
Los microservicios facilitan a los equipos la actualización del código y aceleran los ciclos de publicación con integración y entrega continuas (CI/CD) [1]. Aunque no reducen la complejidad, la hacen más visible y gestionable al separar las tareas en procesos más pequeños [1]. Sin embargo, también presentan desventajas como el desarrollo descontrolado, costes exponenciales de infraestructura, más sobrecarga organizativa, desafíos para la depuración, falta de estandarización y propiedad no clara [1].
El surgimiento de las aplicaciones cloud-native
Cloud Native es un patrón de arquitectura de software utilizado para desarrollar y operar servicios y aplicaciones que se ejecutan en un entorno de computación en la nube [2]. Las características principales de una aplicación "Cloud Native" incluyen:
- Arquitectura basada en microservicios: En lugar de construir una aplicación como un monolito único, se divide en componentes más pequeños y autónomos llamados microservicios, lo que permite mayor flexibilidad, escalabilidad y mantenimiento independiente [2].
- Contenedores: Las aplicaciones "Cloud Native" suelen empaquetarse en contenedores, que son entornos aislados que contienen todo lo necesario para que una aplicación se ejecute de manera consistente en diferentes entornos [2].
- Orquestación de contenedores: Se utilizan herramientas como Kubernetes para gestionar y coordinar la implementación, escalabilidad y el balanceo de carga de los contenedores [2].
- Escalabilidad dinámica: Están diseñadas para escalar automáticamente según la demanda, mejorando el rendimiento y la eficiencia [2].
- DevOps y automatización: Integran prácticas de automatización en todo el ciclo de vida de desarrollo y operación [2].
Las aplicaciones cloud native están optimizadas para el uso de máquinas virtuales y servicios en la nube, y se pueden implementar de forma ágil y flexible en entornos de computación en la nube pública, privada o híbrida [2].
El papel del Twelve-Factor
La metodología 12 Factor App resulta adecuada para transformar aplicaciones monolíticas en microservicios y para desarrollar aplicaciones nativas de la nube desde cero utilizando microservicios [3]. Sigue siendo muy pertinente hoy en día, sobre todo para crear aplicaciones nativas de la nube y basadas en microservicios [3].
La adhesión a la metodología puede ayudar a integrar la seguridad, la fiabilidad y la resiliencia en las aplicaciones [3]. Además, los lenguajes de programación modernos, los marcos de desarrollo y la naturaleza agnóstica de la plataforma de microservicios facilitan la adopción de estos 12 factores [3].
La metodología 12 factor App se presentó mediante una publicación, donde se explican sus objetivos: configuraciones automatizables y explícitas, dependencias claras con el entorno para máxima compatibilidad, la aplicación debe ser desplegada en la nube, despliegue continuo, y aplicaciones enfocadas en la escalabilidad [4].
Implementación de los Factores en la Arquitectura Moderna
Gestión de código y dependencias
Las aplicaciones modernas dependen de numerosas bibliotecas y plugins de software de terceros, tanto propietarios como de código abierto. [5] Estas dependencias pueden ser directas, referenciadas directamente por la aplicación, o transitivas, requeridas funcionalmente por las dependencias directas. [5] Algunos lenguajes de programación ofrecen mayor visibilidad sobre las dependencias y sus relaciones que otros. [5] Sin visibilidad de las dependencias indirectas, es muy difícil identificar y responder a vulnerabilidades y otros problemas que se originan en componentes que el código no referencia directamente. [5]
Para gestionar las dependencias de forma segura y confiable, se recomienda instalar directamente desde fuentes públicas, almacenar copias en el repositorio de código fuente (vendoring), o utilizar un registro privado. [5] El uso de archivos de bloqueo (lock files) permite especificar exactamente qué versión de cada dependencia debe instalarse, combinando el bloqueo de versiones con la verificación de firmas o hashes para todo el árbol de dependencias. [5] Además, es fundamental realizar escaneos de vulnerabilidades de forma automática y consistente para evaluar si las dependencias introducen vulnerabilidades en la aplicación. [5]
Configuración y entornos
La configuración de una aplicación incluye todo lo que puede variar entre despliegues, como recursos de bases de datos, credenciales de servicios externos y valores de despliegue. [6] Las aplicaciones "twelve-factor" almacenan la configuración en variables de entorno, que se modifican fácilmente entre despliegues sin cambiar el código. [6] Estas variables son controles granulares, cada una ortogonal a las otras, gestionadas independientemente para cada despliegue. [6]
La prueba para determinar si una aplicación tiene la configuración correctamente separada del código es comprobar si el código base puede convertirse en código abierto sin comprometer credenciales. [6] La definición de "configuración" no incluye configuraciones internas de la aplicación que no varían entre despliegues. [6]
Procesos y escalabilidad
Las aplicaciones "twelve-factor" utilizan formatos declarativos para la automatización de la configuración, minimizando el tiempo y coste de incorporar nuevos desarrolladores. [7] Tienen un contrato claro con el sistema operativo, ofreciendo máxima portabilidad entre entornos de ejecución. [7] Están diseñadas para desplegarse en plataformas en la nube modernas, obviando la necesidad de servidores y administración de sistemas. [7] Además, minimizan las diferencias entre entornos de desarrollo y producción, posibilitando el despliegue continuo para conseguir la máxima agilidad. [7]
Fundamentos del Enfoque Twelve-Factor
Definición y origen
La metodología de doce factores (12 Factor) fue creada en el año 2012 por varios desarrolladores de aplicaciones en Heroku y consiste en un enfoque o filosofía de trabajo en la que se deben considerar doce principios para desarrollar aplicaciones en la nube (Cloud Computing Apps) [3]. 12 Factor es principalmente un marco para construir aplicaciones de software como servicio – SaaS (Software as a Service) – en la nube [3].
Principios clave
La metodología "twelve-factor" establece que las aplicaciones SaaS deben:
- Utilizar formatos declarativos para la automatización de la configuración, minimizando el tiempo y coste de incorporar nuevos desarrolladores [7].
- Tener un contrato claro con el sistema operativo, ofreciendo máxima portabilidad entre entornos de ejecución [7].
- Ser apropiadas para desplegarse en plataformas en la nube modernas, obviando la necesidad de servidores y administración de sistemas [7].
- Minimizar las diferencias entre entornos de desarrollo y producción, posibilitando un despliegue continuo para conseguir máxima agilidad [7].
- Poder escalar sin cambios significativos en herramientas, arquitectura o prácticas de desarrollo [7].
- Tener dependencias claras con el entorno para máxima compatibilidad [3].
- Enfocarse en la escalabilidad [3].
Beneficios para el desarrollo de software
La metodología "twelve-factor" puede aplicarse a aplicaciones escritas en cualquier lenguaje de programación y con cualquier combinación de servicios de backend (bases de datos, colas, memoria caché, etc.) [7]. Algunos beneficios clave son:
- Configuraciones automatizables y explícitas [3]
- Despliegue continuo [7] [3]
- Máxima portabilidad y compatibilidad [7] [3]
- Enfoque en escalabilidad [7] [3]
Al seguir estos doce factores, las aplicaciones SaaS pueden construirse de manera óptima para entornos en la nube, facilitando su desarrollo, despliegue y mantenimiento a largo plazo.
Desafíos y Soluciones en la Adopción del Twelve-Factor
Obstáculos comunes
Adoptar una nueva tecnología o proceso como la metodología Twelve-Factor puede ser un desafío, y a menudo, las empresas enfrentan obstáculos cuando intentan implementar el cambio [8]. Estos obstáculos pueden variar desde resistencia al cambio, falta de comprensión y limitaciones presupuestarias [8].
Para superar la resistencia al cambio, es importante comunicar los beneficios de la nueva tecnología o proceso e involucrar a los empleados en el proceso de adopción [8]. Esto puede incluir brindar capacitación y apoyo, crear un sentido de propiedad y reconocer y recompensar a quienes aceptan el cambio [8].
Otro desafío común es la falta de comprensión [8]. Es posible que los empleados no comprendan completamente cómo funciona la nueva tecnología o proceso y que duden en adoptarlos [8]. Para superarlo, es importante proporcionar información clara y concisa, brindar capacitación, crear manuales de usuario y ofrecer soporte y orientación durante todo el proceso de adopción [8].
Estrategias de migración
Las restricciones presupuestarias también pueden ser un desafío al intentar adoptar Twelve-Factor [8]. Para superarlo, es importante considerar cuidadosamente los costos y beneficios, explorar diferentes opciones de financiamiento, como subvenciones, préstamos o asociarse con otras empresas u organizaciones, o invertir en un enfoque gradual para la adopción [8].
También pueden surgir problemas de compatibilidad al intentar adoptar Twelve-Factor [8]. Para superarlos, es importante considerar cuidadosamente las cuestiones de compatibilidad antes de adoptar la nueva tecnología o proceso, realizar un análisis de compatibilidad, buscar asesoramiento de expertos e invertir en las actualizaciones o modificaciones necesarias [8].
Casos de éxito
La falta de liderazgo también puede ser un desafío al intentar adoptar Twelve-Factor [8]. Para superarlo, es importante identificar y empoderar a los líderes dentro de la organización que puedan liderar el proceso de adopción, brindar capacitación y apoyo, reconocer y recompensar a quienes lideran el camino y crear una cultura de innovación y mejora continua [8].
A pesar de estos desafíos, numerosas empresas han adoptado con éxito la metodología Twelve-Factor, aprovechando sus beneficios en términos de escalabilidad, portabilidad y despliegue continuo [3] [7]. Empresas como Heroku, donde se originó la metodología, han sido pioneras en su implementación [3]. Otras empresas líderes en tecnología, como Netflix y Atlassian, también han migrado con éxito a arquitecturas de microservicios y aplicaciones nativas de la nube siguiendo los principios de Twelve-Factor [1].
Impacto del Twelve-Factor en DevOps y CI/CD
La metodología Twelve-Factor tiene un impacto significativo en las prácticas de DevOps y CI/CD (Integración Continua/Entrega Continua). Algunos de los aspectos clave son:
Automatización y despliegue continuo
Las aplicaciones "twelve-factor" utilizan formatos declarativos para la automatización de la configuración, minimizando el tiempo y coste de incorporar nuevos desarrolladores [7]. Tienen un contrato claro con el sistema operativo, ofreciendo máxima portabilidad entre entornos de ejecución [7]. Están diseñadas para desplegarse en plataformas en la nube modernas, obviando la necesidad de servidores y administración de sistemas [7]. Además, minimizan las diferencias entre entornos de desarrollo y producción, posibilitando el despliegue continuo para conseguir máxima agilidad [7].
Las herramientas como Cloud Build de Google pueden gestionar y automatizar las fases de construcción, lanzamiento y ejecución en múltiples lenguajes y entornos utilizando archivos de configuración de compilación en formato YAML o JSON [9]. Además, Cloud Deploy, un servicio totalmente gestionado, proporciona entrega continua a GKE, Cloud Run y GKE Enterprise, con pasos de aprobación y promoción sin problemas a múltiples entornos, así como un rollback de una aplicación desplegada en un solo paso [9].
Monitoreo y logging
Los registros (logs) brindan información sobre el estado de las aplicaciones [9]. Es importante desvincular la recopilación, el procesamiento y el análisis de registros de la lógica principal de las aplicaciones, especialmente cuando se requiere escalado dinámico y se ejecutan en nubes públicas, eliminando la sobrecarga de gestionar la ubicación de almacenamiento de registros y la agregación de máquinas virtuales distribuidas y a menudo efímeras [9].
En aplicaciones "twelve-factor", cada proceso en ejecución escribe sus eventos a la salida estándar (stdout) [10]. En entornos de preproducción y producción, cada transmisión del proceso es capturada por el entorno de ejecución y redirigida a uno o más destinos finales para su revisión y archivo, sin que la aplicación tenga que preocuparse por el direccionamiento o almacenamiento de sus transmisiones de salida [10].
Google Cloud ofrece una suite de herramientas que ayudan con la recopilación, el procesamiento y el análisis estructurado de registros [9]. Para aplicaciones en GKE, se pueden utilizar contenedores separados para tareas administrativas, aprovechando CronJobs en GKE, que ejecutan contenedores efímeros y permiten controlar la temporización, la frecuencia de ejecución y los reintentos si los trabajos fallan o tardan demasiado en completarse [9].
Gestión de configuración
Externalizar la configuración del código de la aplicación es crucial en el desarrollo de aplicaciones "twelve-factor" [3]. Este factor es un requisito previo para desarrollar software como servicio (SaaS) en 2022, y con proveedores de SaaS con CI/CD como GitHub, ACR Tasks y Circle CI, ahora es sencillo automatizar este proceso [3].
Las aplicaciones "twelve-factor" almacenan la configuración en variables de entorno, que se modifican fácilmente entre despliegues sin realizar cambios en el código [6]. Las variables de entorno son controles granulares, cada una ortogonal a las otras, gestionadas independientemente para cada despliegue [6]. La prueba de fuego para saber si una aplicación tiene toda su configuración correctamente separada del código es comprobar que el código base puede convertirse en código abierto en cualquier momento, sin comprometer las credenciales [6].
Arquitectura Cloud-Native y el Twelve-Factor
La metodología "twelve-factor" es principalmente un marco para construir aplicaciones de software como servicio (SaaS) en la nube [3]. Es adecuada para transformar aplicaciones monolíticas en microservicios y desarrollar aplicaciones nativas de la nube desde cero utilizando microservicios [3].
Diseño para la nube
Las aplicaciones "twelve-factor" están diseñadas para desplegarse en plataformas en la nube modernas, obviando la necesidad de servidores y administración de sistemas [7]. Separan completamente las fases de construcción, distribución y ejecución [11]. En la construcción, se traen todas las dependencias y se compilan los binarios para generar un artefacto. En la distribución, se usa esta construcción y se combina con la configuración. Finalmente, en la ejecución, se lanza la aplicación como un conjunto de procesos [11].
Las aplicaciones cloud-native están completamente autocontenidas y no dependen de un servidor web. La aplicación exporta HTTP como un servicio, siendo todo parte de la aplicación y solo se expone el puerto para atender peticiones [11].
Portabilidad entre entornos
Las aplicaciones "twelve-factor" tienen un contrato claro con el sistema operativo, ofreciendo máxima portabilidad entre entornos de ejecución [7]. Esto se logra utilizando contenedores, que son entornos aislados que contienen todo lo necesario para que una aplicación se ejecute de manera consistente en diferentes entornos [2]. Una de las ventajas más grandes de los contenedores es su portabilidad y comportamiento predecible entre diferentes ambientes [2].
Escalabilidad horizontal
La escalabilidad horizontal es esencial para lograr un escalado significativo en plataformas SaaS [3]. En los despliegues de Kubernetes, se puede ajustar fácilmente el número de pods para alcanzarla [3]. Sin embargo, para este objetivo es crucial contar con una arquitectura de software adecuada y es importante identificar las aplicaciones que requieren un escalado significativo desde el principio [3]. Twelve Factor App pretende promover la escalabilidad horizontal y romper con la era del escalado vertical [3].
En las aplicaciones "twelve-factor", los procesos son ciudadanos de primera clase [12]. El modelo de procesos muestra todo su potencial cuando llega el momento de escalar. La naturaleza "share-nothing" divide horizontalmente los procesos de las aplicaciones "twelve-factor" y se traduce en un aumento de la concurrencia como una operación simple y fiable [12].
Conclusión
La metodología Twelve-Factor ha transformado el panorama del desarrollo de software, ofreciendo una guía sólida para crear aplicaciones nativas de la nube. Esta metodología no solo mejora la escalabilidad y portabilidad de las aplicaciones, sino que también facilita prácticas de DevOps y CI/CD más eficientes. Al adoptar estos principios, las empresas pueden desarrollar software más resistente y adaptable a las demandas del entorno digital actual.
A medida que la industria sigue evolucionando, el enfoque Twelve-Factor seguirá siendo una herramienta valiosa para los desarrolladores y arquitectos de software. Su flexibilidad y enfoque en las mejores prácticas lo convierten en un recurso esencial para quienes buscan optimizar sus procesos de desarrollo. La adopción de esta metodología puede ser un paso significativo hacia una arquitectura de software más moderna y eficiente.
¿Si quieres saber más sobre cómo implementar estos principios en tu organización?
Contáctanos hoy mismo para una consulta gratuita.
FAQs
- ¿En qué consiste la metodología de diseño de 12 factores?
La metodología de diseño de 12 factores es un conjunto de prácticas recomendadas para desarrollar aplicaciones de software como servicio. Estas prácticas están orientadas a facilitar la creación de aplicaciones que sean portátiles y resilientes en entornos web. - ¿Cómo maneja la concurrencia una aplicación de 12 factores?
La concurrencia en una aplicación de 12 factores se refiere a la capacidad de la aplicación para gestionar varias solicitudes o tareas al mismo tiempo. Esta metodología promueve el uso de procesos sin estado, lo que significa que cada instancia de la aplicación funciona de manera independiente y no guarda información específica de los estados o datos de un usuario, facilitando así el escalado horizontal. - ¿Qué significa recursos adjuntos en el contexto de la aplicación de 12 factores?
En la metodología de 12 factores, los recursos como las bases de datos son tratados como recursos adjuntos. Esto implica que están débilmente acoplados con la aplicación a la que están conectados, permitiendo que se puedan vincular o desvincular fácilmente de las implementaciones cuando sea necesario. - ¿Qué relación existe entre las aplicaciones de 12 factores y los enfoques nativos de la nube?
Las aplicaciones de 12 factores son una metodología creada por los desarrolladores de Heroku para construir aplicaciones nativas de la nube. Estas aplicaciones utilizan formatos declarativos para la configuración, minimizando así el tiempo y el costo asociados a la incorporación de nuevos desarrolladores al proyecto.
Referencias
[1] - https://www.atlassian.com/es/microservices/microservices-architecture/microservices-vs-monolith
[2] - https://whitestack.com/es/blog/cloud-native/
[3] - https://www.aplyca.com/blog/12-factor-app-aplicaciones-exitosas-saas
[4] - https://www.aplyca.com/blog/cloud-native-principios-aplicaciones-y-desafios
[5] - https://cloud.google.com/software-supply-chain-security/docs/dependencies?hl=es-419
[6] - https://12factor.net/es/config
[7] - https://12factor.net/es/
[8] - https://fastercapital.com/es/tema/obst%C3%A1culos-comunes-para-la-adopci%C3%B3n-y-c%C3%B3mo-superarlos.html
[9] - https://cloud.google.com/architecture/twelve-factor-app-development-on-gcp?hl=es-419
[10] - https://12factor.net/es/logs
[11] - https://galvarado.com.mx/post/12-factor-apps-una-coleccion-de-patrones-de-arquitectura-ara-aplicaciones-cloud/
[12] - https://12factor.net/es/concurrency
0 Comentarios