¿Se fian los usuarios de las aplicaciones hospedadas (SaaS)?

[mamcx]

Empezado por mcs

El título es bastante descriptivo, pero voy a detallar más mi dilema.

1:

La aplicación ha estado creciendo durante este tiempo, y ha llegado el momento de crear una versión nueva. La versión actual está escrita en Java+Swing+MySQL.

a) Que sea una aplicación de escritorio y la programe en Delphi. Se vende la aplicación al usuario final y, si este lo desea, cada año se cobra mantenimiento o puede comprar actualizaciones.
b) Que sea una aplicación web hospedada creada en Rails o similar. Mensualmente (o anualmente) se cobra una cantidad fija en concepto de derecho de uso.
-----
2:

Desde el punto de vista técnico, prefiero la versión Delphi. Desde un punto de vista monetario, prefiero la versión web.
----
3:

Por otra parte, la grandeza de las aplicaciones hospedadas es que el usuario se olvida totalmente del tema mantenimiento: no debe hacer copias de seguridad, no debe instalar actualizaciones... Además, puede usar la aplicación desde cualquier ordenador y no debe instalar nada. Eso si, si no tiene conexión a Internet, no puede acceder a sus datos.

Te deshueso los puntos claves en mi opinion:

1:

No veo el porque ha llegado de crear una version nueva, como en el sentido de " Reescribir todo, en otro lenguaje y plataforma, simplemente porque supongo que nube lo obliga".

Una reescritura es el error estrategico #1:

http://local.joelonsoftware.com/wiki...hacer,_Parte_I

Porque esta en conflicto con parte del

2:

Desde un punto de vista monetario..

Porque desligas el tecnico del monetario? Se puede argumentar que el monetario es MAS importante. Porque si te quedas sin gasolina, no solo tu proyecto se va a pique sino todos los que hayan confiado en tu proyecto como sus usuarios.

Ya que el tema de confianza es clave, que tu proyecto sea solido economicamente es critico, no?

Ademas, Delphi no significa "no web". Web <> HTML, Web es una plataforma que PERFECTAMENTE permite clientes nativos (quizas la validación mas poderosa es el AppStore, donde las aplicaciones de iOS usan servicios web para operar).

http://blog.elmalabarista.com/post/1...ion-remobjects

PERO, igual no veo el porque la reescritura. Eso retrasara el proyecto. Diria quizas una reingenieria para adaptarlo al entorno de nube.

3:

Mas que el ahorro de que un usuario no haga un backup (que igual es algo que debes permitir: Que el usuario descargue copia de sus datos, ojala en un formato abierto como CVS, JSON o XML) la ventaja ppal es para ti.

Casimiro apunta a las dificultades de hacer las cosas bien y seguras. El problema de estas apps es la infraestructura: Como hacer un servicio escalable, seguro, rapido, confiable?

Si lo haces TODO TU, te resultara un lio. Ahora lo que esta de moda, y una moda buena, son los PAAS (Plataformas como servicio). Por ejemplo:

http://www.heroku.com/

https://www.windowsazure.com

Donde de forma notable otra entidad te administra la BD (y otros servicios) y ellos (osea MS o Azure) cumplen con las regulaciones y estándares a un nivel superior. Son plataformas probadas y con clientes grandes, y te ahorra un tiempo y pasta enorme.

Por ejemplo, ahora que estoy con heroku+azure. En heroku usando:

https://postgres.heroku.com/

El servicio de tener un motor de BD administrado por heroku es un PLUS tremendo y te quita mucho dolor de cabeza (igual con azure y su sql server).

Ahora igual debes encriptar y hacer segura tu app y todo eso. Lo MISMO que si la hicieras local, solo que es MUCHO mas seguro en la nube que local.

Porque?

Maxima de seguridad #1: El acceso FISICO a la maquina es la anulacion TOTAL de CUALQUIER seguridad. Es superfacil cojer el disco duro y acceder a la BD.

1000 a 1 a que la infraestructura de heroku/azure/amazon es MAS segura a todo nivel que cualquiera de las infraestructuras de red/bd de tus clientes.

Solo debes agregar seguridad de *datos*:

1- Comunicarte solo por HTTPS: Facilísimo y superbarato (los certificados valen centavos)
2- Encriptar los datos sensibles. Lo unico dificil es elegir bien el esquema de seguridad. Al dia de hoy: NO USES MD5 (que no es encriptacion sino hashing)
3- Preferiblemente, auditar con un experto tu seguridad. Te sale mas facil y barato hacerlo contra tu propia servidor (ej nube) que contra los servidores cliente.

El tener nube NO SIGNIFICA PERDIDA DE OPERAR LOCALMENTE.

Ahora tengo 3 proyectos que van a correr sobre nube. Todos pueden operar desconectados (bajo un subconjunto de datos a una BD local) y se sincroniza con el servidor.
-----

Lo ultimo es si tus clientes aceptaran o no. Eso es dificil de saber. Hay clientes que no lo quieren asi.

En general, es mas probable que un cliente pequeño te acepte el trato que un grande. Las opciones:

1- Vas cloud 100% y que se pudra al que no le guste. Sorprendentemente, es algo que funciona en general muy bien (pero depende del publico objetivo

2- Vas cloud, pero das opcion de tener un cloud privado.

Por ejemplo, si hospedas con heroku, tener un paquete donde esta la mayoria y creas instancias privadas para X clientes. Osea, un cliente = 1 heroku.

3- Lo anterior + instalacion local

Lo ultimo es que la mayoria lo haces en cloud pero permites que se instale de forma local en la empresa. Aqui se complica la cosa porque tienes que preocuparte de infraestructura y sincronizar las versiones entre el cloud y los locales, que es en parte la gracia con un PAAS.

Una forma de manejarlo, es usar algo como

http://www.cloudfoundry.com/

Donde permite crear clouds locales. Asi puedes tener el mismo ambiente en todos lados, e implenentar un despacho de codigo automatizado para que cuando actualizes en cloud, se actualizen en los clientes.

[mcs]

mamcx, muchas gracias por tu aportación.

Primero, querría aclararte una serie de temas: El tema de reescritura no es por el traspaso de la aplicación a web. Es porqué la aplicación empezó siendo una cosa pequeñita y ha crecido mucho, hasta el punto que ahora se necesita una limpieza completa. Ya hace tiempo que he leído el famoso artículo de Joel sobre el tema de la reescritura de Netscape 6 (es este que enlazas, no? es que no he visitado el link), y entiendo completamente los problemas y peligros que hay en una reescritura... Pero es que la verdad es que me *interesa* abandonar el actual programa (a parte que el actual es para un único cliente, sin posibilidad de personalización, y con algunos bugs y detallitos).

El tema de versión mixta (cliente local, datos en nube) y de dos versiones (local y nube) los tengo totalmente descartados. Dejando a parte el tema del sobreesfuerzo necesario para crear esto, lo único que se consigue es complicar todavía más la aplicación. Sincronizar versiones, permitir actualizaciones de desktop a web, etc...

Otro inconveniente (bajo mi punto de vista) de la versión mixta, es que tiene "lo malo" de los dos modos de trabajo: se tiene que controlar las actualizaciones de la versión desktop, y además hay el peligro de la seguridad de los datos en internet.

El tema de alquilar un Heroku o un Azure es algo que tengo que mirar. Hasta el momento tenía la idea de simplemente alquilar otro Linode, y allí plantar el Rails, una base de datos Postgre o Mysql, un servidor web light, y ya está. De esta forma me ahorro el trabajo de administrar y vigilar el servidor. Me gusta. De todas formas, no tengo tan claro el tema de la LOPD (Ley de Protección de Datos) usando Azure o Heroku.

Lo de que los usuarios puedan hacer backups de sus datos en csv o xml es algo que siempre he tenido en mente. Principalmente porqué creo que ellos son los dueños, y si quieren usar mi plataforma que sea porqué les gusta, no porqué les secuestro los datos.

Sobre el tema de seguridad local... La verdad, no me preocupa. Si yo ofrezco el servicio de almacenar los datos y la aplicación, yo soy el responsable. Si lo que hago es vender/licenciar la aplicación a Fulanito y él lo tiene en su disco duro, él es el responsable.

Ah, y mis clientes, tal cómo he dicho antes, son todos clientes pequeños. La posibilidad de tener un cloud/instancia privada ni siquiera la voy a plantear, y mucho menos la opción de instalar la aplicación en el servidor del cliente.