Pasar una KB de monolitica a servicios distribuidos
Una de las tareas que tenemos por delante quienes desarrollamos con GeneXus desde hace mucho tiempo es pasar algunos de nuestros desarrollos que vienen de versiones anteriores de GeneXus en una KB monolítica, a varias KB interconectadas.
Los motivos de este cambio, no es caprichoso, sino que hoy que esta motivado por la necesidad de nuestros clientes de tener los cambios mas rapido y nosotros necesitamos instalar con mucha mayor frecuencia que lo que hacíamos antes.
En una KB monolítica, teníamos que esperar a tener TODO el sistema en un estado instalable, y los que desarrollamos sabemos que el tiempo de estabilización de los cambios para que sea instalable es proporcional a la cantidad de objetos, cantidad de desarrolladores y cantidad de cambios introducidos.
La mejor solución que ha encontrado la industria para este problema, es el clásico "divide & conquer". Cuando tengo un problema grande que no puedo resolver en un tiempo limitado, es mejor dividirlo en problemas mas pequeños y de esta forma puedo obtener una solución, que si bien no es optima, permite entregar mas rapido un resultado. En nuestro caso, tenemos una KB Grande y la vamos a pasar a varias KB bastante mas chica para lograr este resultado.
Como dividir una KB?
La tarea de dividir una KB, no es una tarea fácil. Lo importante a tener en cuenta es que para que nuestra aplicación se mantenible en el futuro con varias KB, cada objeto debe estar en una y solo una de las KB, para no tener problemas de actualizarla en una y no en otra.
Esta limitación, nos lleva al problema de que hacer con objetos compartidos, que quienes hace años desarrollamos con GX conocíamos como el CORE (conjunto de objetos que teníamos en varias KB y se compartían en el CONSOLIDADO).
En esta charla (que recomiendo que vean) sobre Modelado de Arquitecturas Complejas y Sistemas de Misión Crítica con GeneXus, Gonzalo cuenta como hicieron ellos para aplicar una metodología para dividir una KB.
La metodología recomendada es:
* Usar Deployment Units para el deploy
* Modularizar la KB
* Definir interfaces entre módulos
* Todas las reorganizaciones deben permitir a la version anterior de la aplicación seguir funcionando
La metodologíaque hemos utilizado es la siguiente
Automatizar el build & deploy.
Si queremos ser agiles en la instalación de nuevas versiones, tenemos que hacer esta tarea fácil. Con las herramientas actuales, es "facil" hacer un script que instale una nueva version en un ambiente de test.
Conviene que ese script sea lo mas completo posible, o sea que parta de la KB, especifique, compile, empaquete la aplicación y la reorganización de la base de datos, si la hubiera.
Luego también conviene hacer otro que arme toda la infraestructura necesaria (cree las webapps, directorios, ajuste archivos de configuración, etc) para lograr tener una aplicación funcionando.
Lo ideal seria partiendo de la KB, poder llegar a armar una instalación en un ambiente de TEST solamente corriendo un par de scripts.
Conviene que ese script sea lo mas completo posible, o sea que parta de la KB, especifique, compile, empaquete la aplicación y la reorganización de la base de datos, si la hubiera.
Luego también conviene hacer otro que arme toda la infraestructura necesaria (cree las webapps, directorios, ajuste archivos de configuración, etc) para lograr tener una aplicación funcionando.
Lo ideal seria partiendo de la KB, poder llegar a armar una instalación en un ambiente de TEST solamente corriendo un par de scripts.
Para esto se recomienda el uso de las Deployment Units en Genexus y también la integracion continua.
Una ventaja de automatizar el build & deploy es que se puede responder mas rapido a los errores, pues solo tengo que corregir el programa con errores y a partir de ahi en adelante, la tarea está automatizada.
Modularizar la KB
Dividir la KB en módulos y lograr que dichos módulos estén levemente acoplados, o sea que compartan la menor cantidad de objetos entre ellos. Esto se logra, minimizando la cantidad de objetos privados que tengo en cada modulo. Da trabajo, pero vale la pena.
A su vez, hay que lograr que los objetos del modulo tengan alta cohesion, o sea que hay que mover a un modulo aquellos objetos que se relacionan fuertemente. Por ejemplo, todos los objetos relacionados con el manejo de clientes, puede convenir ponerlos en un mismo modulo.
Una vez que tengo una KB monolítica, con módulos internos, es mucho mas fácil elegir un modulo y extraerlo hacia una KB independiente. Esto debería evaluarse muy bien en cada caso.
Definir el propietario de una tabla.
En la charla de Gonzalo, habla de tener muy bien definido el dueño de los datos o sea que cada tabla sea modificada únicamente en un modulo. Esto es FUNDAMENTAL para mantener la consistencia de datos, sobre todo si luego vamos a dividir la KB en varias. Hoy esto es algo que se hace manualmente, y en particular tengo varios reportes en el KBDoctor que ayudan con el tema.
Hoy no es posible modelar o especificar de forma completa el propietario de una tabla en GeneXus y
seria de mucha utilidad que se incorpore el concepto en la KB.
seria de mucha utilidad que se incorpore el concepto en la KB.
Si una tabla es privada en un Modulo, únicamente va a poder ser accedida por ese modulo, y entonces todo esta bien.
Por temas de integridad referencial, hay muchas tablas que no pueden ser declaradas como privadas.
Ahora, si la tabla es publica, voy a poder leerla y grabarla desde el modulo a que pertenece pero también puede ser grabada desde otros módulos y no tengo forma de evitarlo. Seria bueno poder tener tablas que fueran PUBLICAS/READ ONLY para los demás módulos y de esta forma, nos aseguramos que el propietario de dicha tabla es el modulo al cual pertenece.
Test Unitarios
Conviene armar un ambiente donde se puedan ejecutar los test unitarios para estar seguros de no romper nada en cada instalación. Considero que los test unitarios son mandatorios, pero también es recomendable tener test de UI.
El proceso de automatización del build, modularizacion y agregado de test, lleva tiempo, por lo que conviene hacerlo paulatino y seguir instalando desde ahi. En nuestro caso, la modularizacion llevo mas de un año de trabajo, de una persona (sin dedicación exclusiva). La modularizacion cambia algunas interfaces externas (nombres de objetos, URL, etc) por lo que es un cambio que debe hacerse en forma paulatina.
En esta etapa, pasamos de tener una KB con una instalación monolítica, a una KB con una instalación distribuida en varios webapps.
Dejo para otro post, la division de la KB en varias KB para instalarla como microservicios.
Dejo para otro post, la division de la KB en varias KB para instalarla como microservicios.
Hola, excelente foro y post. Para los que sabemos y estamos aprendiendo con Genexus.
ResponderBorrarEn cuanto al post que se menciona "la division de la KB en varias KB para instalarla como microservicios."
Ya está publicado?
Me interesa.
Muchas gracias !