PAAS, IAAS y SAAS

Cuando iniciamos nuestro andar por el mundo de la computación en la nube, empezamos a escuchar muchos términos que no conocemos e incluso que pueden llegar a ser confusos cuando intentamos “descifrar” que se quiere decir cuando se utilizan. Quizás entre los primeros términos que vamos a escuchar están PAAS, IAAS y SAAS; en este post vamos a aclarar estas definiciones para poder iniciar más cómodamente nuestro “viaje” a través del “Cloud Computing”.

PAAS

Es un “paquete” tecnológico en donde rentamos no solo aplicaciones, si no también el hardware, el almacenamiento y el sistema operativo a un proveedor en Internet; en otras palabras es comprar una plataforma pero consumirla como un servicio. En realidad, lo que vamos a rentar en PAAS son servidores virtuales con una serie de servicios previamente habilitados por el proveedor del servicio. Normalmente el proveedor del servicio se encarga de las actualizaciones del sistema operativo y de los componentes o servicios ofrecidos en el paquete. Igualmente se hace cargo de los fallos de las máquinas virtuales creando nuevas instancias en otros servidores físicos. PAAS es una “evolución” del SAAS en donde rentábamos una aplicación por usuario o por uso y se nos abstrae toda la plataforma necesaria para que esa aplicación funcione correctamente. En resumen podemos decir que PAAS es una plataforma en donde se puede desarrollar, probar e instalar software; es decir, el ciclo completo del ciclo de vida del desarrollo del software puede ser operado en PAAS.

En este apartado sin duda alguna la oferta más conocida es la de Windows Azure; sin embargo, podemos encontrar varias opciones más en el mercado tales como beanstack para desarrolladores java, o PHP Fog para desarrolladores PHP. En esta categoría me llamo mucho la atención una nube que se esta volviendo muy popular llamada AppHarbor la cual es una opción independiente para desarrollo en .NET.

Desventajas

Quizás el problema más evidente del PAAS es el llamado “lock-in” en que las empresas pueden caer. Esto se da principalmente porque dependiendo de las oportunidades de desarrollo que nos ofrece el proveedor, podríamos quedar sin posibilidad de llevarnos la aplicación a otra plataforma.

IAAS

Este modelo de negocios nos permite rentar todo el equipamiento necesario para soportar las operaciones de la organización, incluido el almacenamiento, el hardware, servidores, redes, UPS, etc. El proveedor es dueño del equipo y es responsable por darle mantenimiento, espacio en la empresa y mantenerlo funcionando. En otras palabras estamos alquilando ese cuarto de servidores que vemos en nuestras empresas todos los días que por lo general no esta utilizado al 100%. Muchos de los servidores que vemos en esos cuartos están “idle” esperando los picos de consumo de la empresa.

La definición típica de IAAS es “El datacenter como un servicio, pagando por consumo”. Normalmente IAAS es algo así como máquinas virtuales “on demand” en donde se paga por horas por el tiempo que estas pasen en ejecución. Es importante notar que normalmente se tiene acceso como administrador a estas máquinas virtuales. El ejemplo más notable en este campo es Amazon con su AWS – Amazon Web Services.

SAAS

En este escenario es donde el consumidor se olvida de cualquier preocupación relacionada con el servicio completo.El proveedor tiene un control muy amplio en la parte administrativa de la aplicación y es responsable de actualizar, instalar, mantener y darle seguridad a la aplicación(es) que brindan el servicio adquirido o rentado. En este escenario el usuario final tiene muy poco control sobre la parte administrativa del servicio contratado. Algunos ejemplos de este modelo son GMail o Hotmail, ya que en ambos casos se pueden llevar a cabo un limitado número de acciones tales como enviar correo, leer un correo, etc. Ejemplos de SAAS en el mercado en este momento son “Google Apps For Business” y Office365. Igualmente muchos de los CRMs en línea pertenecen a esta categoría de Cloud Computing; por ejemplo, Microsoft Dynamics y SalesForce.

Estableciendo las diferencias

Para entender bien la diferencia entre estos modelos de servicio, vamos a hacer una tabla en donde vamos a mostrar cuál es la principal característica de cada uno de los modelos, con esto podemos luego establecer en donde tiene más control el usuario y donde tiene más control el proveedor del servicio.

Modelo	Componentes
SAAS	Aplicaciones ( SalesForce, Dynamics, SAP)
PAAS	Middleware ( BD, ESB, Application Server, Cache Managment )
IAAS	Virtualización, OS, Hardaware

En el esquema de SAAS el control del proveedor y del cliente se ve a continuación:

En el esquema de PAAS el control del proveedor y del cliente se ve de la siguiente forma:

En el esquema resumido de IAAS se puede ver en la siguiente figura.

Etiquetas de Technorati: Cloud Computing,PAAS,IAAS,SAAS

La convergencia entre SOA y el Cloud Computing

Mucho se habla en estos días de SOA y Cloud Computing en nuestras empresas. Todo esto porque las empresas que nos proveen las herramientas y las plataformas para implementar este tipo de arquitecturas nos dan una serie de opciones y lineamientos para tomar en cuenta cada uno de estos “estilos” de desarrollo en nuestras empresas – y en algunos casos parece que tiene que ser cuanto antes.

Sin embargo, estos dos temas se abarcan como opuestos verdaderos donde ninguno de los dos tiene nada que ver o en donde no son necesarios para el buen desarrollo de los proyectos que tenemos a futuro. Desde mi punto de vista este es un enfoque erróneo ya que SOA y el “Cloud Computing” son complementarios y uno no debe sustituir al otro. En este post voy a explicar porque creo que si se usan ambas plataformas de forma complementaria, se van a obtener mejores resultados.

Cloud Computing y la Arquitectura Punto a Punto

Un tema crítico a la hora de llegar a la nube es la forma en que vamos a integrar nuestras aplicaciones locales –> “On Premises” –> con nuestras aplicaciones en la nube. En circunstancias normales, si no tenemos una arquitectura de integración bien definida vamos a tener una arquitectura punto a punto tal y como se ve en la siguiente figura.

Si queremos agregar aplicaciones que funcionan en la nube y las tenemos que integrar con aplicaciones locales, vamos a tener un escenario un poco más complicado ya que las aplicaciones en la nube siguen siendo un punto más en la gráfica de integración.

Evidentemente esto traer muchas complicaciones de mantenimiento y de evolución de los productos ya que el gráfico de integración tiende a complicarse muchísimo conforme vamos agregando aplicaciones, todo esto tomando en cuenta que no estamos agregando el factor de los protocolos de comunicación en los gráficos anteriores porque esto aumentaría la complejidad.

SOA: La Solución

La pregunta que surge es como solucionamos la problemática anterior, y ahí es donde SOA entra en el juego. En realidad existen dos posibles soluciones a este problema

1. Tener todas mis aplicaciones en la nube y utilizar el Bus que mi nube debería ofrecer.

2. Utilizar SOA para integrar mis aplicaciones “On premises” con mis aplicaciones en la nube.

La primera opción es poco realista en un escenario donde la empresa ya tiene una inversión en software que corre localmente y además es difícil encontrar por el momentoempresas que tenga toda su infraestructura en la nube.

La segunda opción es muy viable y es la que vamos a tratar. Si tenemos una arquitectura orientada a servicios, tendremos un BUS de datos que nos va a permitir interconectar aplicaciones desarrolladas en diversas plataformas y que utilizan diferentes protocolos y formatos de comunicación. Si ya tenemos una arquitectura SOA y queremos subir o crear una nueva aplicación en la nube, el escenario de interconexión de nuestras arquitecturas varía radicalmente respecto a la versión anterior punto a punto. Este escenario se puede ver en la siguiente figura.

Como podemos ver en el grafico anterior, cuando se utiliza un ESB la nube simplemente se convierte en un punto de acceso más, con lo cuál podemos garantizar que la integración será transparente y que además podremos interactuar de forma ordenada con aplicaciones hechas en diversas tecnologías y que incluso utilizan protocolos de integración que no son compatibles con lo que normalmente se utiliza para trabajar en la nube – HTTP[s]. Igualmente, cuando agregamos una nueva aplicación a nuestro ecosistema, será muy sencillo integrarla con las aplicaciones que tenemos localmente como con las que están trabajando en la nube.

Etiquetas de Technorati: SOA,Cloud Computing

¿Se requiere una estrategia para ir a la Nube?

 

Esta es quizás una de las preguntas MÁS IGNORADAS por las empresas cuando están en el proceso de decidir si quieren poner parte de sus aplicaciones en la nube o no – o todas. En este post vamos a tratar el porque es importante definir como vamos a movernos a la nube, que aplicaciones vamos a llevar a la nube y que problemas voy a encontrar si voy a la nube sin ninguna estrategia.

Ahora si, voy para la nube

En la mayoría de los casos, la decisión de moverse a la nube parece ser una decisión bien pensada; sin embargo, cuando uno investiga más a fondo se da cuenta de que es una decisión bien pensada desde el punto de vista administrativo y no desde el punto de vista técnico. Esto principalmente porque el ahorro en costos se puede ver sin mucho esfuerzo, y por supuesto la empresas siempre buscan donde ahorrar recursos; sin embargo, a nivel técnico parece ser que es una decisión más bien obligada, en donde queda poco margen de maniobra ya que es difícil justificar el esfuerzo y las ventajas – desventajas de moverse a este modelo.

Normalmente el técnico recibe una charla rápida, analiza el ambiente de desarrollo – que si es con Azure es bastante transparente ya que se desarrolla en Visual Studio – y ya se siente listo para decir, “si, vamos para la nube”. En realidad cuando se enfoca el problema desde el punto de vista “vamos a poner una aplicación” no se ve ningún inconveniente en dar el paso; sin embargo, cuando esta aplicación tenga que integrarse con otras aplicaciones que corren en la empresa –> On Premises <— entonces es cuando se empieza a ver los problemas de mantenimiento e integración.

En la nube no hay problemas – ¿En serio?

Otro mito relacionado con pasarse a la nube, se da cuando las empresas que nos ofrecen la plataforma nos venden la idea de que al estar en la nube nuestros sistemas serán más estables, ya que ellos son responsables del manejo de esta plataforma y además, si ocurre un problema en la máquina( s ) que “hostean” la aplicación el sistema automáticamente mueve la aplicación hacia otra instancia – máquina virtual – en donde se ejecutará de nuevo sin problemas. Sin embargo, aunque es seguro que el ambiente en la nube de la plataforma que seleccionemos va a estar optimizado, no podemos esperar que los errores de nuestras aplicaciones se borren “mágicamente” solamente por el hecho de que ahora corren en la nube; de hecho, si nuestra aplicación tiene problemas ejecutándose “on premises” tendrá los mismos problemas ejecutándose en la nube con el agravante de que ahora no se puede entrar al servidor a realizar todo tipo de acciones que le permitan al responsable de la misma hacerla funcionar.

Igualmente al estar nuestra aplicación corriendo en la nube, tenemos que tener claro que que nuestras aplicaciones van a depender de la conectividad y su latencia – el tema de como trabajar offline con la nube lo trataremos en otro post – y esto va a conllevar a que la comunicación no sea tan rápida como la comunicación que se hace entre aplicaciones que están dentro de un datacenter local – o aún en el mismo país – este tema es muy relevante por eso estaremos tratando el tema de la localización geográfica a la hora de crear instancias en la nube en post posteriores.

¿Entonces como paso a la nube?

Como en todo paso tan relevante, se debe establecer un orden de migración, tomando en cuenta las necesidades actuales de la aplicación y el impacto que va a tener esta migración en las aplicaciones que van a residir dentro de la empresa. Por ejemplo, un muy mal candidato para iniciar el paso a la nube es una aplicación que interactúe mucho con aplicaciones locales, ya que esto va a crear muchos puntos de conexión que van a ser muy difíciles de mantener – Esta es la razón por la cual normalmente los ejemplos en la nube son aplicaciones aisladas con silos de información que no interactúan prácticamente con ninguna otra aplicación. Además, si la empresa no tiene una arquitectura Orientada a Servicios, debe de establecer muy cuidadosamente los pasos a seguir, ya que sin un ESB pasarse a la nube puede convertirse en un tema muy doloroso – algo que trataremos en el próximo post.

Otro punto relevante asociado con el tema anterior es el transporte de datos desde la nube hacia la infraestructura local – on premises – que tiene la empresa. A la hora de seleccionar la aplicación debemos buscar una en donde el transporte de datos entre ambas plataformas no sea exhaustivo ya que el usuario final va a notar el atraso en esta integración lo que podría generar que el usuario empiece a quejarse dando a entender que la plataforma actual es más lenta que la anterior, lo cual puede ser cierto considerando que la comunicación siempre va a tener una latencia al utilizar comunicación a través de http; la idea por lo tanto es que nuestras primeras aplicaciones en la nube sean de poco tránsito de integración. Desde el punto de vista costos también impacta ya que la mayoría de plataformas en la nube cobran por transacción saliente y transacción entrante.

Un punto que casi nadie toca es el tema relacionado con el llamado “vendor lock” de las plataformas PAAS en el “cloud computing”. Esto implica que si desarrollamos o modificamos una aplicación para que corra en una aplicación – por ejemplo Azure – no será fácilmente portable a otra plataforma como por ejemplo AWS. Creo que al final habrá una tendencia más orientada hacia IAAS que hacia PAAS, ya que esta última “amarra” más al cliente que el IAAS. Aquí debemos buscar una aplicación que no tenga tanta complejidad y no requiera muchas modificaciones específicas a la plataforma, ya que si esta no nos funciona entonces podremos llevarla prácticamente igual a otra plataforma que deseemos probar.

El último punto que vamos a tratar es la seguridad. Este es un tema que merece un post completo aparte y que estaremos realizando en un futuro cercano, sin embargo; al inicio de cada proyecto siempre se debe generar confianza con la plataforma que se esta utilizando – y eso no solo para proyectos en la nube – y por lo tanto debemos escoger un proyecto que no tenga datos sensibles no por que la nube sea insegura, si no porque debemos demostrarle al usuario que la nube es tan confiable como cualquier otro sitio web donde se procesen datos muy sensibles.

Etiquetas de Technorati: SOA,Cloud Computing

Entender el Cloud Computing

En muchos casos he tenido la oportunidad de estar en proyectos o “intenciones” de proyectos en donde se toca el tema de computación en la nube y de una forma u otra, todos los participantes tienen su propia definición de lo que es “Cloud Computing”. No creo que ninguna esté del todo mal, ni tampoco que ninguna sea la verdad absoluta, pero creo que al final todas tienen elementos que conforman lo que definiría la computación en la nube. Incluso buscando en Internet – “Googleando en Bing” – podemos ver que existen una gran cantidad de sitios Web con diversas definiciones de lo que es cloud computing.

Es por esta razón, que particularmente creo que la mejor forma de explicar lo que es Cloud Computing es a través de un ejemplo, y esto es lo que voy a hacer en este post.

Banco Salarial de Allá

Supongamos que en un lugar del mundo, existe un banco en donde todas las empresas le depositan el salario a sus empleados, tanto empleados de empresas públicas como empleados de empresas privadas. Aunque los empleados de dichas empresas ahorran mucho dinero, por lo general corren a sacar dinero para pagar sus obligaciones ya sea a fin de mes, o con el pago de la quincena. Por esta razón el sistema que se encarga de manejar las cuentas de los usuarios tiene picos de funcionamiento esos días. El siguiente gráfico nos muestra como se comporta el sistema.

Como podemos ver en el gráfico anterior de procesamiento del sistema de retiros, los primeros del mes y a mediados del mes se produce un fuerte incremento en las transacciones de los usuarios en las cajas y los cajeros electrónicos. Con este dato podemos estar seguros que la capacidad de hardware que necesita el banco para funcionar es un par de puntos superior al pico superior de uso mostrado en la gráfica; es decir, podemos decir que el hardware del banco pasa la mayoría del tiempo ocioso.

La idea detrás del “cloud computing” esta tener el hardware necesario para el procesamiento promedio que ocupa la empresa y “rentar” otra plataforma que esta en la nube para cuando tengo picos de consumo. Siguiendo con el ejemplo del gráfico anterior, debería tener Hardware para el promedio y rentar la diferencia.

En otras palabras, “cloud computing” es el procesamiento distribuido que yo pueda hacer en la nube para poder satisfacer la demanda de mis usuarios. Con este esquema, el ahorro en hardware, mantenimiento, soporte y demás ítems que requiere una plataforma es evidente ya que invierto lo que realmente necesito utilizar y lo demás lo rento

Etiquetas de Technorati: Cloud Computing