Selección de aplicaciones SaaS. Multi-tenancy

 

Seguimos con la serie de Puntos clave para la selección de aplicaciones de negocio SaaS con el que creo más importante, confuso y complejo frecuentemente y el que considero que es crucial a la hora de decantarnos por un determinado proveedor de aplicaciones de negocio SaaS ya que de alguna manera abarca, o es consecuencia, del resto de puntos clave que se comentan en esta serie: el multi-tenancy.

En una primera aproximación se podría definir que una aplicación de gestión SaaS es Multi-tenancy si:

• Puede ser compartida por diferentes clientes
• Es capaz de adaptarse y evolucionar con los diferentes requerimientos de cada cliente
• Y al mismo tiempo ser viable, técnica y económicamente, para el proveedor.

Estos requisitos veremos más adelante que condicionan fuertemente la arquitectura tecnológica de una aplicación SaaS.

 

Para entender el concepto creo que es necesario conocer la historia reciente de los antecedentes a los actuales modelos SaaS, los ASP o Application Service Providers. En los 90 se pusieron de moda los ASP, como he comentado antecedente de lo que ahora llamamos SaaS (aunque algunos dicen que es lo mismo no es lo mismo). El propósito es posible que fuese el mismo pero el estado de la tecnología y madurez de las empresas que se podrían haber beneficiado no lo era. Por ejemplo,uno  trivial, la velocidad y disponibilidad de las líneas de comunicaciones o la disposición de las empresas a sacar sus centros de datos fuera de sus paredes (algo a lo que ahora están más predispuestas en general).

En muchos casos, el concepto acababa en que una aplicación cliente-servidor, diseñada  y construida para ser desplegada en una red local, se habilitaba para que su parte servidor pudiera ser accesible desde fuera de la red local a través de Internet, y el paquete se vendía en forma de acceso por usuario.

Entre las razones técnicas por lo que este modelo fracasó, operativa y económicamente, se pueden contar:

• Velocidad y disponibilidad de Internet en esa época.
• La arquitectura física con la que se habían diseñado esas aplicaciones no escalaba ni soportaba bien compartir infraestructuras físicas en el lado servidor. Era ineficiente en el aprovechamiento de recursos hardware y software (la virtualización de servidores era una tecnología incipiente, de laboratorio prácticamente) y el hardware era caro en esos años.
• La arquitectura del software no estaba pensada para ser compartida por compañías diferentes. Los datos y tablas quizá sí (o ni eso) pero una configuración del software para necesidades específicas de una compañía no se podía hacer estanca al resto por lo que se podían producir colisiones o incompatibilidades entre ellas. Las modificaciones que sobre una arquitectura ya desarrollada tenían que hacerse complicaban más aún el entorno y lo podían hacer ingestionable técnicamente por el proveedor.
• La evolución del software podía ser inviable, o todos los clientes se coordinaban para cambiar de versión a la vez o no se podía, lo que derivó en que el software se quedase atascado en una versión o en que se tuviesen que separar instalaciones por versión – algo antieconómico y a medio plazo inviable.
• Al haber mucha lógica, incluso datos, en la parte cliente, el despliegue y mantenimiento homogéneo de cualquier implantación compartida era una tarea muy costosa porque había que actualizar software en cada estación de trabajo

 

En conclusión, para que una aplicación de gestión sea viable en modo SaaS, debe ser capaz de poder conseguir economías de escala al compatibilizar el que los clientes puedan compartir los costes fijos (infraestructuras, implantación, soporte, mantenimiento, des-implantación, etc.), cubrir las necesidades comunes y específicas de esos clientes y al mismo tiempo poder evolucionar para acomodarse a los cambios en esas necesidades de cada uno. Es decir que sea Multi-tenancy

Afortunadamente esta posibilidad llegó de la mano de avances tecnológicos como la virtualización, seguridad, velocidad y ubicuidad de líneas, navegadores rápidos y capaces de incorporar lógica de forma estándar -no propietaria- en local, entornos y metodologías de desarrollo más avanzados, etc. que permitieron desarrollar productos con arquitecturas tecnológicas que posibilitaban el Multi-tenancy y desplegar modelos True SaaS.

 

¿Y como podemos verificar con nuestro proveedor que su aplicación de gestión es Multi-tenancy y evitar así que en realidad acabemos contratando una aplicación tradicional en hosting, o lo que es lo mismo que seamos un Single-tenancy más en sus infraestructuras?

Pues deberemos hacerle preguntas como:

¿Todos los clientes están en la misma versión del software? Todos los clientes deberían correr la misma versión del código, sin “customizaciones” de código. De esta forma cualquier configuración propia del cliente no acabará afectando al resto de clientes ni, a su vez, se verá afectada por personalizaciones de código del resto de clientes – ¿cuánto se tarda en hacer un cambio de versión?

¿Qué tiene que hacer el cliente si se actualiza la versión del software? Los clientes no se deberían preocupar de tener que actualizar el software, para ellos debería ser transparente, en un extremo ni enterarse. Así la actualización es para todos los clientes a la vez  y cualquier configuración específica del cliente no debería condicionar el poder actualizar el software al resto – ¿Podrías hacer mañana mismo un cambio de versión sin avisar a tus clientes?

¿Con qué periodicidad se actualiza el software? No debería haber versiones en el sentido tradicional sino frecuentes mejoras incrementales (un ejemplo serían las aplicaciones de Google) – ¿Cuántos cambios de versión/upgrades/mejoras has hecho en el último año?

¿Cómo va a cubrir la aplicación estos requerimientos clave [elíjanse varios cuidadosamente] y que son específicos de mi compañía/negocio/sector? Si el proveedor contesta que debe adaptar/cambiar el software es probable que éste ya no sea una opción adecuada (al menos en modo SaaS ) para el cliente. De alguna forma la arquitectura de la aplicación debe estar construida de forma que se puedan diferenciar las diferentes compañías cliente en el momento de ejecución de la aplicación. En los modelos ASP esto se conseguía con el código de compañía/unidad organizativa, pero un modelo True SaaS debe ir más allá, con codificaciones que permitan que en modo de ejecución la aplicación pueda distinguir entre compañías clientes, hacer uso de clusters o agrupaciones de compañías/unidades organizativas por compañía cliente o por criterios de localización geográfica para temas de normativas locales por ejemplo.

 

Por último quiero añadir que, en mi modesta opinión, veo muy difícil, por no decir imposible, que una aplicación que no ha sido técnicamente diseñada y concebida desde cero con un enfoque de ser Multi-Tenancy, pueda serlo, ya que las modificaciones a posteriori que una aplicación tradicional requiera para ser Multi-tenancy acabarán haciéndola compleja y costosa de gestionar y mantener, es decir inviable económicamente.

O sea, que cuidado con los productos tradicionales reconvertidos al nuevo mantra del SaaS.

 

El resto de la serie y otras entradas relacionadas: Selección de aplicaciones de negocio SaaS. Puntos clave

 

Foto variante de una de la serie New York rises de Eugene de Salignacs