Exportar (0) Imprimir
Expandir todo

Planear una migración a Azure

Actualizado: abril de 2014

Cuando empiece a planear la migración, necesitará tener en cuenta varios factores clave como el costo, los requisitos de negocios y técnicos, la escala de tiempo y cualquier prueba que sea necesaria durante el proceso de migración. En esta sección se repasan varios aspectos y pasos que debe tener en cuenta mientras planea una migración a Azure:

Autores: Steve Howard
Revisores: James Podgorski, Paolo Salvatori, Selcin Turkarslan, Stuart Ozer

Planear el costo

El costo es una de las preguntas más importantes que hay que responder. Se recomienda tratarlo en las etapas iniciales del proceso de planeación y toma de decisiones a la hora de considerar la migración de una aplicación local a Azure. El precio de una aplicación para Azure depende de varios factores como la carga de tráfico de red, las características de entrada y salida de la aplicación, y el volumen de datos procesados por la aplicación. El cálculo del precio queda fuera del ámbito de este tema. Recomendamos que use la calculadora de precios de Azure como ayuda para calcular el costo cuando empiece a planear la migración. Aquí tiene la calculadora de precios de Azure.

Cuando calcule el costo para la organización, no olvide incluir los costos directos de Azure durante el desarrollo y las pruebas. En un proyecto de desarrollo local, se pagan los servidores de desarrollo y de pruebas. Del mismo modo, en el entorno Azure, debe pagar los recursos que use durante el desarrollo y las pruebas. Además, debe calcular los costos de entrenamiento y aprendizaje, así como los costos asociados al transporte de la aplicación a Azure. Recomendamos que realice pruebas de rendimiento y que planee la capacidad para evaluar de antemano cuánta capacidad necesitará para la aplicación.

Identificar los principales requisitos de negocios y técnicos que Azure puede ayudar a resolver

Azure puede atender perfectamente diversos requisitos de negocios y técnicos. Si bien esta lista no incluye todas, las aplicaciones con estas características son buenas candidatas para la migración a Azure:

  • Base de usuarios distribuida: hay centros de datos de Azure repartidos por varios continentes. La interconexión entre los centros de datos permite realizar una distribución de datos de alto rendimiento cuando sea necesario. Algunas características de Azure como los servicios Red CDN y de sincronización de datos permiten mantener datos pertinentes o de uso frecuente distribuidos entre centros de datos cercanos a los usuarios finales. El hecho de que los usuarios tengan acceso a centros de datos cercanos a su ubicación geográfica minimiza la duración del viaje de ida y vuelta, lo que optimiza la experiencia del usuario.

  • Carga variable: necesita adquirir hardware para que las aplicaciones locales puedan atender picos de carga. Por ejemplo, una tienda pequeña suele comprar servidores para poder atender la carga de la temporada alta de compras. Del mismo modo, un departamento de contabilidad puede planear cierta infraestructura adicional para poder atender picos de carga en los ciclos de cierre de fin de mes o de fin de año. El resto del tiempo, los servidores pensados para atender esas carga pico están infrautilizados. Por otra parte, las aplicaciones cuya arquitectura admite escalado flexible pueden aprovechar Azure para poner en conexión nuevas instancias de aplicaciones durante las horas pico y volver a niveles menores de potencia y capacidad de procesamiento durante los períodos en los que haya necesidades menores. De esta forma, Azure le permite pagar únicamente por lo que necesita siempre y cuando se trate de aplicaciones correctamente diseñadas y administradas.

  • Multiempresa: para los proveedores de servicios, Azure permite varias formas de proporcionar sus servicios de aplicaciones a cualquier número de clientes en la misma infraestructura, lo que minimiza sus costos operativos.

  • Necesidad de centrarse en las aplicaciones: los proveedores de servicios en concreto desean concentrar sus recursos en el desarrollo de aplicaciones y características más que en el mantenimiento de la infraestructura. Azure le libera de gran parte de la sobrecarga administrativa que conlleva la infraestructura que hospeda aplicaciones de servidor locales u hospedadas tradicionales. Le permite concentrar sus recursos en el desarrollo de aplicaciones y características.

  • Minimizar los requisitos de recursos de la infraestructura: al diseñar las aplicaciones para que aprovechen el escalado flexible que proporciona Azure, también se pueden asignar instancias de roles y recursos según sean necesarios. No es necesario realizar ninguna inversión en hardware por adelantado ni se necesita mantener servidores capaces de atender cargas pico durante momentos de poca utilización.

Además de las ventajas de las plataformas tradicionales como servicio, Azure puede hospedar máquinas virtuales. Estas máquinas virtuales pueden ejecutar cualquier sistema operativo admitido por Azure y pueden ejecutar aplicaciones de la misma forma que si se ejecutaran localmente. Vea Información general sobre Máquinas virtuales de Azure para obtener una lista de los sistemas operativos admitidos. Además, estas máquinas virtuales pueden formar parte de una arquitectura de aplicaciones mayor que puede incluir instancias de roles web o de trabajado y otros componentes de Azure. Las máquinas virtuales son una forma de transportar algunos servicios o partes de aplicaciones que de otra forma no se podrían trasladar fácilmente a Azure. Para obtener más información, vea Migrar con Máquinas virtuales de Windows Azure.

Realizar el análisis y el diseño

En la fase de análisis y diseño, debe identificar las aplicaciones que resultarían más beneficiadas si se movieran a Azure. Después, empiece a diseñar la implementación de Azure y el plan de implementación. Durante esta fase, debe planear el esquema del diseño de la arquitectura y la escala de tiempo.

He aquí algunos de los elementos principales de la planeación:

  • Identificar los desafíos actuales: en la lista siguiente se muestran algunos ejemplos de desafíos que se deben identificar al planear cualquier necesidad de cambio de diseño:

    • Componentes de la aplicación que no funcionan según el estándar con las cargas actuales en la arquitectura actual: por ejemplo, si una consulta SQL no funciona correctamente, debe optimizarla antes de la migración o de cambiar su diseño. También debe rediseñar y realizar un escalado horizontal de todos los componentes de la capa de aplicación.

    • Determinar los requisitos de escalado flexible: debe identificar cómo se puede descomponer la aplicación en unidades funcionales escalables de forma independiente que se puedan ejecutar independientemente unas de otras.

    • Patrones de carga irregulares: debe identificar los patrones de carga irregulares y diseñar la aplicación para el escalado horizontal con el fin de atender los períodos de máxima actividad. Debe planear cómo administrar el nivel de escalado horizontal desde los períodos de máxima actividad hasta los períodos con poca demanda.

    • Previsiones de crecimiento: con frecuencia, las previsiones de crecimiento son la primera señal que alertan al departamento de TI de que puede ser necesario un cambio de paradigma. Decida cuándo el escalado horizontal puede ser una solución para atender las previsiones de crecimiento. Las previsiones de crecimiento también pueden ser el indicador que necesita para considerar cambios de paradigma como el cambio a un paradigma de análisis big-data en determinadas aplicaciones centradas en almacenes de datos. Estas opciones se deben tratar en la fase de planeación. Tenga en cuenta que quizás no pueda saber la solución con seguridad hasta más adelante, durante el proceso de diseño e implementación. Debe hacer una lista de esas contingencias y factores determinantes para poder evaluarlos en el momento adecuado, como puede ser durante la migración inicial o en una fecha posterior.

  • Identificar los requisitos técnicos: averigüe cuáles son los requisitos de cada componente de la aplicación en momentos de máxima actividad y de poca actividad. Después, planee la escala de cada componente. Cada componente puede tener una capacidad y un mecanismo de escalado diferente. Los requisitos técnicos pueden ser algo más que el rendimiento. Por ejemplo, los requisitos de alta disponibilidad y recuperación ante desastres, o los requisitos de latencia máxima de red se deben determinar y comparar con las capacidades de Azure a la hora de planear una migración. En la lista siguiente se muestran algunos ejemplos de requisitos técnicos:

    • Uso de almacenamiento relacional: examine los datos almacenados en las bases de datos relacionales. Los datos de naturaleza verdaderamente transaccional y relacional o los datos que necesitan un procesamiento realmente transaccional deben seguir estando en almacenamiento relacional. Puede usar Base de datos SQL de Azure (Base de datos SQL) o SQL Server que se ejecute en Máquinas virtuales para almacenar este tipo de datos. Puede almacenar otro tipo de datos en Tablas de Azure, almacenamiento de Blob de Azure o unidades de Azure de manera eficiente. Recomendamos que identifique el tipo de almacenamiento necesario para cada parte de los datos.

    • Elegir el almacenamiento de datos relacionales: la elección entre Base de datos SQL o SQL Server que se ejecuta en Máquinas virtuales de Azure depende de varios factores. Si desea evitar la sobrecarga administrativa que supone la alta disponibilidad, equilibrio de carga y conmutación por error transparente, Base de datos SQL es la mejor elección. Sin embargo, para un estado intermedio durante la migración de una aplicación o para casos especiales en los que algunas características todavía no están disponibles en Base de datos SQL, SQL Server que se ejecuta en Máquinas virtuales de Azure puede ser la mejor solución. Las respuestas a estas preguntas dependen de la situación y la solución. En la lista siguiente se muestran algunas consideraciones al respecto:

      • Tamaño de la base de datos: las Bases de datos SQL de Azure están limitadas actualmente a 5 GB de datos para la base de datos Web Edition y a 150 GB de datos para la base de datos Business Edition. Para expandir la capacidad de la base de datos, use el método de escalado horizontal. Para obtener información sobre los métodos de escalado horizontal de Azure, lea "Ampliar Bases de datos SQL de Windows Azure". Para obtener la información más actualizada sobre las ediciones y los tamaños de base de datos disponibles, vea Accounts and Billing in SQL Database.

      • Número de bases de datos: de forma predeterminada, Base de datos SQL admite hasta 6 servidores por suscripción y 150 bases de datos en cada servidor de Base de datos SQL, incluida la base de datos maestra. Este límite se puede ampliar. Para obtener más información, póngase en contacto con un representante del servicio de soporte al cliente en el Portal del cliente de Microsoft Online Services.

      • Consultas entre bases de datos: en la actualidad, Base de datos SQL no admite combinaciones ni otras consultas entre bases de datos. Si necesita uniones o combinaciones que solicitan datos de más de una base de datos en Base de datos SQL, debe realizar esa lógica en la capa de aplicación de su aplicación.

      • Objetos de Common Language Runtime (CLR): Base de datos SQL no admite actualmente procedimientos almacenados, agregaciones, desencadenadores o funciones de CLR. Debe transportar los procedimientos almacenados, los desencadenadores o las funciones a Transact-SQL para poderlos ejecutar en Base de datos SQL. La lógica o las operaciones complejas, como las agregaciones, que no se puedan realizar en Transact-SQL en la capa de base de datos deben moverse a la capa de aplicación. Para ello puede emplear un rol de trabajador.

      • Tipos de datos: Base de datos SQL no ofrece compatibilidad con algunos tipos de datos del sistema de SQL Server. Para obtener la información más actualizada, vea Data Types (SQL Database) en la Biblioteca de MSDN sobre SQL.

      • Replicación: en Base de datos SQL no están disponibles tipos de replicación como la replicación transaccional o la replicación de mezcla. Puede configurarlos y ejecutarlos en SQL Server que se ejecuta en Máquinas virtuales de Azure. Puede usar SQL Data Sync para sincronizar datos entre varias instancias de Base de datos SQL. Sin embargo, el servicio SQL Data Sync quizás no sea adecuado cuando se necesite coherencia transaccional o resoluciones de conflictos complejos. Advertencia: SQL Data Sync solo está disponible actualmente como versión preliminar y su fin es solo servir como origen de comentarios sobre el producto para las versiones futuras; no debe usarse en entornos de producción.

      • Búsqueda de texto completo: Base de datos SQL de Azure no admite actualmente la búsqueda de texto completo. Si su aplicación ejecuta consultas de texto completo sobre datos de caracteres en tablas de SQL Server, quizás desee migrar la base de datos a SQL Server en una Máquina virtual de Azure. Para obtener más información sobre SQL Server en Máquinas virtuales de Azure, vea el tema Migrar a SQL Server en una máquina virtual de Azure.

      • Licencias: el uso de Base de datos SQL se cobra mensualmente según el tamaño de base de datos elegido. SQL Server necesita una licencia cuando se ejecuta en una Máquina virtual de Azure.

      • Inicio de sesión y seguridad: la autenticación de Windows (seguridad integrada) no se admite en Base de datos SQL, pero está disponible en SQL Server cuando se ejecuta en Máquinas virtuales de Azure. Para conocer más instrucciones de seguridad y limitaciones de Base de datos SQL, vea Security Guidelines and Limitations (SQL Database).

      • Paridad de características: para obtener más información sobre las similitudes y diferencias entre SQL Server y Base de datos SQL, vea SQL Database Overview.

  • Inicio de sesión y seguridad de usuarios: con las nuevas mejoras de red realizadas en Azure, se puede extender a Azure un dominio de Active Directory de la red local. Para obtener más información, vea Migrar con Máquinas virtuales de Windows Azure. Para obtener información detallada sobre la administración de la seguridad en Base de datos SQL, vea Managing Databases and Logins in SQL Database.

  • Descomposición funcional de la aplicación: identifique en qué lugar se puede dividir la aplicación en unidades funcionales para que se pueda ejecutar en roles o en máquinas virtuales diferentes de Azure. Esto le permite lograr un escalado flexible y disponer de aplicaciones híbridas si algunas aplicaciones no son idóneas para informática en nube.

  • Payment Card Industry (PCI) y otros requisitos legales: antes de mover una aplicación o un componente a Azure, compruebe el estado actual de las certificaciones o los requisitos necesarios. En casos como los requisitos de cumplimiento de PCI, quizás desee quitar algunas partes de la aplicación y la base de datos que se migraron a Azure, y ejecutar una aplicación híbrida. Esto permite disfrutar de las ventajas de Azure y la informática de nube en la mayoría de componentes, al tiempo que permite mantener un estrecho control institucional y el cumplimiento para las partes de los datos y de la aplicación para los que sean necesarios.

  • Principales componentes que no se pueden hospedar en la plataforma Azure: quizás no pueda hospedar algunos componentes o algunos tipos de datos en la nube pública debido a otras cuestiones. Identifique estos componentes y considere la posibilidad de usar una aplicación híbrida. Con una arquitectura híbrida, puede hospedar algunos componentes en Azure para disfrutar de todas las ventajas de Azure y la informática de nube. Al mismo tiempo, puede mantener un estrecho control institucional y el cumplimiento para las partes de los datos y de la aplicación para los que sean necesarios.

Planear la escala de tiempo

Una vez definido el ámbito de la migración, también se aclara la cantidad de trabajo necesario para cada paso del plan de migración. Examine cada componente de aplicación y de datos y calcule el tiempo y los recursos necesarios para el desarrollo, las pruebas y la migración. Al descomponer funcionalmente la aplicación, desarrolle esos componentes descompuestos en paralelo para producir los componentes escalables de manera flexible.

Establezca hitos del proyecto como pruebas funcionales y de rendimiento, y fechas de lanzamiento en el plan de migración. La migración puede realizarse en una serie de pasos e iteraciones a medida que los distintos componentes estén preparados para Azure o a medida que los componentes estén preparados para su traslado a roles web y roles de trabajo de Azure.

Elaborar un plan provisional

Una vez establecida la escala de tiempo para el desarrollo y la migración, planee el crecimiento durante ese período de tiempo y decida qué hay que hacer en la aplicación y la infraestructura existentes. Este tipo de planeación le permite usar el sistema existente hasta que se haya completado la migración. Cuando elabore este plan provisional, identifique los puntos débiles actuales y lo que se debe hacer para permitir un funcionamiento continuado, y en qué operaciones de escala se puede continuar en la infraestructura provisional. Identifique también los pasos que quizás necesite para permitir el funcionamiento continuado. Con frecuencia, estos pasos pueden ser tan sencillos como optimizar una consulta SQL o agregar un servidor web, según las características de su aplicación concreta. Identifique planes de contingencia por si el crecimiento real es más rápido que el estimado o por si se produce un aumento repentino inesperado. Cuando elabore planes de contingencia, considere si los aumentos repentinos o el crecimiento se pueden asumir con el escalado horizontal a Máquinas virtuales de Azure, ya que esto le permite administrar estas situaciones sin realizar inversiones adicionales en hardware.

Crear un plan de pruebas

Todo plan de migración debe incluir planes para realizar pruebas de funcionalidad y de carga exhaustivas. La descripción de las metodologías de prueba queda fuera del ámbito de este artículo. En la lista siguiente se muestran algunos puntos críticos que no conviene olvidar a la hora de realizar pruebas:

  • Automatizar scripts de prueba

  • Probar todas las capas y los componentes de la aplicación

  • Realizar pruebas en proporciones de actividades que representen las propiedades reales de los sistemas

  • Realizar pruebas en el mayor nivel de utilización esperada o en uno superior

Se recomienda que dedique tiempo a generar y ejecutar pruebas, y a corregir los problemas detectados durante las pruebas.

Identificar los recursos necesarios

A la hora de definir los requisitos de negocios y técnicos, identifique los recursos necesarios para realizar la migración correctamente. Quizás tenga que reunirlos para la migración. He aquí las principales áreas que hay que examinar al identificar recursos:

  • Personal: puede que necesite más empleados con otros conocimientos adicionales para poder migrar correctamente la aplicación. Además, después de la migración, los roles del personal técnico pueden cambiar y quizás haya que actualizar los conocimientos. Por ejemplo, considere los roles de Administrador de la cuenta y de Administradores de servicios para administrar los inicios de sesión, el acceso y los niveles de servicio y escala.

  • Herramientas: identifique las herramientas necesarias para desarrollar, probar e implementar la aplicación de Azure. Para obtener más información, vea Azure Tools para Microsoft Visual Studio y Tools and Utilities Support (SQL Database).

  • Consultoría: quizás necesite conocimientos específicos para migrar la aplicación. Un especialista en migraciones puede ahorrar mucho tiempo y dinero al ayudarle a evitar obstáculos frecuentes.

Planear la administración de aplicaciones en Azure

En el caso de aplicaciones pequeñas, el portal de administración de Azure puede ser suficiente para administrar implementaciones de Azure. El portal de administración de Azure le permite iniciar sesión y administrar las implementaciones y aplicaciones, incluido el cambio del número de roles de instancia, y la administración de instancias de Base de datos SQL. Sin embargo, cuando se trata de aplicaciones complejas y aplicaciones que ofrecen un servicio a los clientes, puede que el portal de administración de Azure no sea suficiente.

Azure expone la API REST para permitirle administrar mediante programación aplicaciones y máquinas virtuales hospedadas en Azure, así como aprovisionar y usar almacenamiento de Azure. Puede escribir una interfaz de administración para el escalado y la supervisión de su entorno Azure. El plan de migración debe incluir un plan para administrar la aplicación después de la migración, especialmente si esta administración va a incluir una interfaz personalizada o automatización.

Para obtener más información sobre la API de REST para administrar implementaciones de Azure, vea Referencias de API para Azure.

Vea también

Adiciones de comunidad

AGREGAR
Mostrar:
© 2014 Microsoft