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

Más de monetización para dispositivos móviles

Long TailEn post anterior describía de manera general algunas alternativas para monetizar (o generar ingresos) de aplicaciones para dispositivos móviles (smartphones y tabletas). Si no lo han leído los invito a hacerlo ahora antes de leer el presente post. En este, me enfocaré principalmente en el modelo de ingresos de vender la aplicación por un precio muy bajo, típicamente entre 1 y 5 dólares, aunque esto puede variar alrededor de esas cifras. Por cierto, una aclaración muy importante es que este post se refiere a aplicaciones móviles que son descargadas desde un servidor Web e instaladas en los móviles. No se refiere a aplicaciones de Nube que son accedidas desde dispositivos móviles. Ambas realidades son bien distintas como mencionaba aquí: Aplicaciones para móviles.

Anteriormente cuando uno quería comprar un software, uno acudía al proveedor y compraba una licencia de dicho software. Dependiendo de la naturaleza y complejidad de la aplicación, el software podía costar desde una cantidad relativamente pequeña (50 dólares, por ejemplo, los antivirus) hasta cientos de miles de dólares tales como las licencias de los programas de ERP (Enterprise Resource Planning) corporativos. En el caso de latinoamérica una empresa podría invertir en el desarrollo de un software y con un poco de suerte lograr colocarlo en el mercado por precios mínimos de unos 500 dólares (como algunos paquetes contables básicos).

Sin embargo, este modelo sería completamente inadecuado para el mercado de aplicaciones para smartphones (iPhone, Android) y tabletas (iPad, Motorola Xoom, Samsung Galaxy) ya que a esos precios las aplicaciones difícilmente serían vendidas. Pero, los costos de desarrollo de software son bastante equivalentes al desarrollo de software para Desktop. Es decir, también para desarrollar software para móviles las empresas requerimos uno o más desarrolladores Web, e idealmente diseñadores, analistas, mercadólogos, etc. Toda una infraestructura de desarrollo y venta de las aplicaciones. ¿Cómo podemos cubrir esos costos si el mercado no paga en licencias de software lo mismo que para aplicaciones Desktop o empresariales?

La respuesta es la Long Tail. Esta “teoría” nos sugiere que el número total de las ventas de una industria está dividida en dos: los artículos populares que todo distribuidor quiere vender porque alcanzan una gran masa de población en poco tiempo, y aquellos artículos muy raros que gustan a pocas personas (o requieren pocas empresas) y que, por tanto, casi ningún distribuidor quiere vender. Sin querer detallar mucho el concepto de Long Tail (les sugiero leer el fascinante artículo de Chris Anderson que popularizó el concepto), esta teoría indica que, sorprendentemente, el volumen más grande de ventas está en los artículos raros pero clásicos o de gustos particulares (p.ej, “Rapsodia Bohemia” de Queen versus la última canción de Shakira) dado que se sostienen por mayor tiempo.

Para querer acceder a dichos mercados, sin embargo, es necesario que la distribución de este tipo de artículos o productos tenga dos características: se sostenga disponible a la venta durante mucho tiempo pero sin elevar los costos de distribución iniciales; y que sea altamente disponible (“encontrable”). Y es entonces cuando observamos que los productos digitales son ideales para aprovechar el Long Tail ya que los costos de distribución durante el tiempo son realmente mínimos. Únicamente se coloca el archivo digital (de música, de software, libros digitales, etc.) en un servidor de Internet y listo. A esperar las descargas de los clientes.

La disponibilidad debe hacerse vía un sitio Web que sea fácilmente encontrable por los usuarios en todo el mundo. Mientras más específico (o especial o raro) sea nuestro producto digital (por ejemplo la canción de Rapsodia Bohemia de Queen en el último cocierto de Freddie Mercury) más fácil será que el usuario llegue a nuestro sitio Web a descargarlo.

Todo lo anterior nos lleva al mercado de las aplicaciones para dispositivos móviles. Si queremos tener éxito con la comercialización de una aplicación en particular, además de la calidad y de la suerte (que también es un factor esencial en el éxito que podamos tener), debemos tener en cuenta que nuestra aplicación sea:

1) Altamente disponible. Muy bien descrita y ubicable en el App Store, Android Market, Blackberry App store, Nokia Ovi store, etc. donde quiera que hayamos decidido distribuirla (incluyendo, cuando sea posible, en un servidor Web propio; en este caso usando técnicas de SEO -Search Engine Optimization- para que sea fácilmente encontrable por los buscadores)

2) En extensión al punto anterior, la aplicación debería ser descargable a nivel mundial. Es decir, altamente disponible a nivel global para acceder a un mercado muy grande

3) Muy barata. El precio no debería disuadir a ningún fanático de la aplicación para comprarla, a veces hasta por impulso dado que la inversión le debe representar casi cero

4) Que resuelva una necesidad muy específica. Mientras más específica (particular o rara), mejor pues será difícil encontrar aplicaciones competidoras.

Ante un escenario así, resulta mucho más atractivo el mercado de desarrollo de software para dispositivos móviles y mucho más atractivo invertir en desarrollarlas. Gracias al concepto de Long Tail, las apps para móviles pueden tener un nicho de mercado muy bueno y resultar ser rentables aún a precios excesivamente bajos.

, , , , , ,

1 comentario

Las redes sociales – ¿Mercadeo o TI?

Social Networks

Últimamente he oído mucho sobre el debate existente sobre si las Redes Sociales, particularmente el caso de Facebook y Twitter, es un área que debe conocer, usar, aprovechar y especializarse desde el área de Marketing de una empresa o desde el área de Tecnología de Información (TI). Dicho de otro modo, la estrategia de Redes Sociales ¿debe ser guiada por Mercadeo o por TI? El debate es muy similar al que había hace unos años sobre los proyectos de Comercio Electrónico (debate en el que personalmente tengo la misma opinión que la que aquí escribo: el E-commerce es un tema de negocios).

Haciendo un breve descargo de responsabilidad, debo confesarles que están leyendo una opinión de un profesional de las ciencias computacionales y un apasionado de la tecnología de la información, incluyendo todo el movimiento de las aplicaciones sociales. En síntesis, me considero un especialista en tecnología Web e ingeniería de software y, aunque también tengo formación y experiencia en Negocios, no soy un mercadólogo. Mencionado esto, les comento mi percepción sobre este tema.

A mi me parece que TI debe estar al servicio de Marketing. Es decir, la estrategia de redes sociales, lo que se pretende con ella, los resultados, las mediciones, el propósito de las redes sociales, etc. debería ser guiada por el área de Mercadeo (quizá incluso por la misma dirección general). La estrategia de redes sociales es, en esencia, un subconjunto de las estrategias de mercadeo y comunicación de una empresa y, por tanto, debe estar alineada con ellas. Y este es un trabajo del Director de Mercadeo y/o Comunicación.

Sin embargo, para que una estrategia de redes sociales sea efectiva y aún bajo la suposición de que será dirigida por Mercadeo, es condición necesaria que el área de TI apoye 100% dichas estrategias, Entre otras cosas, veo necesario:

  • Que TI le presente (periódica pero permanentemente) a Marketing toda la gama de posibilidades y herramientas tecnológicas que las redes sociales tienen. Y este no es un trabajo menor porque las redes sociales (Facebook y Twitter particularmente) y todas las herramientas de terceros basadas en ellas, cambian vertiginosamente y es trabajo de TI conocer las especificidades técnicas para poder usar adecuadamente las redes sociales.
  • Que TI aconseje a Marketing (no que decida) qué cosas puede aprovechar. E inclusive, idealmente, debe mostrarle (con pruebas o demos sencillos) estas posibilidades porque no siempre las palabras o presentaciones Powerpoint son suficientes para dar a conocer cierto concepto tecnológico.
  • Importantísimo es que el área de TI o las personas de TI que se involucrarán en proyectos de redes sociales, hables el lenguaje de Mercadeo. Aunque no sean especialistas sí que entiendan el lenguaje de negocios de la empresa.
  • Que Marketing visualice nuevas posibilidades “escuchando” a su asesor de TI. Es decir, que esté abierto a la utilización de nuevas tecnologías pero enmarcándolas y aprovechándolas en el contexto estratégico de mercadeo de la empresa. No como iniciativas aisladas. Y que, en este sentido apruebe, o rechace, herramientas específicas de las redes sociales.
  • Que una vez que la empresa decida embarcarse en proyectos de redes sociales, marketing y TI trabajen muy cercanamente, muy frecuentemente, y de manera colaborativa.

Creo que de esa manera, las posibilidades de que los proyectos fracasen por falta de entendimiento de las tecnologías o por falta de alineamiento estratégico con la empresa se reducen significativamente.

¿Y qué con el caso de LinkedIn? Bueno, el tema me parece muy similar pero siendo dirigido esta vez por el área de Gestión del Talento de la empresa. O dicho de otro modo, siempre ¡la TI al servicio de los negocios y organizaciones!

, , , , , , ,

Deja un comentario

Desarrollo Ágil y sus posibilidades con Rails

Proceso SCRUM

Fuente: Scrum Alliance

El desarrollo de software para la Web ha venido a apuntalar y terminar por validar diversas metodologías de Ingeniería de Software conocidas como Metodologías de Desarrollo Ágiles. Aunque existan muchas, y con variantes entre sí, de las más conocidas está SCRUM, XP (Extreme Programming) y la de Desarrollo de software Lean (o delgado). Aunque existen muchas, todas ellas están basadas en el Manifiesto de Desarrollo Ágil:

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

En general, podemos decir que se intenta provilegiar la construcción iterativa e incremental de los productos de software, tomando mucho en consideración, en cada ciclo, el punto de vista de los usuarios o clientes. Todo esto se basa en la idea, que considero completamente correcta, de que el usuario o el cliente termina por definir los requerimientos del software únicamente después de que ve y “siente y prueba” el software que se está creando, y no antes.

Aunque el cliente previamente puede tener una idea, ya sea extremadamente vaga o bien imaginada, de lo que requiere en su software, es en el momento que ve en la pantalla de la computadora cuando el cliente realmente termina de definir bien lo que requiere. E inclusive podría requerir varios ciclos de mejora antes de que su necesidad haga “click” en su cabeza. Dicho de otro modo, se trata de ir construyendo y clarificando los requerimientos del software durante (y no antes) la construcción del mismo.

Hoy día se intenta ir incluso más allá con técnicas muy innovadoras como el Test Driven Development (TDD – Desarrollo dirigido por las Pruebas) ó el Behaviour Driven Development (BDD – Desarrollo dirigido por el comportamiento del software). A continuación, una brevísima explicación de ambas.

El TDD se basa en el concepto de que el desarrollador debe codificar primero la prueba o pruebas de algún requerimiento específico. Una vez codificada la prueba asegurarse de que la prueba en realidad es fallida y posteriormente realizar la programación para que la prueba pase. Ya que logró pasar la prueba entonces realizar un proceso de afinado del código para “limpiarlo”, optimizarlo y documentarlo. También en muchas ocasiones el developer o equipo de developers debe estar consciente de que antes de codificar la primera prueba de este ciclo primero debe decidir si el sistema tal como está en ese momento es el idóneo para codificar la prueba o si debe restructurarlo para que sea más adecuado para satisfacer el requerimiento que se va a probar/codificar. Algo así:

Técnica TDD = Refactoring (opcional) + Codificación de la primera prueba del requerimiento

Pero lo esencial del TDD es “First code the Test, then code to pass the test” ó “Primero codifica la prueba, luego codifica para pasar la prueba”.

El método BDD incluye TDD pero lo extiende de manera que las pruebas no sólo sean creadas por el Developer sino también por éste y el cliente o usuario final, utilizando para definir el requerimiento (cierto comportamiento específico del software) un lenguaje casi natural. Dicho de otro modo, el cliente en conjunto con el Developer definen (en un lenguaje específico legible para usuarios no técnicos) el comportamiento y tomando este como insumo el developer codifica la prueba y sigue el método TDD. Excelente, ¿eh?

¿Qué tiene que ver todo esto con la computación en la Nube? Bueno pues que el Software-as-a-Service tiene hoy día una matrimonio con las nuevas metodologías Ágiles de desarrollo, y con técnicas como BDD/TDD. La Web, o al menos la buena Web, se está construyendo alrededor de esta Ingeniería de Software. Un proyecto de construcción de un producto para la Nube debe tomar en consideración estos métodos más que los tradicionales métodos de Project Management.

En el caso de Ruby on Rails, el framework no sólo ya cuenta con mecanismos incluidos dentro de la plataforma (por ejemplo, un subsistema de pruebas) que apalancan métodos ágiles y TDD sino que también se han construido herramientas excelentes y que están ganando momentum en el mercado, tales como Cucumber, herramienta programada en Ruby, que automatiza de manera elegante y sencilla el método BDD para proyectos no sólo de Ruby on Rails sino también Java, Python y C#.

¡Bien por Rails y las metodologías ágiles! Si bien es cierto que esto no es exclusivo de Rails, sí es una razón más para seleccionar Rails como framework de desarrollo para la Nube.

, , , , , , , ,

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