Características del modelo

Así como los otros modelos, este también tiene propiedades que determinan la naturaleza del servicio de entrega, entre las cuales se pueden mencionar las que se citan a continuación:

Es un servicio que se ofrece bajo la modalidad de suscripción; es decir, los clientes no compran el software completo, sino que adquieren una membresía, la cual se paga según la frecuencia ofertada por el proveedor que le da el derecho al consumidor de utilizar el software y todas sus características y funciones.

Se accede completamente a través de la red. Como muchos de los servicios de computación en la nube, el método más común de entrega se realiza por medio de Internet, siendo la interacción únicamente a través del navegador. A su vez, esto representa una ganancia para el cliente, ya que no se preocupa por la compatibilidad de su sistema operativo con el software, ni tampoco la ubicación geográfica, ya que puede acceder a la aplicación siempre y cuando tenga conexión a Internet.

Es autoescalable con la demanda de tráfico y carga. Cuando se hace uso de un software de este tipo, no es necesario estar preocupándose por la carga de trabajo que se pone en manos

del aplicativo, ya que normalmente, estas responsabilidades caen en los hombros de los proveedores del servicio.

Es multi-inquilino; en otras palabras, se puede tener múltiples instancias de la misma aplicación completamente aisladas para servir a un cliente por instancia. Esto supone un

contenedor privado para cada cliente, en el cual sus datos van a existir solamente para ellos y no para varios consumidores al mismo tiempo dentro del mismo espacio lógico.

Teniendo en cuenta estos aspectos, se hace referencia a lo expuesto por Fox y Paterson (2014) en su libro titulado Engineering software as a service: an agile approach using cloud computing [Ingeniería del software como servicio: un método ágil utilizando computación en la nube], para ejemplificar estos principios que debe seguir todo software como servicio, donde se indica que:

El software como servicio establece tres demandas en la infraestructura de las tecnologías de la información: la comunicación: para permitir a cualquier cliente interactuar con el servicio; escalabilidad: ya que las instalaciones principales que corren el servicio deben lidiar con las fluctuaciones en demanda durante el día y tiempos populares durante el año para ese servicio y nuevos para agregar usuarios de manera rápida; disponibilidad: en la que ambos, tanto el servicio como el vehículo de comunicación, deben continuamente estar disponibles: todos los días, 24 horas al día (“24x7”). (Fox y Patterson, 2014, pp.

49-50)

Así, pues, se establece una importancia que se le da a la disponibilidad del servicio, no solo en términos de “ininterrupción”, sino, también, en la facilidad de acceso al servicio mismo.

Como se mencionó anteriormente, siguiendo esta lógica de pensamiento, se habla entonces de un

mucho su entorno de equipos electrónicos para consumir el servicio. Por ejemplo, solo basta tener una computadora, una tableta o un celular para ingresar a la aplicación y utilizarla para obtener un resultado.

De esta misma manera, Namasudra (2018) expresa lo siguiente acerca de este punto, en un modelo de SaaS, una versión del software licenciado es proveída por el proveedor. Cualquier compañía o usuario puede comprar este software bajo demanda (p. 117). Sin embargo, en este sentido difiere un poco en el término “licencia” que utiliza el autor, aunque no equivocadamente, se piensa que hace referencia más bien a la suscripción para usar el software sin requerir

elementos adicionales, ni poseer software de forma local.

Esto supone una ventaja para los proveedores de productos bajo este modelo debido a que, en primer lugar, rápidamente pueden servir a muchos clientes a la misma vez con el mínimo esfuerzo. Esto incluye las actualizaciones y mejoras que se entregan en todo software, no importa de qué tipo sea. Al ser los dueños de la aplicación, tener la administración de la infraestructura y código fuente, se tiene mayor control sobre lo que sucede en todo momento.

En segunda instancia, la adopción del servicio es significativamente más sencilla y rápida que cualquier otra aplicación entregada bajo otra modalidad. Claro está, haciendo la aclaración de que existen aplicaciones gigantes a nivel empresarial, las cuales tienen un poco más de complejidad al adoptarlas, como por ejemplo los sistemas de tipo Customer Relationship Management [Gestión de la relación de clientes], los Enterprise Resource Planning [Planificación de Recursos Empresariales] o los Human Capital Management [Gestión del Recurso Humano]. No obstante, el principio de implementación de rápido acceso y uso no deja de existir.

En tercer lugar, se puede mencionar las capacidades que tienen estos productos de integrarse con otros sistemas a través del uso de API’s, Middlewares y otro tipo de servicios y herramientas que gestionan líneas de comunicación por mensajes para conectar aplicaciones en un ambiente empresarial compuesto por varios sistemas de software de esta naturaleza. Sin embargo, existe una desventaja con respecto a este punto, la cual reside en lo siguiente: aunque varios proveedores de SaaS han desarrollado API´s integrados en sus productos, esto introduce retos como el de codificar y mantener la solución que conecta esos servicios web, y además existe poca estandarización en la estructura de estos. (Pethuru, 2011, p. 62)

Luego, otra consideración en el aspecto de la integración que menciona este mismo autor es la poca experiencia que puedan tener las empresas al sincronizar los datos entre aplicaciones de este tipo en su ambiente, una tarea que se puede convertir en una pesadilla. Esto, en cierta forma, tiene razón, ya que crear un proceso de integración entre aplicaciones puede llegar a ser todo un proyecto aparte y tan tedioso como desarrollar la aplicación misma.

Por el contrario, aquí es donde ese bloqueo se puede llegar a solventar con ayuda de la orientación del software basado en una arquitectura de microservicios, en la cual las interfaces de programación de servicios web sea la base de la comunicación. Además, se puede tomar ventaja de otros servicios en la nube que proveedores ya ofertan, como por ejemplo, Amazon provee el servicio de mensajes de Simple Message Queue (SQS) [cola de mensaje simple], también el de Lamda; Google por su parte tiene App Engine [Motor de aplicación], Google Functions

[Funciones de Google] entre otros que facilitan en gran manera el implementar servicios de integración que se ejecuten solamente con ciertos eventos y que se comuniquen por API´s.

Para resumir sobre el punto anterior, el principio de uso de servicios prediseñados y ofrecidos nativamente por los proveedores de computación en la nube se promueve como la

opción preferida para utilizarse en conjunto con software como servicio para construir un ambiente altamente integrado y sincronizado en tiempo casi real.