Entradas etiquetadas como Salesforce

¿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

¿Computación “en la Nube”? – Parte 1: Una opinión desde el punto de vista técnico

A veces me pregunto si toda este buzzword con respecto a la Computación en la Nube (Cloud Computing) no es más que un concepto tecnológico algo difuso pero, al fin y al cabo, un “refrito” (como sucede en muchas ocasiones) de conceptos antiguos del mundo de la Tecnología de la Información (TI). Pero mientras más lo pienso, veo que no; que esto es algo realmente nuevo; sobre todo desde el punto de vista tecnológico (y esto es lo esencial de este post) aunque desde el punto de vista negocios sí pueda parecerse a otras ideas ya exploradas (sobre esto me explicaré en la Parte 2 de este post donde abordaré el punto de vista empresarial del concepto).

Desde un punto de vista técnico simplista, el concepto de Computación en la Nube podría erróneamente resumirse como todo aquel sistema que funciona enteramente en Internet vía la Web y que se accede mediante un Navegador (browser) o algún otro dispositivo, incluyendo los móviles. Pero no; visto desde ese punto de vista el concepto no sería ni nuevo ni innovador pues existen sistemas que funcionan de esa manera casi desde el inicio de la popularización de las páginas Web por allá en el segundo lustro de la década de los 90s.

Además, si yo hospedo en un servidor de Internet un sistema o sitio Web que luego vendo o alquilo por una cuota, esto también sería considerado Computación en la Nube y eso existe ya desde hace varios años. Inclusive compañías grandes tienen sistemas que les pueden vender a sus clientes y que son instalados en servidores de Internet listos para ser usados vía Web.

Aunque la computación en la Nube incluye todo lo anterior, técnicamente hablando, eso aún NO es computación en la Nube, ya que estamos hablando de una instancia de la aplicación pero atendiendo a un solo cliente (uni-tenant). Si el proveedor de la solución cambia el software o actualiza la versión de software por una versión mejor y, suponiendo que quiere darle ese beneficio a todos los clientes que han comprado dicha aplicación, tendría que ir instalación por instalación a actualizar el software (o pedirle a cada cliente que ellos mismos hagan la actualización).

Entonces la palabra clave es Multi-tenancy. Esto quiere decir que el software funcionará con una sola instancia de la aplicación para muchos clientes. Todos a la vez. Multi-tenancy: Una instancia de la aplicación, quizá sólo una Base de Datos (elástica y escalable, pero una sola) atendiendo a muchos clientes a la vez. He ahí lo nuevo del Cloud Computing. Este es lo esencial; lo core del concepto: Arquitectura Multi-tenancy.

Ante un escenario así, ¿qué sucedería si el proveedor del software cambia de versión a una mejorada? Teóricamente, cambiaría únicamente la versión de producción de dicho software y ¡voilá!, todos los clientes que acceden a la aplicación tendrían la nueva versión sin tener que actualizarla o que el proveedor tenga que actualizar cliente por cliente. Por ejemplo, si Google cambia Gmail, automáticamente todos los clientes (usuarios) de Gmail obtienen las mejoras que Google le hace a dicho producto. Este mismo escenario es posible con aplicaciones empresariales (tanto de misión crítica como otras) o utilitarias, no sólo con correo electrónico.

El caso más conocido en el mundo es quizá Salesforce que es un CRM que nació y creció con el concepto de Cloud Computing. Así, las empresas que usan dicho CRM obtendrán las últimas versiones del software ya que están en un ambiente Multi-tenancy. Lógicamente, detrás de todo ello, existen complejas arquitecturas (que espero podamos ir comentando en este blog) y plataformas que deben (y de hecho, lo hacen) asegurar la escalabilidad, elasticidad de la aplicación, desempeño, seguridad, estabilidad, entre otros conceptos. Pero lo logran y he ahí lo novedoso del caso.

Así que, a seguir explorando el mundo del Cloud Computing.

, , , ,

1 comentario