Entradas etiquetadas como SaaS

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

¿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

[Video] Multitenancy con Ruby on Rails

Una de las características esenciales de las aplicaciones para la Nube es su arquitectura de Multitenancy. La arquitectura multitenancy implica una sola instancia de la aplicación y una sola base de datos para múltiples empresas clientes quienes usan la aplicación de negocios de acuerdo a sus necesidades. Para cada empresa cliente es como si la aplicación fuera únicamente para ellos. El concepto de Multitenancy es fácil de entender cuando lo comparamos con lo que no es Multitenancy. Veamos:

1. Una aplicación que desarrollamos y que aunque está lista para funcionar en Web e Internet (o en Intranet), tenemos que instalarla nuevamente cada vez que alguna empresa la requiere. Así, si hacemos 10 instalaciones (aunque sea en el mismo servidor Web físicamente; o sea, en la misma infraestructura) tenemos 10 Bases de Datos y 10 instancias de la aplicación. Si el sistema tenemos que corregirlo o hacer algún upgrade tendríamos que hacerlo 10 veces. So, esa aplicación aunque funciona en Web e Internet NO es Multitenant. Sí; es una aplicación Web pero No es una aplicación de Nube. De hecho este es el típico modelo anterior que se usaba en los servicios de los Application Service Providers (ASP).

2. Una aplicación masiva (muchos usuarios) tales como Facebook o Twitter no se considera Multitenant porque su modelo de separación de datos está basado en el Rol de Acceso de los usuarios que Inician Sesión. Es decir, todos los usuarios ven lo mismo (o casi) basándose en los permisos que le otorga el sistema. Aunque es una base de datos, los usuarios no entran a un espacio donde sus datos están separados de los demás.

3. Siendo así, la característica fundamental de una aplicación Multitenant es que tengamos una sola base de datos para las 10 ó 100 ó las que sean empresas clientes de nuestra aplicación. Un ERP Multitenant (o sea, de Nube) tendrá una única base de datos y una sola instancia de la aplicación. Si debemos corregir un error o hacer un upgrade bastará con que lo hagamos una sola vez y todos las empresas clientes del ERP recibirían el beneficio de manera inmediata. Buenos ejemplos: Salesforce, Zoho, Paymo, entre muchos.

Con esto en mente, vean este excelente video donde Guy Naor, CTO de MorphLabs, explica cómo diseñar una aplicación Ruby on Rails con Arquitectura Multitenancy y, por ende, una aplicación 100% de Nube. Si eres un Rails Developer o Rails Architect y estás por empezar una aplicación Nube Multitenant, entonces este video es imperdible..!

Vodpod videos no longer available.

Fuente: Confreaks 2009

, , , , , ,

Deja un comentario

La seguridad en la Computación en la Nube

He oído que uno de los tópicos más recurrentes cuando se habla sobre el “Cloud Computing” es el tema de la seguridad. Se dice que las aplicaciones en la Nube son más riesgosas y susceptibles de ataques informáticos de diversos tipos. Además se tiene la impresión de que al estar hospedadas en servidores externos a la empresa, los datos corren más riesgos de ser perdidos o robados; y que, por ende, una Nube privada es más recomendable que las aplicaciones en la Nube Pública. Todo esto me recuerda los albores de Internet cuando se decía que pagar con tarjeta de crédito en Internet era un riesgo mayúsculo y sin embargo el porcentaje de robos o fraudes de información al pagar en línea con tarjeta, en el peor de los casos, no son mayores que los realizados fuera de línea.

No me malinterpreten. No digo que no debamos tener cuidado. Debemos tener mucho cuidado de dónde comprar en Internet de la misma manera que una empresa debe tener cuidado de qué proveedores de aplicaciones Software-as-a-Service contrata. Pero una vez salvado este punto yo me atrevo a decir que los riesgos son menores a los riesgos que tradicionalmente se tienen con las aplicaciones instaladas “in-house” de la misma manera que nuestra tarjeta no corre más riesgos al pagar en línea de los que tomamos al pagar con ella en un restaurant.

Yo creo que el problema es de percepción. Se tiene la percepción de que al no tener el control de la infraestructura de nuestra aplicación (Hardware y Software), esta corre más riesgos. Nos sentimos más seguros de poder “ver y tocar” los equipos o las aplicaciones en cualquier momento. Es decir, caminar hacia el cuarto de hardware y entonces ver que están ahí y revisar en el equipo mismo que los procesos de las aplicaciones están ejecutándose adecuadamente; como si el hecho de poder ver los equipos pudiera, por arte de magia, crear mecanismos más seguros en nuestra infraestructura. En síntesis, queremos tener el control total de ello.

Pienso que este es un punto de vista un poco inocente. En realidad, con los servicios en la Nube de hoy día (de Infraestructura -IaaS- , Plataformas -PaaS- y Aplicaciones -SaaS- ) es difícil que nuestro departamento de TI llegue a tener el grado de especialización y la tecnología de avanzada (state-of-the-art) que estos servicios tienen (salvo quizá para algunas grandes empresas que sí cuentan con recursos para lograrlo). Me refiero, por ejemplo, a servicios de respaldo de datos, seguridad de los equipos, confidencialidad, datacenters, personal especializado, y hoy día hasta seguridad de las redes con tecnologías como la de VPN. Los Service Level Agreement (SLA), ó Acuerdos de Nivel de Servicios, son muy ventajosos para las empresas clientes; se ofrece mantener sus activos funcionando 365x24x7, nivel de servicio que sería difícil igualar por un departamento interno.

Realmente el tema de la seguridad se relaciona más con el diseño de toda la Arquitectura de nuestras soluciones informáticas y todos los elementos relacionadas (redes, equipos, aplicaciones de negocio, middleware, etc.). La seguridad no mejora si usamos una Nube privada por sobre la Nube pública sino que la seguridad únicamente mejora si nuestra arquitectura (ya sea pública o privada) está mejor diseñada e implementada. Y me atrevo a decir que en una gran mayoría de casos, la nube pública será más segura que la privada para desplegar soluciones de Cloud Computing.

Lo anterior se vuelve aún más crítico cuando aunamos dos elementos más: el hecho de que normalmente será mucho más barato el contratar servicios bajo demanda en la Nube pública (infraestructura, plataformas de desarrollo, aplicaciones de negocio, etc.) que comprar equipos o licencias de software, y además asignar a nuestro personal (o subcontratar) para desarrollar y mantener nuestra propia nube privada. Es decir, el factor económico es un factor adicional a favor de la Nube pública. Y finalmente, la Nube pública nos pone en contacto directo para poder aprovechar un enorme gama de recursos (servicios, software, herramientas, APIs, etc.) que son accedidos únicamente desde una plataforma de Nube pública. Hoy día prácticamente todo se accesa vía REST APIs y las aplicaciones de negocios interactúan “fácilmente” unas con otras en la Nube.

En fin, yo recomiendo olvidarnos un poco de nuestros prejuicios de no tener el control, y de querer “ver y sentir” en nuestra propias instalaciones a nuestros activos de TI, para, en cambio, iniciar un proceso de experimentación y exploración de los servicios de la Nube pública y aplicaciones Software-as-a-Service (SaaS) en ella. De hecho, un buen servicio de Nube pública en ocasiones provee mecanismos de control y monitoreo mucho más sofisticados de los que internamente podríamos mantener. Pienso que el tiempo, como en el caso de los pagos con tarjeta, acabará por darnos la razón.

, , , , , ,

Deja un comentario

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