Escenarios de desarrollo con GeneXus e instalación en producción.

Existen muchas forma de organizar el desarrollo de aplicaciones GeneXus. Esta variedad de escenarios, hace que a veces se dificulte el discutir sobre herramientas o procedimientos generales, pues algunos son buenos para un caso, pero no aplican o no son convenientes para otros escenarios. 

Quiero hacer una lista de cada uno de los que tengo identificados, para tratar de explicar pros y contras de cada uno. 

KB Monolítica - Empaquetado Monolítico - Instalación monolítica en una sola maquina

Es ideal para aplicaciones chicas, que no tengan requerimientos grandes de escalabilidad. Permite mantener sencillo el desarrollo y es como conviene empezar todos los desarrollos. 

El empaquetado es sencillo y la puesta en producción también. Hay que testear toda la aplicación para ponerla en producción. 

KB Monolítica - Empaquetado Monolítico - Instalación en mas de un nodo con base de datos compartida

Una unica KB, la cual se empaqueta en un único package, pero se instala en mas de un nodo para tener mejor performance y confiabilidad (se puede seguir operando en caso que un nodo funcione mal o se caiga). 

Tiene la desventaja que la aplicación hay que prepararla para la concurrencia y el balanceo de carga. Hay que preocuparse por mantener la sesión fuera de la aplicación. Si se realiza grabado de archivos, el mismo debe hacerse en lugares compartidos entre los nodos. 

KB Monolitica Modularizada - Empaquetado por Modulo - Instalacion en una unica maquina, separada por modulo

Este es un escenario que tiene muchas ventajas, pues todo el desarrollo se encuentra concentrado en único repositorio (la KB) pero se realiza el despliegue en servicios separados, lo cual le brinda mayor libertad de instalar solo una parte de la aplicación, sin afectar al resto. 

La interfaz entre los módulos tiene que estar bien definida y debería trabajarse en tener módulos desacoplados (lo más desacoplados posible). Hay que definir claramente a que módulo pertenece cada tabla y cada objeto del sistema y definir la menor cantidad posible de objetos públicos por modulo. 

El empaquetado es un poco mas complejo pues hay que definir diferentes Deployment Units para cada webapp diferente que quiera instalar. 

La dificultad de pasar de los escenarios anteriores a este, es que Modularizar da bastante trabajo y también es un poco trabajoso generar el empaquetado que lleve lo que se necesita y solo lo que se necesita. 

La puesta en producción, es relativamente sencilla, pues se tiene una única instancia de la aplicación y una base de datos única. 

Como contra tiene que puede necesitarse bajar la aplicación para la puesta en producción y que si necesitamos escalar alguno de los servicios, vamos a tener que hacer la instalación en mas de un nodo de toda la aplicación. 

Multiples KB que comparten el modelo de datos, Empaquetado por KB - Instalación con base de datos compartida

A este modelo se llega naturalmente cuando tengo una KB grande y la parto en KB mas chicas. 
Aun siguen compartiendo parte del modelo de datos, compartiendo algunas tablas, que por eficiencia se mantienen en una misma base de datos (para realizar los joins y los controles de integridad referencial en forma eficiente). 
El empaquetado es sencillo y la instalación también lo es. 
Hay que tener cuidado que las reorganizaciones originadas en una KB no afecten el funcionamiento de la otra KB.  Hay elementos compartidos que deberían sincronizarse entre las dos KB, por ejemplo dominios y atributos.  Exige coordinación importante entre los grupos que desarrollan la KB. 

Al tener proceso de deploy independientes, puede hacer en diferentes momentos. En caso de necesitar escalar más los servicios de un modulo, podría instalarse en mas de una maquina solo ese modulo, haciendo mucho más fácil el escalado. 

Multiples KB Independientes - Empaquetado por KB - Instalacion con base de datos independiente

En este escenario, la KB y las aplicaciones son independientes. Seguramente se comunican de a través de servicios de mensajería (colas de mensajes, ESB, web services, etc) con interfaces conocidas y que no cambian. 
Es equivalente a tener dos KB monolíticas con instalación monolítica (el primer caso de este post), pero con una KB mucho más chica. 
Es lo ideal para aplicaciones que necesiten alta escalabilidad y para realizar una instalación rápida de un modulo, sin afectar el resto del sistema.

Resumen

Este es una enumeración rápida de algunos de los escenarios que me he encontrado en los desarrollo con GeneXus.  Por supuesto que puede haber combinaciones para otras necesidades, pero creo que representan la mayoría de los casos actuales. 
Los desarrolladores deberíamos tener en cuenta en que escenarios vamos a utilizar las herramientas de desarrollo, empaquetado y puesta en producción, para poder entregar mas rápido nuestras aplicaciones funcionando correctamente a nuestro clientes, que al final del día, es lo único que importa. 

No hay un escenario que sea mejor que otro, solo que algunos hacen mas fácil una parte y otros escenarios hacen mas fácil  (o hacen posible) otro. 

Teniendo en cuenta facilidad en el desarrollo, tareas de empaquetado, tareas de puesta en producción, escalabilidad necesaria, tiempo de downtime permitido, etc, deberíamos evaluar que escenario nos conviene mas usar, a medida que nuestra aplicación evoluciona. Es algo dinámico que cambia el paso del tiempo y los avances técnicos.