WHITE PAPER

MIGRACIÓN DE UNA APLICACIÓN ON-PREMISE

A WINDOWS AZURE

OSSESoluciones - Cartera de Soluciones en Tecnologías de Información

Sep2014

Pág. 2

Contenido

Resumen ..................................................................................................................................................... 3

Acerca de Windows Azure ........................................................................................................................ 4

Caso de Estudio: Migración de la aplicación RouteRegister a Windows Azure .............................. 5

Consideraciones previas a la Migración ................................................................................................. 6

Enfoque, Estrategia y Topología de Migración ...................................................................................... 7

Ejecución de la Migración ......................................................................................................................... 9

Referencias ............................................................................................................................................... 10

Pág. 3

Resumen

Este documento explica cómo migrar aplicaciones web ASP.NET que existen dentro de las instalaciones

de la empresa en un esquema On-Premise hacia Windows Azure, la nube de Microsoft, utilizando servicios

PaaS (Platform as a Service) e IaaS (Infrastructure as a Service). Está destinado a arquitectos de software

y desarrolladores que diseñan y construyen servicios cloud.

Cubre además un caso de estudio para migrar la aplicación “RouteRegister” de la empresa OSSE a la nube

de Windows Azure.

Pág. 4

Acerca de Windows Azure

Windows Azure es la plataforma Cloud Computing de Micrososft. Esta plataforma permite desplegar y administrar

aplicaciones en varios esquemas y modelos que van desde la utilización de esquemas puros de Infrastructure as a

Service (IaaS), y que pueden combinarse además con otros como Platform as a Service (PaaS) y Software as a Service

(SaaS). Windows Azure puede ser utilizado para:

Construir aplicaciones Web que se ejecuten y almacenen dentro de los centros de datos de Microsoft, con

distribución local, regional, y/o distintas áreas geográficas.

Almacenar datos para aplicaciones que se encuentran fuera de esta nube, en esquema On-Premise u otras

ubicaciones cloud.

Crear y administrar máquinas virtuales para entornos de desarrollo, pruebas y producción. Con diversos

sistemas operativos e imágenes específicas (ISOs) que incluyen software base y de aplicación de distintos

fabricantes y partners tecnológicos.

Construir aplicaciones de alcance masivo, escalables en potencia y capacidad para atender a miles de

usuarios.

Ofrecer una gran cantidad de servicios diversos.

Windows Azure y sus servicios están centrados en la construcción de aplicaciones, no en la infraestructura. Los

principales beneficios de utilizar Windows Azure para alojar aplicaciones incluyen:

Mínimo enfoque en la infraestructura. El enfoque es en las aplicaciones.

La organización no requiere comprar/mantener/administrar infraestructura física.

Facilidad para el escalamiento Up/Down, disponible en un esquema de pago por consumo (Pay-As You-go).

Los desarrolladores con conocimiento y habilidades sobre .NET pueden desarrollar y migrar aplicaciones a

Windows Azure aprendiendo el Azure SDK.

Windows Azure proporciona un SLA del 99,95% para las aplicaciones alojadas.

Algunos modelos de implementación típicos en Windows Azure incluyen máquinas virtuales, servicios cloud,

aplicaciones y sitios Web, y servicios móviles.

Para más detalles sobre Windows Azure, visite http://azure.microsoft.com/es-es/

Figura 1. Cloud stack IaaS, PaaS, SaaS

Pág. 5

Caso de Estudio: Migración de la aplicación

RouteRegister a Windows Azure

RouteRegister es una aplicación Web para de registro de rutas de transporte de pasajeros, incluyendo las sedes de

origen y destino, así como los datos de los vehículos y su tripulación. Se ha decidido migrar esta solución a un esquema

cloud utilizando un esquema híbrido que utilice servicios On-Premise y servicios PaaS de Windows Azure, la

plataforma cloud de Microsoft. La arquitectura y configuración de esta aplicación inicialmente es como sigue:

Está construido con ASP.Net 4.0 y alojado en el centro de datos de la empresa bajo un esquema On-Premise.

Se puede acceder a la aplicación desde Intranet e Internet. La aplicación cuenta con una base de datos propia

de usuarios para validar el acceso.

Utiliza una base de datos Oracle11g principal para almacenar sus datos. Además se conecta directamente a

otras bases de datos, Oracle11g y SQLServer2005/2000, para realizar diversas consultas y validaciones.

Utiliza algunos servicios externos que también proveen información de consulta y validación.

Además de su Interfaz Web cuenta con WebServices para realizar las mismas transacciones directamente

desde otras aplicaciones que puedan invocarlos.

Está alojada en un servidor compartido para capa de aplicación, y otro para la base de datos, también

compartido.

Figura 2. Arquitectura RouteRegister (On-Premise)

Pág. 6

Consideraciones previas a la Migración

Hay varios puntos que se deben considerar al mover una aplicación a Windows Azure. Los temas principales que

necesitan que abordar son:

Compatibilidad de las aplicaciones. Se debe analizar si la arquitectura de la aplicación se ajusta al esquema

cloud antes de migrarla. Si no lo es, se debe validar las consideraciones de adaptación, que puede ir desde

adicionar componentes, hasta reescribir código fuente.

Validar cuáles son dependencias externas / internas. Se debe inventariar cualquier dependencia de la

aplicación con otras aplicaciones, si son accesibles desde Windows Azure, y la estrategia para hacerlo.

Clasificación de la aplicación. Compruebe cómo el negocio clasifica la aplicación. Las aplicaciones y

servicios críticos, normalmente requieren de un esquema de alta disponibilidad.

La integración de la aplicación. Comprobar si la aplicación se integra a otras aplicaciones On-Premise, o

utiliza/provee servicios compartidos.

Compatibilidad de la base de datos. Analizar y compatibilizar la base de datos es el paso más importante y

la mejor forma de migrar a Windows Azure.

Requerimientos de Mantenimiento y Gestión. Identificar cómo se mantiene los logs de la aplicación y en

donde se almacenan.

Escalabilidad / Elasticidad. Identificar si el diseño de la aplicación permite escalarla, tal como es soportado

en Windows Azure (cloud ready application).

Requisitos / Protocolos / Estándares. Verifique si en la organización hay reglamentos, estándares, normas,

regulación, que rijan sobre la ubicación y almacenamiento de los datos para validar si pueden ser almacenados

fuera del control de la empresa. De existir, validar si estos reglamentos pueden ser actualizado/modificados.

Seguridad. Validar si se puede replicar o mejorar el nivel de seguridad de la aplicación luego de migrarla a

Windows Azure en términos de:

o Seguridad de los datos

o Autenticación

o Autorización

Pág. 7

Enfoque, Estrategia y Topología de Migración

Existen algunos puntos en donde se debe poner especial atención para el diseño del nuevo esquema cloud de la

aplicación.

a) Sobre la UI. Analizar si la UI se puede migrar a Azure directamente al esquema PaaS. Las aplicaciones web

y WebServices On-Premise, se pueden asignar a WebRoles de Windows Azure. Se requiere realizar un

trabajo de reingeniería para modificar el código de la aplicación Web actual de forma que utilice el SDK de

Azure. Esto es necesario para que se puedan ejecutar los servicios de nube correctamente. Si se utilizan

librerías o piezas de código no compatibles con Windows Azure, estas deberán ser cambiadas o reescritas.

b) Sobre las Transacciones y manejo de Sesiones. En Azure, cada instancia WebRole se ejecuta en su propia

máquina virtual y pueden ser configurados detrás de un balanceador de carga. Sin embargo las sesiones de

ASP.Net no se comparten de forma automática usando el balanceador de carga. Existen diversos enfoques

para hacer frente a este punto, son los siguientes:

a. Utilizando Inproc. Inproc puede ser la mejor opción de rendimiento. Es la forma de gestión por

defecto. Para ambientes de Windows Azure con balanceador de carga, sólo va a funcionar en una

instancia única. Si se utiliza más de una instancia, podría dar lugar a incoherencias.

b. Usando un proveedor de tablas de almacenamiento para sesiones. Existe un subconjunto de

proveedores diseñados específicamente para su uso en Windows Azure. El almacenamiento de la

sesión en estas tablas es accedido a través de unas librerías que se compilan con la aplicación.

Permite a los desarrolladores utilizarlos para almacenar el estado de las sesiones en Tablas de

almacenamiento en Windows Azure. Este es un enfoque de costo relativamente bajo, bien probado

y listo para consumo, con muy poco trabajo de reingeniería.

c. Usando el proveedor de sesiones de SQL Azure. La base de datos SQL Azure es esencialmente un

subconjunto de SQL Server. Y también puede ser utilizado como almacenamiento para el estado de

las sesiones. Si se utiliza el proveedor de la misma base de datos existente para la aplicación, resulta

muy rentable.

d. Usando Windows Azure caché. Es posible utilizar una parte de la memoria caché para las instancias

WebRol o WorkerRol, o usar una porción de uso dedicado para todos los servicios de Windows

Azure de forma que sea compartido entre sitios Web, WebRoles, WorkerRoles y Máquinas

Virtuales.

c) Sobre la interacción con otros módulos y/o aplicaciones. Validar si se pueden reutilizar los servicios de WCF.

Las aplicaciones con las que se interactúa pueden quedarse On-Premise y publicarse como servicios para

luego ser accedidos directamente o vía el Azure Service Bus, AzureVPN.

d) Sobre Diagnostico y soporte. Existe por ejemplo el servicio Azure Diagnostic, que permite recolectar y

almacenar datos en tablas de Windows Azure. El loggin puede ser customizado para capturar los errores y

eventos generados por la aplicación.

e) Sobre la Migración de Base de datos. Existen varios esquemas y topologías que pueden ser aplicadas según

la arquitectura de la aplicación. El objetivo es realizar un diseño que garantice la consistencia de los datos y

la mantenibilidad del modelo. Este diseño requiere conocer si la migración se hará una única vez o será

permanente como parte de la solución. En el segundo caso, se debe tener en mente también la Estrategia de

sincronización para hacerla optima en tiempo y disponibilidad.

Pág. 8

En el caso de estudio propuesto, existe un componente importante a considerar con respecto a la compatibilidad de

las bases de datos. Si bien es cierto, actualmente existen máquinas virtuales con imágenes de sistema operativo con

BD Oracle, se requiere de una inversión adicional para la gestión de este entorno IaaS. La aplicación actual tiene como

base de datos principal una instancia Oracle y se integra fuertemente a otras bases de datos también Oracle y otras

SQL2000/2005. En este caso, la integración de la aplicación con otras aplicaciones es muy grande, y una primera

solución requería migrar cada una de las aplicaciones de forma independiente, además hacerlas funcionar juntas como

lo hacen en el esquema On-Premise. Este caso nos proporciona un esquema interesante de análisis, en donde por

condiciones de diseño, se considera una base de datos SQLServer2008R2 (o superior) que pueda centralizar la data

de consulta de las demás bases de datos. Una vez centralizada, es mucho más simple llevar este set de datos a nube

como una sola unidad con ahorros considerables de costo y tiempo, así como aprovechando las ventajas de los

servicios Azure. La Topología propuesta para esta migración es como sigue:

Figura 3. Arquitectura RouteRegister Propuesta (Híbrida)

Pág. 9

Ejecución de la Migración

La migración de la aplicación RouteRegister, consiste en trasladar cada uno de sus componentes a la nube de forma

gradual e independiente. En cada fase, se debe asegurar no existen dependencias ni problemas para asegurar su

correcto funcionamiento. A continuación se explica el proceso de migración para los componentes de On-Demand

(Paas) y On-Premise.

Figura 4. Diseño y Construcción de componentes On-Demand

Figura 5. Diseño y Construcción de componentes On-Premise

Pág. 10

Referencias

Introducing Azure

http://azure.microsoft.com/es-es/documentation/articles/fundamentals-introduction-to-azure/

Microsoft Azure Infographic 2014

http://go.microsoft.com/fwlink/?LinkId=397969

Appendix A - Replicating, Distributing, and Synchronizing Data

http://msdn.microsoft.com/en-us/library/hh868047.aspx