martes, marzo 22, 2016

La nube, el modelo “multi-tenant” y las extensiones de NAV 2016




Todo el mundo es consciente hoy en día de que estamos en la “era de la nube”… y lamento decir que quien no lo vea de esta forma, tiene un serio problema de realidad distorsionada.

Hace como 4 años, desde Microsoft se nos decía a los partners que teníamos que “cambiar el chip”, y nos mostraban aquellas gráficas impresionantes con curvas exponenciales basadas en datos de encuestas de Gartner e IDC sobre el mercado cloud.

Se comenzaba a hablar de cosas muy raras, con ejemplos tan gráficos y demostrativos como el ya famoso “pizza-as-a-service”:




 Todo comenzaba a girar sobre la “arquitectura orientada a servicio”.



Una nueva realidad

Como decía, nuestra realidad ha cambiado. En España, casi la totalidad de las empresas son PYMEs, y son más las “P’s” que las “M’s”. Además, fruto de la mal llamada “crisis”, existen multitud de personas que sin más alternativas, han apostado por el autoempleo.

Partiendo de este escenario: ¿Quién hoy en día realiza una importante inversión para poner en funcionamiento su Sistema de Gestión?

No digo que el modelo de negocio “clásico”, donde las consultoras realizaban proyectos de servicios de semanas esté acabado ni muchísimo menos, pero sí que estamos hablando de una cuota de mercado inferior, en comparación a años atrás. Es decir, que prácticamente se limita a las medianas y grandes empresas y a aquellas que han tenido la suerte de optar a alguna subvención.

Está claro que se requiere un modelo donde las personalizaciones se reduzcan y las implantaciones sean rápidas, repetibles y fácilmente actualizables. En definitiva, abaratar los costes para poder dar cobertura a las necesidades reales de nuestro mercado.

Dicho esto, me gustaría exponeros qué es el “multi-tenant” y por qué cobra ahora más sentido que nunca.


¿Qué es el “multi-tenant”?

Si nos ceñimos a la definición más terrenal (léase Wikipedia), encontramos esto:

<<Tenencia múltiple o multitenencia en informática corresponde a un principio de arquitectura de software en la cual una sola instancia de la aplicación se ejecuta en el servidor, pero sirviendo a múltiples clientes u organizaciones (tenedor o instancia). Este modelo se diferencia de las arquitecturas con múltiples instancias donde cada organización o cliente tiene su propia instancia instalada de la aplicación. Con una arquitectura de tenencia múltiple, la aplicación puede particionar virtualmente sus datos y su configuración para que cada cliente tenga una instancia virtual adaptada a sus requerimientos. Algunos expertos consideran la tenencia múltiple como un factor decisivo del paradigma de computación en la nube>>

Desde mi punto de vista, esta es una definición muy clara y correcta del concepto.


El “multi-tenant” en Microsoft Dynamics NAV

Esta nueva opción de implementación se introdujo en NAV en su versión 2013 R2, posibilitando por consiguiente su despliegue en Azure.

El fundamento principal es separar los “objetos de aplicación”, es decir, aquellos que son comunes para todas las empresas, de los “datos” específicos y particulares de cada una de ellas.

Esto significa que cuando realice un desarrollo o una actualización tan sólo lo haré 1 vez, y todas las empresas tendrán acceso dado que comparten los objetos de aplicación.

 







Obviamente, las ventajas están bien claras:


  • Reduzco costes de mantenimiento: como es lógico, al implementar los desarrollos una sola vez, reduzco enormemente los costes que supondrían mantener múltiples plataformas para múltiples empresas. 
  • Protejo mi propiedad intelectual: algo en lo que a veces no reparamos, pero que no es baladí. Cuando se programa en Microsoft Dynamics NAV todo el código va embebido en la base de datos. Por tanto, salvo que se trate de un “add-on”, todas las personalizaciones y desarrollos a medida son accesibles por cualquier partner o cliente con licencia de desarrollo. Evidentemente, esto es otro debate independiente y las opiniones son muy diversas al respecto. Yo personalmente considero que esto es sólo una parte, ya que detrás de todo desarrollo existe el “conocimiento del negocio”. 
  • Más clientes, más rentabilidad: una vez realizada la “inversión” en mi infraestructura y mis desarrollos, añadir nuevos clientes es casi un trámite. Mi rentabilidad irá aumentando significativamente conforme de servicio a más clientes.

Podríamos alargar esta lista bastante más, pero considero que “la idea” en líneas generales la tenemos ya.


Esto no es todo… ¿qué cambia con NAV 2016?

En NAV 2016, como muchos ya sabéis se ha introducido la posibilidad de crear “extensiones”, con el fin de ampliar la funcionalidad y con la filosofía de respetar el código original. Y lo bueno es que es aplicable tanto a escenarios clásicos “on-premise”, como a escenarios multi-tenant, es decir, puedo habilitar estos paquetes de extensión para tenants específicos o para todos mis tenants.

Es cierto que existen aún limitaciones, y que hay usuarios que se quejan de esto, pero pensemos en el gran cambio de filosofía, que seguro marcará un punto de inflexión en la historia del producto. La principal diferencia con el “desarrollo clásico” es que no están permitidas las modificaciones del código original, y en su lugar, utilizamos “eventos C/AL” para ampliar y personalizar los objetos.

La gestión de distribución de estos paquetes (que son ficheros .navx), la realizaremos con PowerShell, que a estas alturas siempre la tenemos en el “top 5” del listado de aplicaciones más usadas en Windows 10 :-)

Gráficamente, el concepto sería algo así:

En un entorno NAV 2015, tendríamos 1 servidor por cada solución personalizada de NAV:



En un entorno NAV 2016, podemos tener un solo servidor con múltiples personalizaciones gracias a las Extensiones:



Para terminar, voy a hacer una breve introducción sobre el funcionamiento de las extensiones, que espero que sea clarificadora.


¿Cómo funcionan las extensiones?

Las extensiones son, en términos simplificados, la aplicación de objetos y “objetos delta” en tiempo de ejecución para una combinación específica de un paquete de extensión y un tenant. Cuando se publica una extensión en un despliegue de NAV, lo que hace es compilar los objetos frente a la base de datos de “objetos de aplicación” (que mencionamos anteriormente en el post). De esta forma, cuando la extensión es instalada en un tenant, se almacena dicha asociación y construye el esquema de base de datos correspondiente. En tiempo de ejecución, Microsoft Dynamics NAV sencillamente carga los objetos asociados para esa extensión y el tenant (la combinación de ambos).

Es posible publicar múltiples extensiones a un despliegue de NAV y, en entornos multitenant, instalar cualquier combinación de extensiones publicadas para cada tenant, como podíamos observar en el gráfico de arriba. Al final, esto lo que nos brinda es un alto grado de elección de funcionalidad y al mismo tiempo maximiza el hardware existente y la carga de administración.


Profundizaré en el modelo de extensiones y en su gestión en próximas publicaciones. Confío en que la publicación haya sido de vuestro interés.


Un saludo, Miguel Llorca.