Este documento describe la migración de una aplicación web ASP.NET de un entorno on-premise a Windows Azure. Explica las consideraciones previas a la migración como la compatibilidad y dependencias. Propone una arquitectura híbrida con componentes on-premise y en la nube. Finalmente, detalla el proceso de migración de forma gradual e independiente para cada componente.

1. WHITE PAPER
MIGRACIÓN DE UNA APLICACIÓN ON-PREMISE
A WINDOWS AZURE
OSSESoluciones - Cartera de Soluciones en Tecnologías de Información
Sep2014

2. 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

3. 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.

4. 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

5. 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)

6. 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

7. 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.

8. 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)

9. 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

10. 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