Software como servicio

Desventajas de la infraestructura de cloud computing frente al hosting tradicional

noreply@blogger.com (José Antonio Parra Ramírez) — Fri, 22 Oct 2010 08:07:00 +0000

Software propietario / Compatibilidad / Estandarización : Algunos sistemas cloud utilizan sistemas de administracion propios del proveedor por lo que portar un servidor a otra plataforma podria significar hacer toda la migracion manualmente, muy compleja o definitivamente quedar "amarrado" a ese proveedor.

Panel de Control : No todos los sistemas cloud soportan los paneles de control ampliamente usados y estandarizados a nivel de VPS y dedicados, como cPanel, Plesk, DirectAdmin, etc. ( permiten aprovechar toda la experiencia acumulada y principalmente la portabilidad entre distintas plataformas ).

Bloques de recursos / Flexibilidad : Algunos proveedores tienen solo "un bloque" de recursos predefinido con una cantidad determinada de cpu, memoria y disco, por lo que los requerimientos de algunos servidores pueden resultar demasiado costosos.
Ej : si uno necesita una cantidad mínima de ram, debe comprar "x" cantidad de bloques que incluyen cpu y disco que no son necesarios, pero que obviamente se deben pagar ( algunos cloud manejan los recursos en forma independiente ).

Experiencia : La mayoria de los sistemas cloud aun estan en una etapa beta beta con algunos problemas de configuracion y porque obviamente se necesita personal tecnico que domine nuevas plataformas mas complejas ( por ej : interconexion de servidores con una SAN usando fibra optica ).

Tarificación : Cuando se tarifica por horas o consumo de recursos, el sistema de tarificacion solo lo controla el proveedor y es casi imposible poder determinar si los calculos estan bien hechos, hemos encontrado serias diferencias en los costos de algunos cloud probados, ya que el costo diario cobrado ha superado lo que teoricamente deberia costar por un dia según los recursos utilizados ( Se evita al tener un cobro mensual fijo ).

Costos definidos : Con un dedicado o un VPS normalmente hay un costo fijo mensual, con un cloud que tarifica según los recursos consumidos la factura a fin de mes podría ser una desagradable sorpresa, sobre todo si se adiciona el punto anterior ( Ej : un ataque DDOS que consume ancho de banda en forma desmesurada ).

Localidad : al ser una plataforma virtual que puede migrar automáticamente un servidor entre diferentes nodos/clusters/datacenters, se pierde la ubicación física de los archivos lo que ante un problema serio podría implicar que se pierdan en la nube.
No es lo mismo tampoco hablar de Amazon o un cloud montado en un cluster de nodos conectados a una SAN que es algo físicamente mucho mas acotado.

Complejidad : es muy diferente un software para administrar un nodo o un cluster de 4 o 5 nodos, que administrar un cloud formado por varios cluster de nodos que actuan como si fueran una sola unidad; ante una falla del sistema administrador la restauración del sistema podría demorar muchísimo mas que una plataforma mas simple.

Seguridad : Si alguien logra hackear el administrador de un cloud podria poner en peligro decenas o cientos de nodos, hay que recordar lo que paso con HyperVM que al hackear la clave del administrador pudieron tomar el control de datacenters completos y en forma muy simple eliminaron decenas de miles de dominios ( el creador de HyperVM se suicidó ).
Lo mismo para un virus o troyano que pudiera ingresar al software de
administración.

Downtime : Si llega a ocurrir un downtime del cloud, detectar la falla y
solucionarla podria demorar mucho mas que si fuera en un solo nodo o cluster.

Ventajas de una infraestructura de cloud computing frente al hosting tradicional

noreply@blogger.com (José Antonio Parra Ramírez) — Fri, 22 Oct 2010 08:03:00 +0000

Alta disponibilidad : Si un dedicado falla tienes que esperar hasta que se solucione el problema, si es una falla de hardware puede tomar horas.
Si un nodo en un cloud falla el servidor debiera migrarse a otro nodo dentro del mismo cluster automáticamente e incluso a otro cluster de servidores en caso que la falla sea de todo el cluster o a otro datacenter.

Escalabilidad : Si requieres mas potencia de CPU en un dedicado deberías cambiar el nodo completo.
En un cloud puedes agregar y/o sacar cpu's en minutos y en forma dinámica dependiendo de los requerimientos.

Optimización de recursos : Un dedicado se debe comprar pensando en la máxima carga que se va a ocupar.
Un cloud puede dinámicamente utilizar recursos de acuerdo a las necesidades, pagando solo por lo que se necesita en un minuto; por lo que por ejemplo para evaluar sistemas y probar cargas uno podría partir con un core e ir subiendo hasta 8 cores para ver como se comporta un sistema.

Costos : Un dedicado puede significar una alta inversión inicial que se amortiza en varios meses o años.
Un cloud requiere una muy inferior inversión inicial comparada con un dedicado.

Tecnología : Un dedicado usualmente solo tiene UN disco SATA, opcionalmente un RAID-1 SATA, y tener un RAID-10 SAS de 15k significa usualmente gastar mas en el sistema de discos que en el resto del hardware.
Un cloud usualmente cuenta con SAN de alto rendimiento compuesta a veces por hasta 48 discos trabajando en paralelo y usando RAID de mayor confiabilidad como RAID-6 o RAID-50.
El costo de tener tecnología de primer nivel o redundante a veces es inalcanzable en un dedicado.

Portabilidad : Migrar un dedicado a veces requiere una instalación completamente nueva.
Migrar una VM en un cloud se puede hacer creando una imágen que puede ser incluso portada a otro sistema cloud en forma completamente transparente ( Ej : migrar un container Virtuozzo a un cloud basado en VMWare ).
Obviamente un dedicado tambien se podría migrar, pero en un sistema cloud viene todo instalado y es muy simple de operar.

Administración : Un dedicado normalmente no incluye ningún sistema de administración y monitoreo.
Un cloud normalmente integra un sistema de administración y monitoreo que permite realizar muchas tareas en forma muy simple y además llevar estadísticas de uso del sistema.

To Cloud or not To Cloud, That is the question!

noreply@blogger.com (José Antonio Parra Ramírez) — Wed, 29 Sep 2010 11:14:00 +0000

Check out this SlideShare Presentation:

To Cloud or not To Cloud, That is the question!

View more presentations from Diego López de Ipiña.

Computación en la Nube con Amazon EC2

noreply@blogger.com (José Antonio Parra Ramírez) — Wed, 29 Sep 2010 11:02:00 +0000

Check out this SlideShare Presentation:

Computación en la Nube con Amazon EC2

View more documents from Pablo Iñigo Blasco.

Las ventajas no tan obvias de SaaS

noreply@blogger.com (José Antonio Parra Ramírez) — Sun, 27 Jul 2008 07:39:00 +0000

Deberían ser ya de sobra conocidas las estupendas ventajas del uso de SaaS frente a la utilización tradicional de software. En esta ocasión y tras la lectura del último artículo de Sinclair Schuller uno de los bloggeros más reconocidos en el mundo SaaS, me gustaría resaltar algunas otras ventajas no tan obvias que ofrece el Software como servicio:

Cruce del equipo de conocimiento: En grandes corporaciones, equipos múltiples de desarrollo de productos en paralelo, muchas veces indavertidamente, duplican esfuerzos y funcionalidades si no existe buena comunicación entre los equipos. La estandarización sobre una plataforma SaaS crea un equipo comun que transfiere conocimiento. Se crea compatibilidad y los equipos pueden ser empleados para aprender a explotar varias partes de la funcionalidad de la plataforma.

Flexibilidad a largo plazo: Teniendo una verdadera plataforma SaaS como base para la oferta SaaS se crea un nivel de desacoplamiento natural entre la entrega SaaS y la construcción del producto. Esto permite para futros productos construir una plataforma de entrega a un nivel superior desde la plataforma tendente más a la abstracción que a la especialización. Como resultado, la flexibilidad de reutilizar los mecanismos de entrega llega a ser una realidad. En situaciones donde la pila de entrega y servicio estan junto, esto llega a se r muy dificil de ustal sólo calacomo verdadera la plataforma SaaS se crea un lnivel de desacoplamiento natural entre la plataforma de entrega y los productos que se hacen. Esto permite para los productos del futuro construir una plataforma de entrega en el nivel superior desde que la plataforma hasta abstraerse hasta la especialización. Como resultado, la flexibilidad de reutilización de los mecanismos de entrega llega a ser una realidad. En situaciones donde la plin de entrega y servicio son utilizados juntos. Esto llega a ser muy dificil usar solo una plataforma de entrega.

Evolución independiente: Cuando la infraestructura o el software no estrategico están dentro de un producto, la evolución del del mismo afecta directamente al valor de la oferta. Como resultado, esta parte del producto nunca evoluciona, y se acaban perdiendo oportunidades. Utilizando una plataforma desacoplada se permite evolucionar el producto independientemente de la funcionalidad del negocio.

Separación: La separación entre la plataforma de entrega del codigo del producto crea una separación que hace el control de calidad más dificil de lo necesario.

QUE NO ES SOA

noreply@blogger.com (José Antonio Parra Ramírez) — Sat, 21 Jun 2008 17:13:00 +0000

Ante la confusión que esta levantando el termio SOA (Service Oriented architecture) conviene recordar que no es SOA:

SOA no es una plataforma de servicios Web ni la requiere aunque puede ser implantada efizcamente en este tipo de plataforma.

SOA tampoco es un producto. Para que los servicios constituyan valores reales para la actividad de la adminsitración se requieren infraestrugura, herarmientas y métodos. Estos son los productos que ofrecen los proveedores de este tipo de solución.

Estrategia de precios para el modelo SAAS

noreply@blogger.com (José Antonio Parra Ramírez) — Sun, 17 Feb 2008 22:31:00 +0000

Marcar los precios de forma correcta es siempre una tarea dificil. Por ejemplo: Deberíamos marcar los precios basandonos en el valor o en el coste?. Deberíamos enforcar la estrategia de precios para maximizar los ingresos por unidad o por volumen?.

En el modelo SaaS resolver estas cuestiones tampoco es facil, me atrevería a decir que incluso es más complicado. Sin embargo y aunque habria que estudiar cada situación caso por caso, todo modelo de precios SaaS debería cubrir las tres claves principales propuestos por Shully: Impulsar la adopción del servicio SaaS, cubrir costes y generar margenes y beneficios saludables .

Impulsar la adopción: La adopción de los sistemas generalemnte es impulsada bajando la barrera para adquirir la funcionalidad de la oferta SaaS. Se recomienda por tanto ofrecer un periodo de prueba del producto sin coste y que el precio de la funcionalidad base sea lo más bajo posible para reducir la resistencia a la adopción y optimizar la capacidad para atraer a nuevos clientes. Si el precio es demasiado alto, se puede crear una barrera de adopción importante y si el precio es demasiado bajo, al adopción podría impulsarse pero generar perdidas.

Cubrir costes: Generalmente, no es interesante vender con perdidas. El precio por tanto debe permitir recuperar el coste. Parece lógico por tanto que el precio sea significativamente superior al coste para absorver fluctuaciones repentinas. Por otra parte el cálculo de costes debe ser muy preciso y evitar que haya sorpresas operativas en un periodo de tiempo razonble.
Generar Margen y beneficio: La sugerencia en este punto es generar benefico con la venta de la oferta SaaS a los clientes existentes. Si puede utilizar el precio orientetivo para impulsar la acdopción a traves de un bajo coste, debería tener un mercado saludable de cllientes existentes que tienen una resistencia abaja para gastar mas dinero.

En resumen, la estrategia de precios para el modelo SaaS debería seguir una estrategia inicial basada en coste que elimine las barreras de adopción e incremente los ingresos por volumen y seguidamente continuar con una estrategia basada en valor que aumente los ingresos por unidad, para conseguir el objetivo final de obtener un beneficio que resista las fluctuaciones del mercado. Es decir la estrategia de siempre pero "al reves" .....

Microsoft SOA Conference 2007

noreply@blogger.com (José Antonio Parra Ramírez) — Tue, 01 Jan 2008 18:11:00 +0000

El pasado día 4 de diciembre tuve la oportunidad de asistir a la conferencia SOA 2007 de Microsoft. Durante esta sesión la compañía de Bill Gates dio a conocer su oferta de productos y soluciones, y la estrategia de Microsoft en las iniciativas de procesos de negocio (BPM) y arquitectura orientada a Servicio (SOA). La expectación era importante y como suele ser habitual la conferencia no defraudó, al menos en lo que a organización se refiere. Fernando Bocigas, jefe de producto Plataforma de aplicaciones abrió la conferencia y seguidamente tuvimos oportunidad de escuchar a Zubair Murtaza el director de marketing de producto de Microsoft Corporation quien difundio la estrategia de softwre + servicios de Microsoft, para mi lo más relevante de la jornada. Me explico.... Mientras gran parte de la comunidad informatica da, o damos por hecho, que el modelo SaaS está empezando a dejar de ser una tendencia para convertirse poco a poco en una realidad, sorprende que el responsable de marketing de Microsoft aún ponga en cuestión la idoneidad de utilizar este término. Si bien Zubair reconoce la importancia que cada vez más tendrán los servicios frente al software tal y como se ha distribuido tradicionalmente, considera que estos conceptos no están totalmente unidos sino que se complementan. Microsoft acuña el término "S+S" (Software + servicos) frente al "SaaS" (Software como servicio). Lo cual suscita, al menos a mí, algunas dudas que probablemente me decida a despejar en un próximo artículo: ¿En que se diferencia S+S y SaaS?, ¿Es esto tan sólo otro nombre más acuñado por Microsoft para referirse a lo que todos llamamos SaaS? ¿Porque, esa necesidad constante de acuñar nuevos términos?. El resto del evento consistió en una serie de conferencias sobre Biztalk, sus aplicaciones y novedades en la versión 2006 R2 como plataforma SOA de Microsoft. La agenda así como la documentación del evento, esta disponible en la página Microsoft SOA conference 2007.

Los inconvenientes del software como servicio.

noreply@blogger.com (José Antonio Parra Ramírez) — Sun, 25 Nov 2007 17:07:00 +0000

Una vez claros los beneficios que aporta la utilización del software como servicio, y para ser objetivos, conviene explorar "la otra parte de la moneda" y hablar de los inconvenientes que, por suspuesto, SaaS tambien tiene. En esta ocasión, y al igual que hice en el artículo anterior, me he permitido hacer referencia a Abe Sultan y traducir parte de su artículo SaaS 101: The Drawbacks pues creo que es el que mejor sintetiza todos los inconvenientes de este nuevo paradigma.

INCONVENIENTES PARA EL CLIENTE O USUARIO FINAL.

No control directo de los datos - Una de las mayores barreras a eliminar es el control de los datos. Especialmente, ¿que pasa cuando las cosas van mal? Estoy seguro que todas las compañías que intentan venderle un prodycto diran que las cosas no pueden ir mal. Es importante que aborde las cuestiones difíciles: ¿Como de seguros estan mis datos? ¿Seré capaz de bajarlos? ¿Estarán disponible de forma adecuada y de forma segura? ¿Pueden ser vendidos? ¿Puede cualquier otro alojar la aplicación y mis datos? Los fuentes de la aplicación son abiertos y por tanto pueden ser alojados con otro proveedor?. Las historias de compañías que desaparecen no son infrecuentes, y no únicamente compañías SaaS, tambien compañías de software tradicionales. La única diferencia es que cuando una compañía de software trdicional cae, la mayor perdida son los años de soporte que esperabas del vendedor. Cuando un proveedor SaaS cae, las inplicaciones son más profundas al tener que considerar los datos vitales del negocio.

Requiere conexión a internet - No conozco muchas compañías que funcionen sin una conexión a internet en estos días. No obstante, esto podría afectar a sus operaciones si necesita acceder a una aplicación y su conexión de internet se cae. Un buen número de compañías esta intentando resolver este problema permitiendo a sus aplicaciones continuar trabajando en una forma desconectada durante un periodo de tiempo, y sincronizando después con el servidor. Si esta es una gran preocupación para usted asegurese que su proveedor puede cubrir esta necesidad.

Dependencia de un tercero para que funcione su negocio - De alguna manera, usted esta confiando en un tercero para que le asista en el funcionamiento de su negocio, y si no se mantiene hasta el final esto podría afectarle. Para mantener a estas personas en el negocio habría de hacer un contrato de permanencia y asegurarse al menos que en el 95% de las veces este servicio puedan darlo mejor que de forma interna. Lo cual no significa que usted no debería tener cuidado de las implicaciones y asegurarse de poder dar respuesta a estas importantes cuestiones.

Seguridad - Otra gran barrera es la seguridad. Usted esta confiando sus datos más valiosos a alguien más. Esto puede ser una realidad dificil de aceptar pero la mayor parte de las rupturas de seguridad ocurren debido al descontento de los pempleados internos que finalizan y venden o hacen públicos los datos cuando ellos son despedidos o cuando se van. Por tanto la gestión y almacenamiento de los datos por expertos de la aplicación no es tan mala idea como podría pensarse. Además, ellos son los primeros interesdos en asegurar la confianza con el provedor de la misma forma o más que podría confiar en su propio departamento IT interno. Aunque por supuesto no olvide resolver esta importante cuestión con su proveedor.

INCONVENIENTES PARA EL PROVEEDOR.

Enfocarse en la satisfacción del cliente - Esto es una de aquellas malas cosas que es bueno tener y que hacen las grandes compañías pero tenemos que mencionarlo en cualquier caso. Los proveedores de SaaS necesitan enfocarse en la satisfacción del cliente més a mes o ellos perderán a sus clientes. Tienen la necesidad de ganarse el negocio de sus clientes cada mes o si no ellos pueden simplemente dejarlo. En contra de los desarrollos on-premise los cuales son muy costosos y consumen mucho tiempo, si sus clientes no están satisfechos con el servicio pueden dejarlo en cualquier momento con un coste mínimo. Alguien podría argumentar que esto se puede negociar con un contrato a mas largo plazo, haciendo más duro devolver los datos y otra clase de artimañas pero si usted pregunta, esta es una practica aún peor y si usted no es el mejor, entonces será mejor que tenga buenas razones para explicar porque deberían sus clientes firmar un contrato blindado.

Duros procesos de desarrollo - Hay muchos enfoques diferentes para escribir aplicaciones SaaS que están fuera del alcance de este artículo, pero el fondo es que hay un gran conjunto de cosas nuevas por las que usted necesita preocuparse cuando escribe una aplicación SaaS que en otro caso no debería necesitar si fuera un desarrollador de software on -premise. Aspectos como la separación de los usuarios, aprovisionamiento y escalabilidad por mencionar algunas podrían ser aspectos dificiles de abordar teniendo en cuenta que no debería pensar en ellos si estuviesemos escribiendo una aplicación on-premise. A día de hoy hay varias compañías trabajando con plataformas SaaS que hacen todo esto mucho más facil pero ninguna hace más facil el desarrollo de lo que era antes. Otra cosa que hace que el proceso de desarrollo sera más duro es que tanto el talento como las características tecnicas requeridas son más defíciles de encontrar que para un desarrollo on-premise.

Compensaciones - Uno de los problemas más recientes para los proveedores de SaaS es como mantener las operaciones cuando los ingresos son pequeños. A diferencia de los desarrollos tradicionales on-premise donde una oferta podría traer $60.000 por adelantado y financiar un par de meses mientras se cerraban otras ofertas, las ofertas de SaaS son mucho más pequeñas incialmente y se hace mucho más duro mantener las operaciones a menos que el proveedor se financie adecuadamente para poder sobrevivir hasta que la entrada de dinero sea suficiente. Además, la cuestión de como compensar a su equipo de ventas puede ser una de las respuestas que pueden variar grandemente dependiendo de su oferta. Esto puede requerir al proveedor ofrecer salarios base más altos y ser creativos en cuanto a las comisiones. Un ejemplo de este escenario: Vendedor A de una aplicación on-premise para una licencia de 2.500$. Sobre una oferta de 20 usuarios podría ingresar 50.000$ más un soporte adicional de 10.000$ (normalmente un 20%). Fuera de los 60.000$ ellos podrían normalmente darle en cualquier caso entre un 1% a un 4% de comisión de las ventas dejando para la compañía $58.500$ para ejecutar la operación. En un escenario comparable donde el vendedor B con el mismo tipo de aplicación que el proveedor A pero como una aplicación SaaS este probablemente costaría alrededor de 75$ por usuario por lo que en el mismo caso para una oferta de 20 usuarios ingresaría 1.500$ por mes teniendo en cuenta que en 3 años se alcanzarían los mismos 60.000$ que en la compañíaon-premise. El proveedor necesitará tener una buena estrategia sobre como compensar a su fuerza de ventas al mismo tiempo que tenedrá que disponer de suficiente dinero para hacer funcionar la compañía.

Éxito puede ser un problema - Seguro que ha oido hablar en multitud de ocasiones de que demasiado éxito puede llegar a convertirse en un gran problema, en el caso de SaaS esto aplica de forma literal si el proveedor no esta preparado. La cosas pueden quedar fuera de control si la aplicación no tiene una arquitectura apropiada para resolver las cuestiones de escalabilidad y su servicio puede llegar a ser insostenible, sobre todo si no escala apropiadamente con la adición de nuevos subscriptores. Asegurese de no dejar estas cuestiones para más tarde porque podría encontrarse más adelante con un muro en el camino.

Los beneficios del software como servicio

noreply@blogger.com (José Antonio Parra Ramírez) — Sun, 18 Nov 2007 08:50:00 +0000

Si bien en artículos anteriores he hecho referencia a alguna de las ventajas que supone utilizar SaaS o software como servicio, aún no había tratado en profundidad todos los beneficios que ofrece implantar este nuevo modelo. Por ello y con el debido respeto al Sr. Matt Ammerman me he permitido la licencia de traducir parte de su artículo SaaS 101: The Benefits, pues es sin duda la mejor y más precisa recopilación que he encontrado sobre las bondades de este paradigma.

BENEFICIOS PARA LOS CLIENTES.

No necesita intalación y mantenimiento de software ni en el cliente ni en el servidor.

El tiempo de despliegue es más corto. Potencialmente minutos frente a implantaciones que pueden durar meses.

Disponibilidad global. Aunque la tecnología existe para hacer que el software instalado en local sea accesible desde fuera, esta tecnología lo que permite directamente es la disponibiildad desde cualquier lugar utilizando internet de forma nativa.

Suscripción a un acuerdo de nivel de servicio (SLA Service Level Agreement) - Mediante este tipo de contratos el cliente tiene asegurado que sera el proveedor quien asuma el despliegue, la eficiencia de la aplicación y la recuperación del sistema frente a fallos.

Actualizaciones pequeñas y constantes - Cuando se utiliza una aplicación SaaS, es el proveedor es el primer interesado en mantener satisfecho al cliente y por tanto hacer constantes mejoras de la aplicación. Con SaaS esto puede llegar en forma de minisculos cambios en lugar de parches enormes y actualizaciones que cuestan mucho tiempo y dinero implementar.

Reduce los gastos internos de IT - Este es un beneficio muy importante. De todos los beneficios quizás el que más destaca es el gran potencial de SaaS para reducir los gastos de informática frente a los gastos en los que incurre el modelo cliente/servidor tradicional. Esto permite al personal de IT enforcarse en mejorar las operaciones tecnicas diarias de su compañía, en lugar de dedicarse a resolver problemas de software de terceras partes y a mantener su infraestructura.

Reditribución del presupuesto de IT - Por la externalización de la funcionalidad del software a un proveedor, la empresa realizara un ahorro de costes en requerimientos de infraestructura y personal IT cualificado. Esto permite a la empresa infocarse en sus competencias principales. También, permite que el ahorro de costes por el uso de aplicaciones SaaS pueda ser redirigido a otros servicios más productivos.

BENEFICIOS PARA LOS PROVEEDORES.

Agrega entorno operativo: No más envío de tecnicos para instalar o configurar el software porque este no está instalado en una infraestructura altamente-especifica en el cliente. El proveedor tiene el control completo para optimizar una infraestructura según los requerimientos específicos de la aplicación. Esta mayor sinergia es lo mejor y permite ahorros financieros al mismo tiempo que reduce los dolores de cabeza.

Ingresos predecibles - El modelo de subscripción asociado con SaaS permite que los clientes paguen periodicamente. Si este ciclo se hace suficientemente flexible, el proveedor puede obtener una previsión real de beneficios. la cuota puede estar vinculada al producto (igual que los plantes de telefonía móvil) donde cada persona paga según el mismo , mensualmente, anualmente o trimestralmente. En mi opinión, cuanto más flexible sea la cuota, mejor.

Crecimiento Predecible - Igual que el punto anterior, pero aquí se habla de volumen real de subscriptores. El hecho de que los usuarios entren al site para acceder a la aplicación significa que con las herramientas adecuadas se puede monitorizar el uso de forma muy fiable.

Foco sobre las pequeñas actualizaciones frente a lanzamiento de grandes parches - Y mientras el proveedor esta en ello, no preocupa la logistica del lanzamiento sobre las diferentes sedes del cliente. Los equipos de desarrollo del proveedor pueden centrarse en fijar la funcionalidad principal de la aplicación abordando "bugs" y mejorando las caracteristicas en un lanzamiento incremental más pequeño que es tamben más fácil de hacer.

Las ventas llegan por una gestión de relación con los clientes. Cuando el proveedor vende un servicio por subscripción, la obtención de la suscripción llega a ser un balance entre la retención del usuario y el desgaste frente a la consecución de grandes acuerdos "big deals". Seguro que es importante tener un equipo de ventas en la calle para vender la aplicación - por ejemplo obtener suscriptores puerta a puerta - pero la verdadera fuerza de las nuevas ventas y el marketing en SaaS es gestionar las relaciones con los clientes. La ecuación llega a ser muy simple - Mantenga los ratios de retención más altos que los ratios de desgaste y centrese en atraer nuevos clientes.

"LitwareHR" un pequeño ejemplo de SaaS

noreply@blogger.com (José Antonio Parra Ramírez) — Mon, 12 Nov 2007 01:53:00 +0000

Microsoft tendrá muchos defectos, pero entre sus grandes virtudes siempre ha estado la de saber hacer llegar al público la tecnología de una forma práctica. Con SaaS la compañía de Bill Gates lo ha vuelto ha hacer. Mientras los grandes gurús y las grandes compañias como Oracle e IBM, que siempre van por delante ( y no lo digo con segundas), generan cantidades ingentes de papel blanco (white papers), llega Microsoft y publica en su sección MSDN un recurso llamado LitwareHR o ejemplo de aplicación SaaS. Así de facil.

LitwareHR es por tanto la aplicación de referencia de la implementación de un SaaS de Microsoft(Software como servicio). Liberado por el centro de arquitectura MSDN de SaaS, lo más importante de esta aplicación no es lo que hace, sino como lo hace. Básicamente litwareHR tiene dos objetivos principales.

Ser la guía de referencia de la arquitectura SaaS descrita en los documentos publicados por MSDN.

Demostrar como utilizar las tecnologías, .NT Framework 3.0 y SQL Server 2005 en la creación de soluciones SaaS.

Tanto el código fuente de la aplicación como su documentación la tenéis disponible en skyscrapr.net .

SOA y SOI nuevas siglas, viejos conceptos.

noreply@blogger.com (José Antonio Parra Ramírez) — Sun, 04 Nov 2007 20:55:00 +0000

Decir que SOA y SOI son conceptos novedosos no sería justo para quienes, desde hace años, hemos diseñado aplicativos y administrado sistemas con el firme proposito de dar servicio. ¿Acaso los sistemas informáticos e infraestructuras de las operadoras o de los bancos no se han diseñado siempre para dar servicio?, y que hay de los terminos tales como: servicio, servidores, cliente servidor, etc... Efectivamente, conceptos como arquitectura, infraestructura, servicio y la combinación de todas ellos, no son nuevos. Sin embargo, no podemos negar tampoco, que hoy adquieren una mayor importancia y tienen un significado propio dentro de este nuevo paradigma que se ha dado en llamar SaaS. SOA y SOI son por tanto la arquitectura y la infraestructura del software como servicio y sin profundizar demasiado, me gustaría explicar brevemente el significado de cada una de estas siglas que tanto está dando que hablar.

SOA o arquitectura orientada al servicio no es ni más ni menos que un patrón de diseño de arquitectura, como en su día lo fue OOA (arquitectura orientada a objetos) es decir un estilo de arquitectura software pero que a diferencia de la anterior se basa en servicios de aplicación débilmente acoplados y altamente interoperables. La arquitectura SOA es por tanto un marco de trabajo para el desarrollo de software y su implantación. Y aunque la mayoría de las definiciones de SOA identifican la utilización de Servicios Web (SOA y WSDL) en su implementación, una arquitectura soa se puede implementar utilizando cualquier tecnología basada en servicios.

SOI o infraestructura orientada al servicios es un concepto que hace referencia a los aspectos relativos a la infraestructura tecnológica que necesita una arquitectura o solución SOA. Aunque microsoft tiene pefectamente definido su implementación de SOI y open group acaba de empezar, esta infraestructura no es propiedad de ningún fabricante. Básicamente la infraestructura orientada a servicios consiste en una infraestructura virtualizada e industrializada que ofrece servicios de infrasetructura com oun pool de recursos (servidores web, servidores de aplicación, servidores de bases de datos, servidores, almacenamiento) en lugar de instancias discretas.

En resumen, SOA y SOI son modelos conceptuales que no prescriben ninguna tedcnología en particular para su implantación, que definen la arquitectura y es la infraestructura de un sistema SaaS respectivamente y que sin duda merecerán una explicación más profunda en posteriores artículos. Recomiendo para aquellos que no puedan esperar la lectura del blog de CIIN y espacio SOA.

"SaaS ahorro de hasta un 40%"

noreply@blogger.com (José Antonio Parra Ramírez) — Sun, 28 Oct 2007 07:28:00 +0000

De todos es sabido que la principal ventaja del software como servicio "SaaS" es que los clientes pueden acceder a las aplicaciones de forma online, utilizando únicamente un navegador Web y con una tarifa basada en suscripción. Al tratarse por tanto de una aplicación hospedada y gestionada por el proveedor, la gestión del software se simplifica muchísimo para el cliente y evita la necesidad de invertir en la compra de licencias de software. Además, tampoco hay necesidad de instalar el software en cada ordenador, ni de realizar actualizaciones etc... Pero... conocido todo esto, cual es el ahorro que esto produce?. Pues bien, recientemente Arthur Wong, vicepresidente senior de Symantec y presente en SaaScon se ha atrevido a cuantificarlo: "El SaaS puede llegar a reducir el coste total de propiedad de software de una compañía entre un 20% y 40%". Evidentemente, no hay que tomar esto como dogma de fé, y cada cual es libre de creerselo o no. Personalmente y conociendo los costes ocultos de cualquier sistema de información estoy bastante de acuerdo.

SaaS implicaciones para el fabricante de software.

noreply@blogger.com (José Antonio Parra Ramírez) — Sun, 21 Oct 2007 08:34:00 +0000

Hasta aquí he hablado de SaaS como modelo de negocio, previsiones de adopción, estratégias de marketing de diferentes compañías, índices de crecimiento, ventajas, inconvenientes etc.... Pero, ¿Que implicaciones tecnológicas tiene este nuevo modelo para los fabricantes de software?. Pues bien, antes de enumerar las implicaciones directas hay que entender que una aplicación SaaS debe estar diseñada para: Ser escalable, permitir N-Usuarios de N-clientes, Ser fiable y permitir la interacción de múltiples usuarios, su ejecución no debe afectar ni ser afectada por otras soluciones, debería ser capaz de integrar nuevos servicios y funcionalidades y finalmente debería ser extremadamente segura y capaz de personalizarse para cada usuario y cada cliente. ¡Casi nada!. De nuevo, se demuestra que la orientación al usuario implica necesariamente, como en casi todas las áreas de ingeniería, un mayor esfuerzo del fabricante. En consecuencia, los fabricantes que opten por adaptarse al modelo SaaS habrán de abordar:

Nuevo análisis del sistema para pasar del concepto aplicación al concepto servicio.

Rediseño de la arquitectura sobre todo para gestionar la escalabilidad y los recursos de manera que la aplicación de servicio a un número indeterminado de usuarios.

Reescritura del código de las aplicaciones para que den servicio a N-Usuarios y N-Empresas, dentro de un entorno descentralizado.

Las aplicaciones deberán incluir servicios de monitorización, facturación etc, que hasta ahora no incluían.

Deberán dar un soporte 24x7 que asegure a los clientes que las aplicaciones funcionen correctamente en todo momento y solucionen las anomalías que se produzcan.

Deberán cuidar y tener asegurados los datos y las transacciones implementando procesos de seguridad, normas de calidad e infraestructura que garantice los datos hospedados.

Deberán elaborar un plan de mejoras continuas, nuevas versiones y mantenimiento del sistema.

Las implicaciones tecnológicas en los fabricantes del software como todos podemos imaginar son muy fuertes, tanto que gran parte de los fabricantes se verán obligados a desarrollar productos, mejor dicho servicios, totalmente nuevos abandonando los actuales. Pero en cualquier caso y como siempre dígo toda amenza esconde siempre una gran oportunidad. Oportunidad que los fabricantes deben aprovechar para actualizar su oferta y sacar ventaja competitiva de la misma y de la nueva situación.

Los Data Centers no pueden obviar SOA. ¡Hay que empezar ya!

noreply@blogger.com (José Antonio Parra Ramírez) — Sun, 14 Oct 2007 22:04:00 +0000

En opinión de Massimo Pezzini, analista de Garnet, no hay alternativa a las arquitecturas Orientadas a Servicios (SOA). En menos de 5 años, todas las empresas las usarán, independientemente del sector y del lugar geográfico. Que arquitectura SOA implantar no es lo relevante ahora, sino cuando implantarla y como. La respuesta a la primera pregunta es obvia, los centros de datos deberían implantar SOA tan pronto como sea posible para aprovechar la ventaja competitiva que supone ser el primero en dar el paso. En cuanto a la segunda pregunta: ¿Como implantarlo?, siempre es bueno ser prudentes. La recomendación es empezar por poco y crecer incrementalmente, aprovechando la flexibilidad inherente de la pltaforma. Aviso a navegantes..., las compañías europeas no pueden obviar SOA. ¡La decisión correcta es empezar ya!.

Salesforce.com "La confianza plena en el modelo SaaS, clave de su éxito"

noreply@blogger.com (José Antonio Parra Ramírez) — Sun, 07 Oct 2007 16:54:00 +0000

Nadie puede negar que la compañía que fundó Marc Benioff está rompiendo moldes. Pero...¿que hace que una compañía nacida hace tan solo 7 años esté catalogada como visionaria dentro de los cuadrantes de gartner y experimente crecimientos del 71%, tal y como declaró en el último trimestre de este año?. La clave, desde mi punto de vista no es la tecnología sino la confianza absoluta en el modelo SaaS o modelo bajo demanda cómo único modelo de licenciamiento. No en vano, Marc Benioff está considerado como el visionario de Silicon Valley precursor de lo que él mismo dio en llamar "el fin del software" y que hoy abandera con el logotipo que registró que acompaña siempre a su compañía y adjunto en este artículo. Eso y los 13 años de trabajo previo que dedicó a Oracle Corporation claro.

NOTA: Aprovecho esta ocasión para recomendar la lectura de su pequeña biografía que podéis encontrarla en la página web de salesforce.com http://www.salesforce.com/es/company/leadership/executive-team/#benioff. Merece la pena su lectura.

¿Es SaaS adecuado para su negocio?

noreply@blogger.com (José Antonio Parra Ramírez) — Mon, 01 Oct 2007 06:58:00 +0000

Así titula Microsoft, uno de sus recientes artículos de tecnología, http://www.microsoft.com/spain/empresas/tecnologia/saas.mspx. cuya lectura recomiendo, por su caracter didáctico. Además de identificar las ventajas e inconvenientes del nuevo paradigma, lo que considero más transcendente de su publicación es que desde el propio Microsoft se admite que "SaaS" se está configurando como una nueva tendencia en la forma de entender el software. En palabras de David Courtney http://www.coursey.com/About/index.html, prestigioso consultor y autor del artículo "SaaS es una nueva e interesante forma de que las pequeñas empresas adquieran software". Sorprende sin embargo que a día de hoy, la compañía de Bill Gates "el gran visionario de internet y de la computación" no haya introducido esta tecnología en ninguno de sus productos, a diferencia de lo que están haciendo sus más directos competidores Oracle, SAP etc... ¿Es SaaS adecuado para su negocio?, !Por favor, Bill¡, a estas álturas, eso... ni se pregunta.

La revolución del software como servicio

noreply@blogger.com (José Antonio Parra Ramírez) — Sun, 23 Sep 2007 18:30:00 +0000

Según Gartner Group en EE.UU se espera que para el 2011 la utilización del software en la modalidad Saas pase de un 2% a un 25%. Probablemente estemos a las puertas de la mayor revolución de la industria del software desde la aprición de internet.

Servicios TI la nueva era de la informática

noreply@blogger.com (José Antonio Parra Ramírez) — Wed, 19 Sep 2007 17:43:00 +0000

El incremento en la utilización de nuevas tecnologías, así como el uso cada vez mayor de nuevos aparatos y más sofisticados ha hecho que muchas empresas se vean incapaces de gestionar de manera correcta sus recursos informáticos. Y es que además de saber gestionarlos de forma adcuada, el mantenimiento de los equipos y de la infraestructura informática implica, en numerosas ocasiones un elevado coste que las compañías son incapaces de asumir. Así que la opción pasa por los servicios: Es decir, que empresas expertas, conocedoras de las máquinas, los programas y las redes gestionen todo este entramado de forma correcta y a a un coste apropiado. Esta necesidad da origen al llamado SaaS o Software como servicio.