Archivo para la categoría Cloud computing

El Software como Servicio y Aplicaciones Web

Software como Servicio y Aplicaciones WebEl Software como Servicio (mejor conocido como SaaS por sus siglas en inglés de Software as a Service), es hoy día una de las tendencias más tangibles y fuertes en el mundo de la tecnología. Cuando hablamos de Computación en la Nube o Cloud Computing, muchas veces estamos hablando realmente del Software como Servicio. Podemos decir que Infraestructura como Servicio (IaaS: Acceso, vía Internet, a recursos computacionales de hardware), Plataforma como Servicio (PaaS: Acceso, vía Internet, a recursos de desarrollo de software) y Software como Servicio son las tres principales variantes que conforman el movimiento de Computación en la Nube.

¿Software vía Internet? ¿Pero no son las aplicaciones Web, software que se usa y se consume vía Internet? Efectivamente así es. Pero entonces, las aplicaciones Web tienen años desarrollándose. Desde finales de la década de los 90s ya se hacían desarrollos en PHP o en ASP. Entonces, ¿porqué SaaS es una tendencia nueva? Bien, la respuesta corta es que efectivamente todo el software como servicio son aplicaciones Web (ya sea tradicionales o también algunas aplicaciones para móviles). Sin embargo no todas las aplicaciones Web pueden ser consideradas software como servicio. Más bien yo diría que, hoy día, muy pocas podrían ser consideradas así.

La diferencia esencial estriba en el concepto de Multitenancy. Este concepto tiene ligeramente diferentes significados (aunque todos similares) ya sea que estemos hablando de IaaS, PaaS o SaaS. En el caso del software se refiere a la capacidad que éste tiene de tener varias empresas usuario (o tenants) en la misma instalación de software. Por ejemplo, si un sistema CRM debe prestale el servicio a dos empresas que nada tienen en común, y además dicho CRM no necesariamente tiene que ser instalado dos veces (una vez para cada empresa), entonces estamos hablando de SaaS. Es decir la misma instalación de software (y la misma instancia de ejecución de dicho software) atiende a dos o más empresas distintas. De hecho, típicamente atiende a muchas empresas con una sola instalación.

En los casos donde se tuviese que hacer una nueva instalación del software por cada empresa usuaria (aunque fuese en el mismo servidor Web), entonces estaríamos hablando de una aplicación Web normal. Dicho de otro modo, para ser SaaS la empresa usuaria del software, debe tener una clave y una contraseña (típicamente muchas de hecho, para cada uno de sus empleados) que le permita al software saber de qué empresa se trata.

A nivel técnico crear software SaaS tiene algunas implicaciones. La más importante quizá (pero no la única) es que la Base de Datos debe estar bien diseñada para soportar Multitenancy, típicamente con algún mecanismo (existen varias soluciones) para que en sus tablas de información se guarde el código de empresa y, de esa manera, fácilmente la aplicación pueda mantener una “Vista” de la información de la empresa.

¿Y si usted es un proveedor de software que quiere desarrollar SaaS versus una Aplicación Web tradicional? Bueno, debe tener esto claro, para poder diseñar adecuadamente el software y más importante aún para hacer las adaptaciones a su modelo comercial (ya no licencia o venta del software sino vía alquiler del mismo). En mi caso particular, con Arckanto software estamos ya inmersos en la conversión de una aplicación Web (sistema de operaciones microfinancieras) hacia el modelo técnico y comercial de Software como Servicio.

¿Y si usted es una empresa que quiere desarrollar SaaS para su propia empresa o para beneficio de sus clientes individuales (como lo hacen hoy día la mayoría de los bancos, por ejemplo)? En este caso la diferencia entre SaaS y aplicación Web no tiene mayor relevancia, quizá ninguna. ¿Y si usted es una empresa que quiere comprar o rentar software? Bueno, tener claro que tendrá varios beneficios si el software es verdaderamente SaaS y no solo una aplicación Web tradicional, siendo los dos principales beneficios el que no tiene que desembolsar una inversión grande inicial en licencias (aunque el costo final es similar en ambos casos) y el hecho de que las actualizaciones y mejoras del software usted las obtendrá de manera automática (pues el proveedor mantiene una sola instancia de la aplicación).

Al final, quizá lo importante de todo esto es que el mundo del software está cambiando a ritmo vertiginoso. Precisamente el mes pasado di una charla sobre Tecnologías Emergentes para las cámaras de tecnología de información y de exportadores de Costa Rica (CAMTIC y CADEXCO) donde les describía esta tendencia: el 85% (¡sí, 85%!) del nuevo software para el año 2015 será entregado a las empresas bajo el modelo SaaS, de acuerdo a este artículo de la empresa Samanage basado en datos de la consultora Gartner. Es una buena noticia para todos, tanto empresas como proveedores de tecnología. A nivel mundial existe ya mucho software de negocios entregado bajo el modelo SaaS, aunque en América Latina es aún muy incipiente. Pero hay que ir pensando en el cambio ya.

Y finalmente, este video explicativo (versión inglés) de InfoWorld, sintetiza muy bien en dos minutos los principales elementos del concepto de SaaS. Recomendado.

, , , , , ,

2 comentarios

AngularJS y nuevas posibilidades para las aplicaciones Web

AngularJS

AngularJS Architectural Overview

Recientemente en Arckanto software estoy desarrollando una aplicación Web para automatizar un proceso de negocios operativo de una institución microfinanciera. Al margen de las características funcionales, el desarrollo técnico está basado principalmente en una base de datos MySQL y en el framework de desarrollo Yii, el cual por cierto ha resultado una gratísima sorpresa para mi. Perfectamente podemos imaginar a Yii como el Rails pero para el mundo PHP: Un sólido framework basado en el patrón MVC y la filosofía de “Convention over Configuration”.

Pero en realidad, este post no está dedicado a Yii (quizá en otro post futuro comentaré más de él) sino a otra tecnología: AngularJS. Resulta que para poder desarrollar alguna de las características de la aplicación mencionada, requería muchos elementos de programación del lado del cliente en lenguaje javascript (o sea, programación a ser ejecutada por el Navegador mismo). Aunque antes había hecho algunas pequeñas cosas en javascript, principalmente en jQuery, en realidad no había profundizado mucho en el tema.

Esta vez requería un poco más de “inteligencia” del lado del Browser porque requería calcular totales, subtotales y validaciones relacionadas, antes de “postear” (enviar) la información al servidor y la aplicación Yii. Así que decidí investigar un poco el tema y vi que existen muchos frameworks javascript para desarrollar modernas aplicaciones Web (single-page applications) que requieran mucha interactividad en el Navegador. Algunas de los frameworks más relevantes son Backbone.js, Ember.js, Knockout.js y otros. Pero el que más me llamó la atención fue AngularJS (la razón bastante técnica para describirla en este post pero en síntesis puedo decir que fue debido a su filosofía de no manipular el DOM desde los controladores sino separarlo completamente usando Directivas: Controlador imperativo y View Declarativo).

AngularJS es un framework javascript desarrollado e impulsado por Google (así que imaginarán el respaldo que tiene) orientado a lo que se llama “Single-Page Applications” que se traduce en Aplicaciones de una sola Página (este tema por sí solo merecería otro post). Llamadas así porque todo el sistema reside en un solo archivo HTML, y desde él se llaman a todos los controladores javascript que le dan forma al funcionamiento del sistema. ¿Impresionante, no? Todo el sistema en una sola página. Bueno, aunque así se llaman y efectivamente una página puede contener todo el sistema, la realidad es que uno puede tener varias páginas Web (especie de módulos) que juntas forman un amplio sistema Web. Dicho de otro modo, no es necesario que estén en una sola página pero esa es la intención.

Eso da una interactividad enorme a la aplicación pues mucho de la lógica es ejecutada por el Navegador mismo. AngularJS quedó como “anillo al dedo” para lo que yo requería. Pero lo más importante para mi fue que en el proceso entendí (o más bien, estoy entendiendo) todo lo que significa desarrollar en AngularJS (o con un framework javascript; javascript puro en el caso de AngularJS) y cómo puede interrelacionarse este tipo de aplicaciones con aplicaciones del lado del servidor (como Rails o Yii) basadas en una base de datos central.

En mi opinión, todo este movimiento de frameworks javascript, con AngularJS como un ejemplo icónico, vendrá a fortalecer muchísimo el desarrollo de aplicaciones de Nube. Es el complemento ideal de Rails o de Yii, estos siempre necesarios para darle solidez al backend y la persistencia de datos. Pero ahora el desarrollo Web logra emular en interactividad, sino es que superar, los antiguos desarrollos para Desktop. Ergo: Es la tendencia. Por ahí está gran parte del futuro de las aplicaciones Web de Nube, sin duda.

Reflexión final: ¿No será que todo tiende a ser cíclico? De Mainframes a PCs. De PCs a Cliente/Servidor. Y se reinicia el ciclo: De sistemas centrales Web a sistemas distribuidos y comunicados con arquitectura REST (algo así como de nuevo en cliente-servidor). Pero claro, esta vez yo obviamente no apostaría por VisualBasic y MS-SQL-Server como amplia base de difusión tecnológica. Apostaría por AngularJS (en el cliente), más algún framework MVC de servidor (preferiblemente Ruby on Rails), más MySQL y/o MongoDB como Bases de Datos. ¿Qué tal suena? Veremos…!

Mientras, aquí “Hola Mundo” en AngularJS:

, , , ,

4 comentarios

El mundo de las bases de datos NoSQL

El escenario de las Bases de Datos

Fuente: The 451 Group

En un post anterior intentaba describir algunas alternativas de Bases de Datos de Nube. Específicamente me enfoqué en bases de datos con el modelo relacional: AmazonRDS, ClearDB, Xeround, Database.com, VoltDB, etc. Sin embargo no comentamos nada acerca del modelo alternativo: el NoSQL. Bajo este concepto se agrupan un buen número de productos de base de datos, con muy diversos modelos conceptuales y soluciones técnicas, cuyo denominador común es que no siguen el modelo de bases de datos relacional. No basan su gestión en el lenguaje SQL.

¿De qué se trata entonces el NoSQL? Bueno, lo que sucede es que estas soluciones han venido a llenar un importante carencia de las bases de datos relacionales en cuanto a la capacidad que estas tienen en escalabilidad, distribución y manejo de datos no estructurados. Estas 3 características resulta que son cada día más relevantes debido precisamente a la Nube; a los múltiples y diversos servicios cuyo crecimiento y replicación distribuida son extremadamente necesarios: ¿cómo estructurar, por ejemplo, la información almacenada por Google o Facebook? ¿cómo asegurar que nuestra información en la Nube siempre estará disponible? ¿cómo manejar el explosivo crecimiento de información y su variabilidad de formatos? En síntesis, ¿cómo manejar el problema de almacenamiento del Big Data?

De hecho, existen muy buenos artículos que detallan con profundidad el problema de las bases de datos relacionales. Recomiendo mucho que lean “NoSQL, NewSQL and Beyond” que presenta concisa pero analíticamente este problema de las bases de datos relacionales acuñando inclusive el término “STRAINED” (torcidas o exprimidas, en español) con las iniciales de cada uno de los problemas que tienen.

El hecho es que, a raíz de esta problemática han surgido los modelos NoSQL (y también, aunque menos conocidos, los NewSQL que se comentan en el artículo mencionado). Entre los principales modelos NoSQL y algunos productos insignia de cada modelo tenemos:

Modelo: Documental
Descripción: Guardan documentos textuales y/o XML, principalmente en formato JSON, con la finalidad de almacenar información con estructura laxa y cambiante. Ideal para servicios que requieren almacenar transacciones o datos enviados desde dispositivos móviles que usen JSON para intercambiar información.
Productos insigne: MongoDB (por mucho la BD NoSQL más usada en el mundo), CouchDB

Modelo: Almacén Llave-Valor (Key-Value Stores)
Descripción: Enfocadas en el almacenamiento de información de configuración o basada en arreglos asociativos (hashes). Su intención es guardar simplemente una gran serie de “llaves” con su valor asociado lo cual da una potente flexibilidad ante datos no estructurados.
Productos insigne: Redis, Amazon DynamoDB

Modelo: Orientadas a almacenamiento de Clusters Distribuidos – Big Tables
Descripción:
Orientadas en el almacenamiento de enormes cantidades de información desestructurada que es almacenada de manera distribuida en cientos o miles de clusters en localizaciones geográficas incluso distintas. Típicamente basadas en almacenamiento en innovadores sistemas de archivos y usando el cada día más relevante algoritmo Map-Reduce.
Productos insigne: Hadoop, HBase, Cassandra

Esos son los principales pero realmente están emergiendo modelos cada día más innovadores enfocados en retos distintos y con diferentes capacidades y orientaciones. De hecho, los modelos y productos descritos arriba tienen fronteras poco claras y por tanto varias características de un producto podrían clasificarlo dentro de otro modelo.

Todos estos modelos aprovechan la tendencia al “relajamiento” de la integridad de la información en beneficio de la replicabilidad y disponibilidad de la información. Por ejemplo, ¿han notado como Facebook en ocasiones no representa exactamente la misma información dependiendo de dónde o cómo accedamos a él? Eso es porque estos servicios “relajan” la integridad la cual hacen “eventualmente” consistente. Pero no siempre consistente en tiempo real.

Ello debido al Teorema de CAP que en esencia nos dice que la información, en un cluster distribuido y replicado, podrá estar siempre disponible o siempre consistente pero no ambas. Pero realmente, ¿a quién le interesa que Facebook o Twitter se tarden unos segundos o un par de minutos en hacer consistente la información? Casi a nadie. Lógicamente en ambientes empresariales la integridad y consistencia es esencial y por eso la gran solidez histórica de las bases relacionales.

Y es precisamente a la última frase del párrafo anterior que las bases de datos relacionales no solo no están muertas sino que son más importantes y relevantes que nunca. Las aplicaciones empresariales internas y estructuradas seguirán requiriendo de la integridad y estructura eficiente que este modelo privilegia. Las bases de datos relacionales seguirán teniendo vigencia, sin duda. Lo que pasa es que el modelo NoSQL viene a solventar otro tipo de necesidades de almacenamiento y recuperación de información que han aparecido en años recientes principalmente debido a los servicios de Internet, la Nube y la problemática del Big Data. En síntesis, ambos modelos pueden perfectamente coexistir y tener validez en los desarrollos de software. Simplemente que los Developers necesitaremos ser bilingües o, mejor dicho, políglotas para poder aplicar el modelo de base de datos correcto dependiendo de la necesidad de negocio específica que tengamos entre manos. El mensaje para el SQL y el NoSQL es “zapatero a tus zapatos”.

¿Y entonces.. con qué debo iniciar si quiero empezar a usar NoSQL? A menos que tu proyecto tenga realmente una problemática grande debido al enorme volumen de datos y distribución en clusters (en cuyo caso Hadoop o Cassandra podrían ser la vía) lo típico es que uno empiece usando el modelo documental (MongoDB es el líder; es el MySQL del mundo NoSQL) o el de Key-Value Stores (con Redis, por ejemplo).

Voilá!

, , , , , ,

3 comentarios

El escenario de las Bases de Datos de Nube

No me queda ninguna duda que el movimiento de Software-as-a-Service (SaaS) ha llegado para quedarse. Dicho de otro modo, que las aplicaciones en la Nube será el nuevo modelo de entrega de aplicaciones tanto de servicios de consumidor (a la manera de Facebook o Gmail) como de sistemas empresariales (a la manera de Salesforce.com). Lógicamente aún falta mucho por hacer y resolver para que todo esto se haga completa realidad en el ambiente empresarial. En particular, los temas de seguridad y accesibilidad (y velocidad) a la red son los principales problemas, al menos en Latinoamérica; aunque en ambos casos son cada día mejores los avances y menores las preocupaciones.

¿Y qué está pasando con el almacenamiento de datos? Mucha oferta e incertidumbre. Pues sí, aún se mantienen modelos y productos de bases datos sólidos y muy probados. MySQL sigue teniendo mucha “momentum” entre los developers como primera opción para el almacenamiento de los datos de sus aplicaciones. Sin embargo, cuando se habla de aplicaciones de Nube éstas deben ir de la mano de productos de bases de datos de Nube (DBaaS, por Database as a Service), que resuelvan principalmente los temas de elasticidad y escalabilidad. ¿Soluciones? Bien, pues básicamente tenemos dos enfoques: SQL y NoSQL. En este post abordaremos las alternativas basadas en el modelo relacional (SQL) y dejaremos para un post posterior el tema interesantísimo de las bases de datos clasificadas como NoSQL.

Importante mencionar que el modelo SQL está mejor orientado a aplicaciones empresariales internas cuyo modelo de datos es más estructurado; tales como las aplicaciones de procesos de negocios: ERP, SCM, CRM, etc. En cambio NoSQL está más asociado con el almacenamiento de datos externos a la empresa, más de tipo social o de analítica de datos externos. Es decir, donde el almacenamiento de información no tiene una estructura tan clara: datos Facebook, aplicaciones integradas a redes sociales o servicios móviles, almacenamiento de servicios de Nube al consumidor y/o de analítica de datos, almacenamiento de documentos JSON, etc. Claro; esto es solo una generalización porque la solución óptima dependerá de cada caso específico.

Bueno, como decíamos, MySQL sigue estando en un lugar de privilegio. Específicamente en cuanto a productos que le dan a MySQL las características de Nube, tenemos tres principales: Amazon RDS, Xeround y ClearDB. Todas ellas promocionadas como el MySQL para la Nube por lo que tienen la ventaja de un modelo probado y conocido pero con características de Nube. Otra buena alternativa desde un producto conocido es la solución provista por Heroku para la base de datos PostgreSQL. Bajo esta se provee de una base de datos PostgreSQL pero con el modelo Nube. Así que los developers que se han visto más cómodos desarrollando en Postgres que en MySQL pueden también hacer uso ya de características propias de Nube utilizando el servicio de Heroku.

También, como comenté en un post anterior, Database.com se presenta como el nuevo modelo de bases de datos para la Nube. Ofrece elasticidad y escalabilidad transparente así como una serie de herramientas para el Developer enfocadas en el desarrollo de servicios de Nube, móviles y sociales. Desventaja importante: no la puedes bajar e instalar en un ambiente local. Aunque esto último no es estrictamente necesario, ni siquiera recomendable en un ambiente de producción Nube, sí resulta conveniente para el Developer en ciertos contextos de desarrollo.

Además, existe un buen número de bases de datos relacionales que ofrecen características de escalabilidad y desempeño. La más interesante de todas es quizá VoltDB, del gurú de bases de datos Mike Stonebraker. Sin embargo, desde mi percepción resulta desventajoso que aún no tenga versión Nube 100% sino que aún maneja únicamente el modelo descargue-instale-use.

¿Qué hacer? Bueno, a diferencia de mis primeras opiniones positivas respecto al uso de Database.com, creo que esta base de datos es la mejor opción únicamente si tu aplicación estará instalado en la plataforma Force.com ó si tendrá interacción fuerte con esta. Particularmente si tienes servicios integrados con Salesforce. De lo contrario, veo desventajoso utilizar una base propietaria que no pueda ser transferida a otros contextos.

Me parece entonces que si eres un developer MySQL, lo mejor será utilizar alguna de las opciones de Nube. En mi opinión Xeround parece tener la mejor oferta técnica aunque habría que analizar con mayor profundidad si ClearDB o Amazon RDS están al mismo nivel. Y sólo recomendaría PostgreSQL si tu aplicación Nube está operando en Heroku. En este caso, lo mejor sería dejar un ambiente compacto completo en Heroku que es la plataforma que tiene una de las ofertas técnicas más sólidas en cuanto a PostgreSQL para la Nube (existen otras como EnterpriseDB, por ejemplo).

Sólo a manera de contexto sobre lo que estamos hablando, aquí un par de videos con un “vis a vis” de Database.com y Xeround (MySQL on the Cloud) :

Difícil, ¿eh? Y esto sólo tomando en cuenta el modelo relacional. Aún falta el modelo NoSQL que es todo un mundo complejo e interesante para el uso de almacenamiento de servicios Nube. En otro post abordaremos este tema.

, , , , , ,

1 comentario

¿Force.com y Heroku: Hermanas con distinta personalidad?

Platform as a Service - PaaSEn un anterior post mencionaba las diferencias generales de las plataformas como servicio (PaaS) Force.com y Heroku, hermanitas pues ambas son propiedad de la compañía Salesforce y actúan bajo la sombrilla de ésta. Al margen de lo comentado en dicho post hay también otro tipo de diferencias. Más sutiles. Más de personalidad o espíritu de cada plataforma. Porque, aunque hoy día pertenecen al mismo grupo empresarial, sus historias son bastante diferentes. He aquí mi percepción:

Orientación y enfoque
– Force.com. Orientacion a procesos y aplicaciones tradicionales de negocios. Su enfoque básicamente está en resolver necesidades organizacionales: ventas, finanzas, gestión del talento, marketing, servicio a cliente, etc.
– Heroku. Orientación de aplicaciones de servicios stand alone. Su enfoque resuelve aplicaciones de negocios de servicios: Shopping Carts, Mensajería, Sitios Web de cupones de descuentos, etc., así como servicios innovadores o estilo software de Start-up tecnológica.

Usuarios de las aplicaciones creadas en cada plataforma
– Force.com. Usuarios internos (funcionarios y ejecutivos de negocios) de la empresa que usan la aplicación desarrollada.
– Heroku. Usuarios externos a la empresa, típicamente clientes, y público en general a escala masiva.

Estilo de desarrollo
– Force.com. Desarrollar en esta plataforma se parece bastante al trabajo de configuración de aplicaciones. Click aquí, click allá, parámetro por aquí y listo, ya tienes el sistema funcionando.
– Heroku. Desarrollo de software más intensivo. Se programa mucho más que en Force.com pero también se tiene un mucho mayor grado de control sobre el software creado.

PaaS orientadas a proporcionar servicios a distinto nivel
– Force.com. A nivel Aplicación. Le ofrece a los developers muchos elementos ya solucionados en Salesforce y reutilizables para construir sus apps. De este modo, el software construido se parecerá mucho a las aplicaciones nativas de Salesforce.
– Heroku. A nivel Infraestructura de desarrollo. Le ofrece a los developers muchos elementos del entorno tecnológico Cloud para que construyan sus apps. Por ejemplo, servicios de mensajería, sincronización de apps en tiempo real, persistencia políglota, APIs REST a otros servicios Nube, etc.

Ingenieros usuarios de la plataforma
– Force.com. Colegas de traje y corbata. Típicamente del mundo de los negocios. Developers y Tech Savvy´s pero con mucho enfoque, estilo y espíritu del mundo de los negocios.
– Heroku. Desarrolladores de base y “línea dura”. Estilo más “a lo start-up” y sin muchos formalismos empresariales. Altamente especializados y considerados “Geeks”.

Objetivo de servicio
– Force.com. Las aplicaciones de Force.com son más intensivas en Datos y Gestión de la Información (Data-centric).
-Heroku. Las aplicaciones de Heroku son intensivas en aprovechamiento de lnfraestructura tecnológica y servicios de Nube (Architecture-centric). Muy orientadas a uso de APIs de servicios de terceros.

Clientes típicos que atienden
– Force.com. Los clientes de las aplicaciones de esta plataforma tienden a ser grandes empresas y trasnacionales. Prácticamente el mismo segmento de mercado “SAP & Oracle”.
– Heroku.com. Los clientes de las aplicaciones de esta plataforma tienden a ser pequeñas y medianas empresas (Small Business, SME ó Pymes) y/o Start-ups tecnológicas.

Lógicamente lo anterior son simplemente “Generalizaciones”; y como toda generalización, tiene sus excepciones. Lo que quiero decir es que las distinciones anteriores son principalmente (aunque no en todos los casos) “por costumbre, comunidad y estilo”. Nada impediría a un developer Heroku usar traje y corbata, como nada impediría a un developer Force.com desarrolar ahí una idea “Start-up style”. Después de todo, ambas PaaS están exclusivamente orientadas a aplicaciones de Nube al estilo Software-as-a-Service (SaaS), y con integración de aplicaciones móviles y sociales. Y ambas lo hacen muy bien.

¿Cuál prefieres tú? ¡Hasta pronto!

, , , , , ,

Deja un comentario

SaaS y ¿cómo “juega” Heroku en el mundo Salesforce?

Recientemente Salesforce ha anunciado que seguirá apoyando sus dos plataformas de desarrollo de aplicaciones para la Nube: Heroku y Force.com. Esto podría parecer extraño dado que ambas plataformas están diseñadas para alojar aplicaciones Web de Nube. Sin embargo las razones que Salesforce aduce me parecen muy lógicas: Force.com es una plataforma de desarrollo de aplicaciones de procesos de negocios. Básicamente los usuarios de estas aplicaciones son el personal mismo de las empresas. Por otro lado, Heroku está orientado a aplicaciones masivas de tipo “público”. Las aplicaciones de Nube en Heroku son más usadas por el público en general (Twitter, Groupon, Shopify, etc.) ya sean clientes o no de una empresa en particular.

La división anterior me parece no sólo natural sino que también nos indica una clasificación de las aplicaciones de Nube. OJO: No estoy diciendo que en Salesforce no se puedan alojar aplicaciones masivas ni que en Heroku no se puedan hospedar aplicaciones de negocio de backoffice. Sin embargo, la clasificación resulta bastante lógica. Me explico.

Heroku tradicionalmente ha venido apoyando el mundo de los Desarrolladores Ruby (y Ruby on Rails) para que desplieguen sus habilidades técnicas en iniciativas empresariales de desarrollo de aplicaciones masivas de alta calidad. Su orientación es más que nada hacerle la vida fácil al desarrollador o empresario de software para crear de manera relativamente sencilla sus aplicaciones y poder desplegarlas en un ambiente de producción optimizado, moderno y seguro. Para ello, da acceso a muy valiosas extensiones o “add-on´s” que añaden mucha funcionalidad a las aplicaciones ahí alojadas.

En cambio Force.com ha venido siendo la plataforma idónea para desarrollar aplicaciones de negocios ligadas al CRM de Salesforce y sus otros productos. Ha servido como una buena vía para extender las capacidades del CRM de Salesforce y crear otras aplicaciones alrededor de él. Inclusive sistemas completos de negocios, estilo ERP, que son tan o más grandes aún que el CRM original de Salesforce.

Mi propuesta personal: desarrollar productos de software (modelo software as a service SaaS, lógicamente) desplegados sobre Heroku y creados en Ruby on Rails pero accediendo a información contenida dentro del CRM de Salesforce. De hecho, ya existen buenas herramientas de integración de información para esta vía y, de acuerdo a los ejecutivos de Salesforce, la integración será cada día mayor (es lógico pues ambas forman parte de la misma empresa global). En síntesis, concibo algo así como Backoffice con Salesforce, Force.com y otras aplicaciones de negocios maduras (Financial Force, por ejemplo), mientras que productos de Frontoffice con Rails sobre Heroku pero integrados con los productos Salesforce mencionados.

Voilá. Y con ello tendremos un completo set de productos de software para la Nube. ¡Hasta pronto!

, , , , , , ,

1 comentario

[Video] ¿Qué es el software como servicio?

Con tanto “ruido” y novedades acerca del Cloud Computing y el Software-as-a-Service he notado que existe algo de confusión con los términos. Inclusive existe un sobreuso de los mismos. Debido al “momentum” tan positivo que existe para las aplicaciones en la Nube, muchos proveedores de software mercadean sus aplicaciones de negocios como “de Nube”. Aunque muchas de ellas sí lo son, existe una gran mayoría que únicamente aprovechan el concepto para vender sistemas de información con un modelo ya bien conocido: el de proveer una aplicación vía la Web o Internet. Esto no es necesariamente “Software como Servicio” (o aplicaciones de Nube).

Un excelente video que nos clarifica varios conceptos acerca del Software-as-a-Service o aplicaciones de negocio “en la Nube” es el siguiente, creado por la empresa norteamericana Salesforce. El video es muy bueno; lo recomiendo. Y por supuesto, debo aclarar que aunque no tengo ninguna relación con esa empresa, sí tengo en cartera de mis servicios, la consultoría de implantación de productos de Salesforce.


Fuente del video: Salesforce.com

¿Qué distingue entonces a una aplicación de negocios “de Nube” o al software como servicio? OJO: No estoy incluyendo aquí el servicio de Infraestructura de Hardware en la Nube (Infraestructure as a Service – IaaS) sino especícamente el caso del software de aplicaciones de negocios en la Nube. Sus características distintivas:

  1. Existe una sola aplicación (una sola instalación) para muchas empresas clientes. Es decir, usa Arquitectura Multitenancy (en el video esto lo traducen como Multiusuario). Y por tanto, la aplicación debe ser escalable.
  2. Cada una de las empresas clientes podrá configurar su propia aplicación y determinar los usuarios que la usarán. El uso del software se realiza vía el browser o navegador de Internet.
  3. El modelo de uso del software es vía renta o suscripción. La aplicación no es instalable en equipos de la empresa cliente, ni dentro ni fuera de ella. Y lógicamente no existe el concepto de “licencias de uso”.
  4. No importa, en lo que a la aplicación concierne, qué infraestructura de hardware la soporta. El hardware no es de la empresa que usa la aplicación y tampo esto debe ser importante para la empresa cliente.
  5. Los beneficios principales son: costo menor; accesibilidad desde cualquier lado y en cualquier momento; actualizaciones automáticas (siempre al día).

Creo que la mayor confusión que existe es al confundir una aplicación de Nube y una aplicación Web. Las aplicaciones de Nube son necesariamente aplicaciones Web. Pero no viceversa pues la gran mayoría de las aplicaciones de Internet no están basadas en Arquitectura Multitenancy.

That is it. Eso es. Entonces cuando les ofrezcan una aplicación de negocios de Nube o Software-as-a-Service, regresen a ver los 3 minutos del video y pregúntense si el software es realmente de Nube.

, , , , , ,

1 comentario