Entradas etiquetadas como Database.com

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

Algunas razones de porqué elegiría Rails + Database.com + Heroku para una solución de Nube … Parte 2

En la primera parte de este post, había descrito las razones por las que yo elegiría Ruby on Rails para el desarrollo de un sistema Web. Al final, comentaba que me parecía que la base de datos ideal debería ser una basada en la Nube y que Xeround (MySQL cloud based) podría ser la opción idónea. Sin embargo, existe una fuerte alternativa. Se trata de Database.com, el producto de base de datos de Salesforce que también está orientada a aplicaciones en la nube (tal como lo es Salesforce).

Me parece que, aunque ambos productos son sólidos (Xeround y Database.com) y tienen las características adecuadas, existe una poderosa razón de mercado y de negocios que favorece la opción de Database.com. Este producto es el que Salesforce utiliza para sus aplicaciones CRM basadas en la nube y que utiliza también en su plataforma de desarrollo Force.com, la cual está ganando mucho momentum en los últimos meses.

Dicho de otro modo, una nueva aplicación de negocios que use Database.com estará íntimamente ligada desde el punto de vista técnico con los datos y las aplicaciones nativas de Salesforce (aunque uno podría usar Database.com sin depender de la plataforma Force.com). Y una integración natural con el líder del mercado en aplicaciones de negocios para la nube representa un potencial valor de mercado de una eventual futura aplicación de negocios. Inclusive existe también la posibilidad de alianzas estratégicas futuras no sólo con Salesforce sino con muchos otros proveedores de aplicaciones de negocios del ecosistema de Force.com.

4. Plataforma de desarrollo y deployment Heroku.com. Existen varios, y muy buenos, proveedores de servicios que ofrecen un óptimo deployment de una aplicación Ruby on Rails. Uno de los mejores es Heroku.com. Ofrece un medio ambiente y plataforma sólida para aplicaciones Ruby, una arquitectura Multi-tenancy natural, múltiples Add-on´s que pueden enriquecer y apalancar las aplicaciones desplegadas en Heroku, y una reputación excelente como proveedor de servicios Platform-as-a-Service (PaaS).

Aunque pudieran existir otros proveedores Ruby (Engine Yard, en particular), Heroku recientemente ha adquirido una enorme ventaja de mercado ya que fue comprada en enero del 2011 por Salesforce. Al margen de la ventajosa liquidez financiera que esto trae para Heroku, es también de esperar entonces que Heroku y Force.com vayan siguiendo rutas técnicas paralelas o con una integración mejorada. Dicho de otro modo, Salesforce está también apostando por el ecosistema Ruby on Rails, paso lógico dado que Apex (el lenguaje de programación usado en Force.com) es muy cerrado y no cuenta con una comunidad fuerte de Web developers (como Ruby) salvo por los que ya desarrollan en Force.com.

Conclusión: la arquitectura Ruby on Rails + Database.com + Heroku me parece la ideal para aplicaciones de negocio para la Nube. Su principal desventaja (creo que temporal) es que actualmente la integración RoR-Database.com no es factible con la versión 3 de Rails sino únicamente con una anterior. Ello debido a que el adaptador de la base de datos (ActiveSalesforce) no es compatible con Rails 3. Sin embargo esto deja de tener relevancia ahora que Force.com está apostando también por las APIs basadas en REST por lo que seguramente pronto veremos un adaptador REST (a febrero del 2011, existe incluso ya una versión alfa) en lugar del actual basado en SOAP.

(Nota relevante agregada el 22-mar-2011: Rails 3 & Force.com REST API)

Quizá en otro post comentaré de alternativas también sólidas como arquitectura de base para aplicaciones Nube. Sin embargo, la aquí expuesta es la que yo elegiría en definitiva.

, , , , , , ,

2 comentarios

Algunas razones de porqué elegiría Rails + Database.com + Heroku para una solución de Nube … Parte 1

Hace más o menos un par de meses (finales de diciembre del 2010) me vi inmerso por esos azares del destino en buscar cuál sería la plataforma idónea para desarrollar “from scratch” soluciones de negocio y procesos organizacionales bajo el concepto de computación en la Nube (Cloud Computing). Software-as-a-Service (SaaS) en su definición más pura. Lo más interesante del caso es que yo no tenía ninguna restricción; o sea, no tenía ninguna inversión tecnológica heredada que tuviese que “respetar” o con la que tuviese que interactuar; es decir, ¡el mundo ideal del Arquitecto de Software!

So.. me di a la tarea de investigar un poco el asunto y leer algo de material al respecto. Tenía que considerar muchos factores, no sólo técnicos sino también como estrategia de negocios e inversión futura. Simple y llanamente debía elegir en qué desarrollar un producto que mi empresa pudiese invertir y rentabilizar en el futuro. En este post explico la primera parte de las razones por las que elegí cierta tecnología. En la segunda parte continuaré comentando el razonamiento de mi decisión.

Mi elección:

He aquí algunas de las razones por las que seleccioné la tecnología descrita:

  1. Ruby es un lenguaje de programación orientado a objetos creado en Japón por Yukihiro Matsumoto, “Matz”, a principios de los años 90s; lo suficientemente maduro para demostrar que no es flor de un día pero lo suficientemente “moderno” y poderoso como lenguaje de programación. Es elegante, sencillo de aprender, tiene una comunidad de desarrolladores vibrante y ha sido definido por Marc Benioff, director de Salesforce, como el lenguaje de la Nube. Además, existen implementaciones Java (JRuby) para los developers que aún se sienten cómodos con Java pero quieren acceder a la elegancia de Ruby. Y finalmente, Ruby es también Open Source.
  2. Ruby on Rails (RoR). Es el framework de desarrollo Web que mayormente usa el lenguaje Ruby (aunque existen otros; Sinatra en particular) y es ampliamente conocido y aceptado por la comunidad Ruby. Rails es uno de los primeros frameworks de desarrollo en utilizar el patrón MVC (Model-View-Controller) que prácticamente se ha convertido en un estándar del desarrollo de aplicaciones para la Web. Sólido y maduro.
  3. Base de Datos: En este tema hay mucho por escoger. MySQL es muy bueno, es Open Source y es ampliamente aceptado por la comunidad de Web Developers. Por otro lado, Apache tiene una muy interesante iniciativa de base de datos (document-oriented) llamada CouchDB que también tiene ya proveedores en la Nube: Cloudant.com. Si consideramos que “la Nube” será nuestro pan de cada día, debemos privilegiar la decisión de una base de datos “de Nube”. Es por ello que la versión “Nube” basada en MySQL llamada Xeround sería nuestra primera opción; máxime que Xeround ya tiene un add-on para funcionar en la plataforma de Heroku.

Sin embargo, aquí es donde entra nuestra primera gran consideración en favor del mundo Salesforce, más específicamente, del mundo Force.com que es la plataforma de desarrollo de aplicaciones para la Nube de Salesforce. En la segunda parte de este post abordaré porqué me pareció importante integrarse con Force.com, vía su producto de base de datos Database.com y también terminaremos de justificar nuestra decisión completando el cuadro con la plataforma de desarrollo de Heroku.com.

¡Back soon!

, , , , , , , ,

1 comentario