Haciendo una conexión segura a Windows Azure con WAC–Windows Azure Connect – Parte 1

En el post pasado, vimos que una de las formas más simples, económicas y seguras de exponer servicio al mundo exterior era utilizando la nube con lo que se conoce como Frame Relay. Ahora bien, la pregunta que surge es ¿Cómo hago mi conexión desde mi servidor de servicios hasta el servicio WCF en Azure? La respuesta es Azure Connect.

Windows Azure Connect es un componente de la plataforma Azure que permite crear conexiones entre computadoras ( o VMs ) dentro de la empresa y los roles de Windows Azure ( VMs al fin y al cabo ). Azure Connect (AC) crea una conexión segura IPSec desde el cliente hacia el servidor utilizando “agentes”, que en realidad son componentes de software en cada extremo que se encargan de administrar la conexión. La siguiente figura nos muestra esta funcionalidad.

Azure connect no solamente me va a permitir hacer “relay services” desde Azure hacia mis servicios WCF, si no también me facilita la posibilidad de acceder recursos desde la nube que están en mi “data center” tales como bases de datos, folders y archivos e impresoras. Igualmente, los roles de azure pueden incorporarse al active directory local utilizando AC.

Utilizando Azure connect podemos migrar aplicaciones a la nube y permitir que estas puedan seguir accediendo o interconectándose con otras aplicaciones dentro de la empresa ya sea utilizando arquitectura punto a punto, EAI o SOA.

En el próximo post vamos a implementar una conexión vía Azure connect desde Azure hacia una aplicación local.

Etiquetas de Technorati: Azure,Azure Connect

Service Relay: Exponer servicios desde mi empresa de forma segura

Normalmente las empresas tiene sitios web y servicios web para consumo interno que aunque deberían tener un esquema de seguridad, en muchos de los casos corren totalmente inseguros. Por otro lado, es común que las empresas tenga sitio web en donde el usuario pueda ver información de la empresa; estos comúnmente hosteados en datacenters de pago o en servicios de hosting en otros países como USA o Australia donde el costo es muy muy bajo –> alrededor de $5 al mes en su versión más básica.

Sin embargo, existe un escenario que siempre genera miedo entre las personas que componen un departamento de TI –> Necesitamos publicar nuestros servicios Web que acceden nuestros sistemas “core” de negocio, ya que requerimos que otros socios de negocio puedan consumirlos. Con ese escenario, aparecen diversas recomendaciones y soluciones – algunas efectivas otras no tanto – en donde por lo general hay que invertir una gran cantidad de dinero y esfuerzo.

Las soluciones varían en rango en temas tales como:

• Uso de una DMZ
• Uso del https
• Uso de certificados digitales para autenticar el servicio o para evitar tampering del mensaje.
• Poner varios servidores para evitar que el usuario ingrese directamente a los servicios y por ende a las capas inferiores

Todo esto sin duda puede ser efectivo [al menos retrasar el ataque] o disminuir la superficie de ataque, con lo cual vamos creando condiciones más incómodas para los posibles “hackers”. ¿Y a que viene todo esto y como lo relaciono con la nube?

Pues bien, resulta que Windows Azure tiene un componente que es muy relevante en estos ( y muchos otros ) escenarios. Este componente se llama el Service Bus. Este service bus nos permite exponer servicios utilizando una técnica conocida como “service relay”, en donde podemos exponer contratos de servicios en la nube que de forma privada consumen servicios que exponemos desde nuestra plataforma local, con lo cual obtenemos un nivel extra de aislamiento y además, estamos pasandole el primer nivel de protección a Windows Azure. En la siguiente figura se puede ver este escenario.

En este escenario, exponemos los servicios a través de Windows Azure y su Bus obteniendo así un nivel de abstracción que nos va a permitir asegurar el ingreso de consumidores a nuestros servicios ya que estos los podemos autenticar en la nube y autorizar de forma local. Igualmente, vamos a tener una conexión segura desde nuestra organización hasta la nube –> azure –> permitiendo no solo una conexión https si no también estableciendo que rango de dirección pueden interconectarse para exponer la implementación de los servicios. Con este escenario, lo que estamos pretendiendo es que para que un “hacker” pueda llegar a nuestro servidor, primero tenga que violentar la seguridad que vamos a establecer en el bus de Azure, con lo cuál no solo aumentamos la seguridad si no también reducimos costos ya que estamos trasladando parte del esfuerzo requerido a la nube. A este proceso de intermediación se le conoce como Service Relay.

Etiquetas de Technorati: Azure,Azure Service Bus,Servicios Web,Seguridad

El rol de máquina virtual–> VM Rol

En este post vamos a tratar el rol de máquina virtual. Este rol permite implementar imágenes de Windows Server 2008 R2 en Windows Azure. Este rol funciona a partir de una máquina virtual creada en Windows server siendo luego cargada al ambiente de Windows Azure. En realidad este tipo de rol lo que hace es ejecutar la imagen de Disco Duro Virtual ( VHD ) en donde fue creado o instalado el sistema operativo.

Características del rol de VM

Las principales características de este rol son:

• El sistema operativo de la máquina virtual se puede configurar y se le puede dar mantenimiento.
• Se pueden utilizar los servicios del sistema operativo dentro del rol.
• La máquina virtual puede pertenecer a un dominio de active directory y trabajarse a través del Azure Connect. Es importante destacar que un rol VM no puede ser un controlador de dominio de Active Directory –> esto por que no hay tráfico UDP.
• Se pueden ejecutar tareas programadas.

Consideraciones

Al tener nosotros la posibilidad de crear la máquina virtual de primera se nos presenta la idea de poner aplicaciones que no se pueden tener en Azure o que hay que pagar extra para tenerlos en Azure tales como SharePoint Server o SQL Server. Sin embargo, todas las instancias de los roles – no solo el de VM – deben de ejecutarse en un ambiente sin estado, lo que significa que no deben de depender en los datos almacenados en el sistema operativo; todo esto para permitir que varias instancias idénticas puedan estar disponibles para darle robustez a la aplicación. Por lo tanto aplicaciones como SharePoint o SQL server no se soportan en este rol ya que son aplicaciones que manejan un estado.

¿Es este un rol de la plataforma PAAS de Azure?

Cuando uno analiza el objetivo de este rol surge la pregunta respecto a su este rol realmente pertenece a una oferta PAAS o a una oferta IAAS. Desde mi punto de vista este rol no es una oferta PAAS, es una oferta IAAS; esto principalmente porque de acuerdo a lo que se establece para delimitar estas ofertas, en realidad el creador de la máquina virtual tiene control absoluto sobre el sistema operativo y sus peculiaridades, algo que no debería suceder en una plataforma PAAS. Estos delimitadores los pueden ver en este post.

Etiquetas de Technorati: VM Role,Windows Azure,Cloud Computing

Máquinas Virtuales en Windows Azure: El concepto de Rol

Tal y como comentaba en el post anterior, a través del uso de máquinas virtuales es como Windows Azure logra la separación de servicios entre servidores físicos. Cada máquina virtual esta dividida en varias máquinas virtuales; con esto, la aplicación de un cliente no interferirá con otra aplicación en el mismo servidor físico ya que cada una corre en una máquina virtual diferente.

Conformación de una máquina virtual

Cada máquina virtual tiene instalado la aplicación del cliente – conocido como servicio. Esta máquina virtual  es una instalación de Windows Server 2008 R2 con los componentes extras de Windows Azure. En el caso de tener un rol web la instalación tendrá habilitado el IIS 7.5. Un rol es simplemente otro nombre para la aplicación. En realidad se refiere a la imagen base del VM que “hostea” la aplicación – más acerca de los roles en Windows Azure en el próximo post.

Aunque nuestra aplicación corre en una máquina virtual, esta máquina virtual se abstrae del dueño de la aplicación el cual solamente puede ver la instancia del rol – de la aplicación – y nunca el contenido de la máquina virtual – Ejemplo claro del concepto de PAAS.

Por último, hace falta agregar que cada máquina virtual tiene un componente conocido como agente del proceso. Este agente de proceso monitorea la salud de la instancia en la que está ejecutándose y le reporta su estado al Fabric Controller; esto le permite a este componente llevar a cabo acciones tales como manejo de actualizaciones, reiniciar roles que no están respondiendo y mover las aplicaciones entre servidores físicos para garantizar su continuidad.

Etiquetas de Technorati: Windows Azure

Arquitectura de Windows Azure– Parte 1

Windows Azure es la oferta de Microsoft para el Cloud Computing. Es una oferta del tipo PAAS como lo vimos en el post anterior. A partir de este post, vamos a explorar como esta compuesto Windows Azure, y como es que funciona.

¿Windows Azure – Un Sistema Operativo en la Nube?

Al agregarle la palabra Windows a la plataforma, lo primero que se nos viene a la mente es: Sistema Operativo Windows. ¿Es Windows Azure un sistema operativo en la nube? Para contestar esta pregunta debemos primero analizar de forma básica que hace un sistema operativo. Un sistema operativo tradicional se encarga de reservar tiempo de CPU y memoria para que la aplicación pueda ejecutarse; además, es responsable de administrar estos recursos – reiniciar una aplicación, liberar memoria, etc. Todo esto en una sola máquina o un servidor. Entonces ahora nos preguntamos: ¿ y en la nube con Windows Azure cómo funciona esto?

Primero que todo tenemos que tener en cuenta que en Windows Azure nuestras aplicaciones no solo corren en un servidor, si no que potencialmente pueden correr de forma paralela en muchos servidores. A este nivel, Windows Azure no es responsable por reservar memoria y CPU en n servidores, si no que más bien el nivel de abstracción más alto utilizado en la plataforma son las máquinas virtuales. Podemos decir entonces que a nivel de una plataforma en la nube, el sistema operativo no es responsable por asignar los recursos de las aplicaciones – CPU y Memoria – sino que ahora es responsable por reservar recursos para las máquinas virtuales.

¿Como se organizan las máquinas virtuales en Windows Azure?

A través del uso de las máquinas virtuales es como Windows Azure permite separar servicios – o aplicaciones - entre servidores físicos. Cada servidor físico contiene n máquinas virtuales. Cada máquina virtual contiene solamente una aplicación lo que permite que una aplicación en el mismo servidor físico no interfiera con otra aplicación. Esta aplicación puede estar ejecutándose en varias máquinas virtuales en diferentes servidores físicos tal y como se muestra en la siguiente figura.

En nuestro siguiente post vamos a profundizar en el tema de las máquinas virtuales en Windows Azure.

Etiquetas de Technorati: Cloud Computing,Azure

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