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

Transcripción

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 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 Pág. 2

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

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 Figura 1. Cloud stack IaaS, PaaS, SaaS Pág. 4

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

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

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

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

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

10 Referencias Introducing Azure Microsoft Azure Infographic Appendix A - Replicating, Distributing, and Synchronizing Data Pág. 10