SaaS en v7 (I) – El análisis previo

Desde que Velneo comenzó resaltar que la v7 estaba enfocado en el CloudComputing y que el el futuro de las apps de gestión era el SaaS,  muchos miembros de la comunidad comenzamos evaluar esta “nueva” modalidad y lo que aporta v7 para adentrarnos en esta nueva “ola”, como resultado de esas consideraciones y muchas lecturas me embarque en el proyecto que hoy denomino vClouden, tratando de cerrar la brecha que hay entre v7 y las aplicaciones SaaS estandar(interfaz web, zona de clientes, soporte online, documentación, billing, etc.), de toda esa experiencia he logrado sacar algunas conclusiones que quisiera compartir y hoy comenzaré con el análisis previo.

 Que trae v7 a la mesa en el area del

Software como Servicio ?


No voy traer a colación las grandes ventajas de v7 desde el punto de vista del desarrollo de aplicaciones, mas bien voy a referirme a ella desde el punto de vista de arquitectura y lo que ello implica de cara a servir aplicaciones SaaS.

  • Posibilidad de conexión a travez de internet por defecto en la plataforma, ello implica que en cuanto a comunicación para un vServer son indiferentes las conexiones locales o las conexiones por internet, el simplemente te permite conectarte.
  • Cache de aplicaciones, después de la primera conexión en donde se “baja” la aplicación  solo se comunican datos entre la aplicación y el servidor de aplicaciones, además los inicios son instantáneos.
  • Cache de datos, los datos que le solicitamos a la base de datos, no tienen que enviarse en un solo paquete va llegando progresivamente como en un streamming de video.
  • Capacidad de manejar tablas locales en memoria para una mayor velocidad en ciertas operaciones.
  • El nuevo vUpdater, realmente útil para mantener a nuestros usuarios SaaS con la ultima versión tanto de nuestras apps como de la plataforma.

y todo esto que significa de cara a las aplicaciones ?, en pocas palabras: que tus cliente podrán disfrutar de un interfaz familiar y rápido, que solo transfiere datos y que siempre se mantendrá actualizado, teniendo la data de su negocio en la nube accesible desde cualquier lugar, además con la posibilidad de ser instalada como una app stand alone normalmente.

ok esto habla muy bien de las aplicaciónes como tal, pero y el resto del entorno Saas ?

Hacia una SaaS real con v7.

Antes de comenzar hay que imaginarse como debe ser una SaaS con v7 desde el punto de vista de lo que se le ofrece al cliente, aqui mi lista de deseos:

  • Interfaz web para registro clientes con una zona interna, la cual contendrá la instalación de aplicaciones, documentación, soporte, billing y datos de cuenta.
  • Darle al cliente la capacidad usar cualquiera de mis aplicaciones en cuantas instancias quiera por el tiempo que quiera.
  • Soporte Online deberá majearse tickets manteniendo la historia de la conversación ademas de notificaciones por mail.
  • Documentación online para las aplicaciones.
  • Darle al cliente la capacidad de tener backups de su propia data.

Antes de siquiera comenzar te enfrentas con el dilema de las instalaciones:

A la fecha solo se me han ocurrido tres formas de entregar un app v7 ne modalidad SaaS y aunque cualquiera de las 3 puede llegar a se valida dependiendo de las aplicaciones a servir, miremos los pro y los contra de cada una, tomando en consideración la lista de deseos:

1. Una instancia por cliente dentro de un solo vServer (Multitenancy): 

Tal vez la ideal en teoria y para la que supongo que Velneo apostaría de futuro pero de cara al Saas tiene varios peros importantes:

Pros:

  • Multytennacy real, actualizas tu aplicación automaticamente todos tus clientes tienen disponible la nueva versión, aunque te limitas a hacerlo cuando no haya nadie conectado, igual vale.
  • Durante un buen rato solo se administra un vServer y el escalado es mas a nivel de hardware.
  • Aíslas los datos de cada cliente en sus carpetas de datos.

Cons:

  • La falta de comandos que recibe por consola un vServer es muy limitada, así que de momento no hay forma de automatizar la creación de usuarios, grupos, instancias, carpetas, etc. automatización necesaria si queremos que el usuario puede tener tantas instancias de nuestra app como desee.
  • Aunque nos saltáramos el punto anterior el vAdmin no tiene facilidades de uso para manejar, buscar o filtrar instancias, por lo que personalmente no me imagino mirar un vAdmin donde hayan unas 100 o 200 instancias cada una con sus herencias.
  • Un tema particularmente importante es aislar el rendimiento de cada instancia, si dos usuarios pagan unos USD 20/ mes para usar tu app ambos debería tener el mismo rendimiento por su dinero pero que pasa si el usuario 1 tiene muchos mas usuarios conectados que el usuario 2 y los dos usan el mismo vServer?, por supuesto esta consideración en una escala mas macro.
  • Falta de información en cuanto a rendimiento, si, he escuchado que a los vservers los ha probado y les han dado mucha “caña” con millones de registros y conexiones, y les creo, pero a mi antes de confiarle buena parte de mi negocia a un vServer me gustaría conocer una publicación oficial que cuantifique el rendimiento de un vServer, cuantas contexiones, cuantos millones de registros, cuantas instancias, es decir … cuando un vServer comienza a deteriorar su rendimiento.
  • Costo: si o si tienes que comenzar tu Saas usando un vServer enterprise de ahi la importancia de conocer el rendimiento para conocer le costo beneficio de usuarios soportados vs costo del vServer enterprise + Hosting.
2. Una sola instancia que albergue a todos los clientes.
Esta es otra opción tambien factible, simplemente encargarnos nosotros mismos dentro de nuestra aplicación de la gestion de usuarios, grupos, permisos, etc.

Pros:

  • Solo gestionar una sola instancia y un solo vserver.
  • Administración de usuarios mas fácil y hasta una comunicación mas directa para crear nuevos clientes dentro de la app desde el interfaz web mediante vModApache o TCP.
  • Multitennacy para mantener a todos tus clientes con la ultima version de tu app.

Cons:

  • Mayor inversión en desarrollo al tener que crear todo el interfaz y la lógica de usuarios para el registro y logueo.
  • No hay un aislamiento de los datos de los diferentes clientes, todos estarían dentro de la misma db, aunque no es un requisito para algunos para mi es importante poderle decirle a mi cliente no solo que sus datos no los pueden ver otros, sino que físicamente están aislados entre si.
  • Dificultad para vender tu app en stand-alone dada la arquitectura necesario para que funcione como una Saas que no puede encajar dentro de una instalación local, sin mencionar que de cierta forma arriesgas tu know-how al tener una app que sirve para montar un Saas por ahí dispersa.
  • El mismo problema de la falta de información en rendimiento y costos que (1)

3. un vServer para cada cliente en la misma maquina usando algún mecanismo de Sandboxing.

Básicamente imitar lo que hace el cloud de Velneo a nivel de desarrollador pero en este caso a nivel de cliente.

Pros:

  • Estabilidad separada, si un vserver se cae por algun bug no afecta a las demás.
  • otra capa de aislamiento para los datos de cliente y mayor facilidad en el proceso de proporcionar backups cuando el cliente lo requiera.
  • Performace aislado para cliente (Depende del mecanismo de enjaulamiento)
  • Al tratarse el el vserver y la app como una unidad, se pueden realizar tantas instalaciones del mismo como se deseen.
  • No hay que preocuparse con que tanto puede dar un vserver.
  • Puede usarse el vserver monousuario para comenzar.
  • El escalamiento es lineal mas clientes, mas maquina y viceversa, claro usando algún servicio cloud.
  • El app sigue siendo el mismo asi que puedes vender tambien licencias stand-alone sin arriesgar el know-how de tus Saas.

Cons:

  • Administración de muchos vservers y tambien automatizar el escalamiento de los servidores en la nube donde se alojan los mismos.
  • Mucha mas Inversión en desarrollo para la automatización requerida
  • Lidiar con el licenciamiento de los vServers ya que vas a necesitar varios.

Bueno, dado los requerimientos me decante por la última opción, aunque requirió mucho mas I+D terminó siendo una solución mas abstracta y lo mejor de todo con la posibilidad de ser abierta para otros desarrolladores, continuare en el siguiente post contanto como pasé de este análisis previo a la implementación de vClouden.

Saas en v7(II) come on cloud

Saludos,

About these ads

2 pensamientos en “SaaS en v7 (I) – El análisis previo

  1. Pingback: Saas en v7(II) – come on Cloud !! «

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s