Cómo determinar la fiabilidad de las aplicaciones SAAS

Preguntas para el proveedor

Dado que la infraestructura SAAS es –desde el punto de vista de sus clientes- un sistema de caja negra, una de las características más importantes relacionadas con la fiabilidad que hay que considerar es la mesa de mandos de estado del servicio del proveedor, el sistema a través del cual un vendedor SAAS proporciona a sus usuarios la información sobre la salud del servicio y las interrupciones. Como la mayoría de los proveedores hacen público el estado de sus servicios a través de sus sitios Web, este es un buen lugar para empezar con la evaluación de fiabilidad de tu proveedor SAAS.

Asegúrate de que el vendedor SAAS que estás evaluando proporciona información sobre los tiempos de funcionamiento y el estado del rendimiento que cada servicio discreto ofrece, y de que la información es acertada, está actualizada y es fácil de localizar. También es importante que el proveedor SAAS ofrezca información relacionada no sólo con el estado actual, sino también con el estado histórico. Más aún, el proveedor SAAS debería ofrecer maneras de notificarte las caídas o degradaciones del servicio, a través, por ejemplo, de alertas de correo electrónico o RSS que los administradores pueden integrar en sus propias mesas de monitorización.

Cuando llega el momento de discutir sobre la fiabilidad del proveedor de SAAS, los acuerdos de nivel de servicio (SLA) –que se asientan tanto en los tiempos de funcionamiento como en el rendimiento que los clientes pueden esperar de sus proveedores, así como en la compensaciones que los clientes recibirán si estos acuerdos no se cumplen- son un buen punto de arranque. Sin embargo, muchos proveedores SAAS, incluidas empresas bien establecidas como Salesforce.com, no ofrecen SLA, debido quizás a la dificultad que representa tener que definir la fiabilidad del modelo SAAS con el rigor necesario para que se ajuste a un acuerdo formal.

Si tu posible vendedor de SAAS está dispuesto a aceptar un SLA, el acuerdo puede servir como una útil herramienta para hacer coincidir las expectativas de tu empresa con el nivel de servicio que el vendedor está dispuesto a ofrecer, particularmente si tu SLA va más allá del tiempo de funcionamiento básico e incluye métricas de rendimiento específicas.

Sin embargo, el peso de monitorizar el tiempo de funcionamiento y reclamar compensación por caídas y degradaciones del servicio suele recaer en el cliente, y los créditos parciales sobre la factura por uso del SAAS no cubrirán los períodos de inactividad importantes. Tanto si el proveedor que estás evaluando ofrece un SLA por su servicio como si no lo hace, lo más importante es que el vendedor sea capaz de responder a tus necesidades de tiempo de funcionamiento y rendimiento.

Deberías hablar con el proveedor de cómo su arquitectura se desenvuelve con sobrecargas, y si está preparada para escalar a clientes adicionales sin que esto afecte a la fiabilidad de la aplicación. Además, deberías preguntar sobre la distribución geográfica de los centros de datos del vendedor –cuanto más cerca estén los centros de datos de tus usuarios, mejor será el rendimiento-.

Por otro lado, deberías comentar con el proveedor de SAAS los procesos de adaptación que planeas hacer a sus aplicaciones y considerar si las implicaciones que esto pueda tener en el rendimiento merecen la pena. Deberías averiguar también cuál es el calendario de actualizaciones y discutir qué impacto tienen estas actualizaciones en el rendimiento. Si estas actualizaciones se van a producir en los momentos en los que tú necesitas el máximo rendimiento en tu aplicación, propón si es posible que puedas controlar los tiempos en los que se hacen las actualizaciones.

En cuanto a la aplicación SAAS como tal, averigua hasta qué punto la aplicación del vendedor se aprovecha de la ejecución cliente o de las tecnologías RIA (aplicación de Internet enriquecida), capaces de reducir el impacto de los problemas de conectividad a Internet (por ejemplo, baja latencia) reduciendo los viajes de ida y vuelta del servidor al navegador que se necesitan para ejecutar ciertas operaciones, tales como la clasificación de elementos.

Asegúrate de preguntar al vendedor de SAAS si su aplicación tiene en cuenta el acceso a datos offline. Por ejemplo, los servicios de correo electrónico SAAS suelen venir con un historial de acceso offline, ya que tanto el protocolo IMAP como el Exchange MAPI funcionan con clientes de correo locales para mantener el correo disponible localmente así como en la nube. Con otras aplicaciones que tengan menos protocolos de datos estandarizados, el historial offline puede que sea menos atractivo. Sin embargo, tecnologías como Google Gears, que la propia Google y Zoho emplean para algunas de sus ofertas SAAS, permiten el acceso a algunos datos de forma offline. Incluso los vendedores de SAAS sin una estrategia offline deberían al menos ser capaces de decir si tienen pensado incluir esta función en un futuro.