Migrando aplicaciones a la nube (AaaS, o SaaS específicos o sectoriales)

En el área de SaaS, hay un subsector del mismo al que algunos llaman AaaS (Application as a Service) para recoger en él a un subconjunto de software compuesto por aquellas aplicaciones propias con las que una empresa está dando servicio a clientes externos (haciendo negocio) o a usuarios internos (resolviendo una necesidad común, pero específica e interna de una gran empresa), es decir aplicaciones que aunque se usen por un amplio conjunto de usuarios de alguna forma son aplicaciones propietarias o verticales de un sector muy concreto y no son altamente generalistas. Estos servicios del tipo AaaS (al igual como sucede en general con el resto del SaaS) se pueden llevar a la “nube” de 4 formas muy diferentes:

1. Una de ellas la podríamos considerar “no pura” y que de forma simplista consistiría en virtualizarla, y gestionar de forma manual sus necesidades cambiantes de recursos en función de la demanda de los usuarios (levantando más máquinas virtuales o reduciéndolas en función de la carga, que es monitorizada por sistema de gestión tradicionales). De forma similar o incluso menos sistemática habría que resolver sus necesidades de almacenamiento o de comunicaciones. La infraestructura que utilice puede ser propio o externa, y en este caso puede ser una auténtica plataforma IaaS o una plataforma que contrata de máquinas virtuales. Para simplificar la casuística a analizar, y para cercarnos al purismo, vamos a entender que la plataforma en la que se instale la aplicación es auténticamente IaaS.
2. Una segunda opción, es usar la primera aproximación y, además, usar los servicios de empresas intermedias que se encargan de realizar la correcta gestión del entorno virtual para asegurar que nuestra aplicación tiene en todo momento los recursos necesarios y suficientes (es decir, sin pecar de un exceso onerosos) para atender a la demanda de los usuarios. Una empresa paradigmática en ofrecer tales servicios es RightScale.
3. Una tercera opción es desplegarla sobre un entorno PaaS real (aquí dependemos de que de nuevo la palabra cloud es un “buzzworld” y todo el mundo califica de tal sus servicios, encontrándonos con algunos proveedores de servicios PaaS que no son tales (sino más bien una Plataforma más o menos grande con un servidor de aplicaciones, si se me permite esta aproximación muy simplista). Si el servicio que se contrata es una auténtico PaaS, este detectará las necesidades en cada momentos de la aplicación y se encargará de aprovisionarla con los recursos correctos (algunas de las plataformas PaaS existentes sí realizan este aprovisionamiento automático para la aplicación que corre sobre él, pero solo de recursos de cómputo, siendo el almacenamiento y las comunicaciones gestionados de forma manual o semi-automatizada).
4. Otra forma, la que podríamos denominar auténtico “cloud” (SaaS real en este caso) que consiste en que la propia aplicación se auto-aprovisione de más máquinas virtuales o de más almacenamiento en disco o de más ancho de banda, en función de la carga o necesidades que sus usuarios le generen en cada momento.

Evidentemente, puristamente hablando, sólo se podrían considerar auténticos AaaS (o SaaS en general) las dos últimas soluciones, pero eso al usuario final no le importa siempre y cuando el servicio que recibe sea bueno, acorde a la filosofía SaaS (siguiendo la definición del NIST), y el precio aquilatado al nivel de servicio que contrata. Es más en ocasiones “vive engañado”, quiero decir que cree que está recibiendo un servicio SaaS real (pues así lo afirma el vendedor) pero en el fondo tiene un servicio de uno de los dos primeros tipos que hemos enumerado. Profundizando en este aspecto:

• Lo que es cierto es que en condiciones normales, y con un buen equipo técnico de soporte y gestión en el caso de la primera opción, el usuario final nunca detectará la diferencia, por lo que a él no le importa siempre que el precio sea competitivo aspecto que en principio, en la primeros opción no es tan fácil de conseguir, pues hace falta más recursos humanos para realizar una buena gestión, además de que deberá formarse en las herramientas que en tal sentido le ofrezca el proveedor al que contrate la plataforma
• En la segunda opción el coste interno de la correcta gestión del aprovisionamiento es externalizado, y realizado mediante los servicios de una tercera empresa (p.e: RightScale).
• En el tercer caso, y asumiendo que el servicio PaaS (sobre el que se apoya) es real y completo, la despreocupación del aprovisionamiento es total, pero a cambio aparece el coste de la proveedor de los servicios PaaS, y en general de tener que adaptar nuestra aplicación para que funciones en la plataforma PaaS (necesidad común a prácticamente todas las plataformas PaaS, y más o menos compleja en función del proveedor PaaS e de las características de nuestra aplicación). Además en este caso, en general también se convierte en cautivo del proveedor PaaS pues la adaptación que hemos hecho en nuestra aplicación para que funciones en su plataforma PaaS no sirve para otras plataformas PaaS.
• Por último, el cuarto caso se trata de adaptar la aplicación para que ella se auto-aprovisione de los recursos (de más máquinas virtuales o de más almacenamiento en disco o de más ancho de banda), en función de la carga o necesidades que sus usuarios le generen en cada momento, y los libere cuando ya no los precise. Para ello la aplicación llamará directamente, desde el propio código de la aplicación, a las APIs correspondientes de la plataforma IaaS subyacentes para aprovisionarse o liberar el recurso que precise en función de la cara de usuarios en cada momento. En este caso, también pueden aparecer problemas de estandarización e interoperabilidad como ya hemos comentado anteriormente (ver el comentario titulado “Nubes en la bola de cristal”). Sin embargo en el campo del IaaS ya existen plataforma a abiertos y estándares de facto que permiten liberarse de esta situación. Este es el motivo por el que TISSAT, como ya he comentado en día precedentes, ha aportado por la solución OpenStack que ofrece un a plataforma de auténticos servicios IaaS siendo de código abierto y que en este momento está soportada por un consorcio en el que participan más de 170 empresas (entre ellas Tissat). Cualquier empresa que desarrolle (o migre) sus aplicaciones en la nube sobre dicha plataforma IaaS (llamando a sus APIS para auto-aprovisionarse de recursos cuando lo necesite la carga de trabajo que soporta) tendrá la opción de mover sus aplicaciones entre todos los proveedores que ya dan servicio con dicha plataforma OpenStack (entre ellos, por mencionar uno, el gigante RackSpace), o incluso, llegado el caso, de montarse el mismo una cloud privada con OpenStack y en ella ejecutar sus aplicaciones así desarrolladas.