Estado del arte del despliegue de aplicaciones GeneXus en 2022

Por: Gerardo Canedo 

Determinar dónde desplegamos las aplicaciones que construimos es crucial para lograr que las iniciativas de transformación digital sean eficaces y eficientes. En los últimos años, han surgido un sinfín de opciones que en la década pasada no se encontraban disponibles, cada una con sus ventajas y sus desafíos.

Hagamos un poco de historia. En la década del  2000, para desplegar una aplicación era necesario adquirir hardware. Antes de finalizar el desarrollo, se debía dimensionar qué requerimientos de Memoria, CPU y almacenamiento serían necesarios para un correcto funcionamiento de la solución. Para obtener alta disponibilidad, era necesario contar con hardware redundante. 

Este esquema conllevaba desafíos de dimensionamiento: Si se destinaba un hardware por debajo de lo necesario, en casos extremos podría implicar el descarte del equipamiento adquirido y la necesidad de comprar equipos más potentes. Por el contrario, si el hardware estaba sobredimensionado, implicaba una ineficiencia de la inversión. A su vez, se debían configurar y mantener distintas instancias de los sistemas operativos y el software de base en general, lo que requería un gran esfuerzo de administración y el riesgo que la aplicación funcionara de distinta manera en distintos ambientes (funciona OK en test, no así en producción).

Como respuesta a estos desafíos surgieron las tecnologías de virtualización. Para ser técnicamente exactos, este tipo de tecnología existía desde mucho antes, pero no era masiva ni se encontraba disponible en todas las plataformas.

Con la amplia adopción de la virtualización, un solo hardware podía alojar distintos sistemas (Máquinas Virtuales) en el mismo equipo/servidor, siendo completamente independientes uno del otro. Esto permitió que distintas aplicaciones utilizaran el software base en las versiones que requerían de forma independiente y un mejor aprovechamiento de los recursos: luego de construida y desplegada la aplicación era posible agregar o quitar recursos (CPU y memoria fundamentalmente) sin la necesidad de un cambio físico. En este paradigma, aún era necesario administrar los servidores: actualizar su software base y configurar el software de aplicación. Los problemas de inconsistencia entre distintos ambientes continuaban siendo una preocupación. En menor medida, continuaba siendo necesario adquirir hardware antes de desplegar las aplicaciones, invirtiendo en equipos/servidores para poder utilizarlo luego.

Con estos desafíos en mente, las nubes comenzaron a surgir y a hacerse cada vez más populares. Al principio, comenzaron brindando la facilidad de no tener que adquirir hardware para alojar nuestras aplicaciones: en el momento requerido, se instancian máquinas virtuales y comienzan a estar operativas. Con el tiempo, las nubes empezaron  a dar soporte a funcionalidades que buscaban facilitar la adopción de buenas prácticas y disminuir costos: gestión de logs, autenticación, alta disponibilidad y performance.

En paralelo, se comenzó a popularizar el concepto de contenedores: en vez de disponibilizar un sistema operativo completo, se genera una versión reducida únicamente con lo que se necesita. Adicionalmente, es posible incluir las configuraciones que hacen al correcto funcionamiento de la aplicación, lo que representa una gran ventaja de administración.

En adición a los contenedores (y con foco en aspectos de alta disponibilidad, monitoreo y disponibilidad), surgieron tecnologías como Kubernetes. Estas tecnologías buscan generar pods (unidades autocontenidas que poseen una imagen del software y sus configuraciones), desacoplando totalmente el ciclo de vida de ejecución de su construcción y configuración. Proveen tal grado de desacople, que a priori, puede conseguirse totalmente la abstracción del ambiente de ejecución, siendo escalado y migrado de hardware de forma transparente para el usuario final y el equipo de construcción del software.

También existen opciones nativas de la nube. Estas opciones parten de la base que ni tenemos un servidor web o de aplicaciones (“serverless”), ni una base de datos que gestionar (Database as a Service). En estos casos, es posible codificar nuestras necesidades de infraestructura y virtualmente olvidarnos de operar una infraestructura para la solución.

En las próximas semanas compartiremos nuevos post describiendo nuestra experiencia desplegando aplicaciones generadas con GeneXus (tanto web como mobile) en distintas configuraciones, desde Docker a AWS o Azure o Kubernetes.

A modo de conclusión: es posible utilizar estas nuevas formas de desplegar y operar aplicaciones construidas con GeneXus sin mayores sobresaltos, con grandes ganancias en la robustez, disponibilidad, gestión de logs, mitigación de errores de configuración y mantenibilidad.