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.
