Un enfoque simple para la modernización de aplicaciones con Azure

Las empresas de todos los tamaños están adoptando la nube. Es una plataforma ágil y rentable para ejecutar aplicaciones de software y garantizar la salud y la estabilidad de una empresa. Durante esta migración, la aplicación y el software propietario han sido la fuerza impulsora clave para pasar de los centros de datos privados a Azure. Existen varios enfoques para migrar aplicaciones a la nube. Puede migrarlos tal cual. O bien, puede optar por modernizar las aplicaciones para que sean más eficientes en Azure.

Enfoques de migración

En comparación con las nubes empresariales privadas, Azure tiene muchas más funciones. La mayoría de las nubes empresariales son solo plataformas de máquinas virtuales. Unos pocos soportan la contenedorización. A diferencia de, Azure ofrece bases de datos, puertas de enlace API, canalizaciones de CI/CD y mucho más como servicios administrados.

Estos servicios pueden simplificar la arquitectura del software y reducir el trabajo de DevOps. Pero, al migrar una aplicación desde un centro de datos privado a Azure, debe actualizar la aplicación para usar estos servicios.

Dependiendo de cómo elija actualizar la aplicación, existen tres enfoques principales para la migración.

  1. Levante y cambie – Rehost
  2. ~ Contenedorización
  3. Modernización para la arquitectura sin servidor Entremos en detalles sobre cada

Levantar y cambiar

Como ya mencionamos, la mayoría de las nubes empresariales implementan solo la virtualización. La mayoría de las aplicaciones empresariales también se ejecutan en máquinas virtuales (VM), mientras que algunas aplicaciones se instalan en servidores bare-metal. El lift and shift es una forma fácil de migrar estas aplicaciones a Azure. Crea máquinas virtuales en Azure e implementa las aplicaciones existentes en estas máquinas virtuales.

Azure tiene un mecanismo de red flexible. Por lo tanto, puede configurar la conectividad entre las máquinas virtuales de la misma manera que tenía la conectividad de red en el centro de datos de su empresa.

ventajas

El enfoque de elevación y cambio requiere pocos o ningún cambio de código en las aplicaciones existentes. Por lo tanto, el tiempo y el esfuerzo para la migración son mínimos.

Contras

Las aplicaciones migradas con el método de elevación y cambio seguirán ejecutándose en máquinas virtuales en Azure. Por lo tanto, heredarán todas las desventajas de las aplicaciones basadas en VM. No podrá implementar prácticas ágiles de DevOps con ellos.

Si bien las VM pueden tener menos gastos generales operativos que los servidores bare-metal, aún debe reforzar la seguridad, parchear, actualizar el software, etc.

Una vez que aprovisiona las máquinas virtuales, se le factura independientemente de si su aplicación consume todos los recursos asignados a las máquinas virtuales. Entonces, en general, es posible que esté pagando más por la infraestructura.

Migración de bases de datos 

Azure ofrece varias aplicaciones populares de código abierto bases de datos como PostgreSQL, MySQL, Apache Cassandra, etc., como servicios de base de datos administrados. También puede implementar bases de datos autogestionadas en Azure mediante máquinas virtuales y almacenamiento en bloque.

Azure se encarga de todo el trabajo de administración de la base de datos en las bases de datos administradas. En comparación con las bases de datos autoadministradas, las bases de datos administradas por Azure ofrecen una mejor escalabilidad y resiliencia. Por lo tanto, siempre debe intentar elegir bases de datos administradas por Azure en lugar de bases de datos autoadministradas.

Las bases de datos administradas admiten bastante bien el enfoque de elevación y cambio. No necesitan que cambies el código de la aplicación.

Contenedorización

Avanzando un paso más, puede migrar las aplicaciones existentes mediante contenedorización. Este método requiere cambios específicos en el nivel de código.

Una aplicación destinada a ejecutarse en máquinas virtuales o servidores bare-metal tiende a ser monolítica. Contendrá el código completo de la aplicación incluido en un solo paquete. Debe reconstruir y volver a empaquetar dichas aplicaciones en imágenes de contenedor.

Consideremos un ejemplo. Una aplicación de comercio electrónico tiene una función de búsqueda y una función de carrito de compras. Cuando un usuario busca un producto, la aplicación recibe la solicitud de búsqueda, ejecuta la búsqueda y envía los resultados. La aplicación recibe otra solicitud cuando el usuario agrega un producto de los resultados de búsqueda al carrito de compras.

Una aplicación típica es una colección de funciones que gestionarán estas solicitudes. Cuando se ejecuta en VM, una sola VM será responsable de administrar todas estas funciones.

Para contener una aplicación de este tipo, debe rediseñarla de acuerdo con los microservicios. Implica cambios considerables en el código. Pero, podría reutilizar la mayor parte de la lógica comercial ya implementada.

Azure tiene dos opciones para ejecutar aplicaciones en contenedores.

Servicio Azure Kubernetes (AKS) ofrece Kubernetes como un servicio gestionado. Puede aprovisionar un clúster de Kubernetes administrado e implementar su aplicación en él. Dado que Azure administra el clúster de Kubernetes, se encargará de la mayor parte del trabajo operativo relacionado con la administración del clúster. AKS le permite crear varios clústeres de Kubernetes, por lo que tiene la flexibilidad de separar lógicamente varias aplicaciones si es necesario.

Si su aplicación no necesita un servicio completo de Kubernetes, puede usar Instancias de contenedor de Azure (ACI) en cambio. ACI es un servicio que le permite implementar rápidamente contenedores sin aprovisionar un clúster de Kubernetes.

ventajas 

La contenedorización aumenta la agilidad. Puede implementar flujos de trabajo de desarrollo ágiles como CI/CD para aplicaciones en contenedores.

La contenedorización también hace que una aplicación sea más escalable. A diferencia de un centro de datos privado, no está limitado por los recursos de infraestructura en Azure. Puede ampliar y reducir dinámicamente su aplicación en función de la carga de tráfico real. Una aplicación en contenedores permite este tipo de escalado desde nuevos contenedores se puede girar en cuestión de segundos.

Contras

 La reconstrucción y la remodelación de la arquitectura requieren más tiempo y esfuerzo para la migración.

Herramienta de creación de contenedores de aplicaciones de Azure

 Azure ofrece una herramienta: Contenedorización de aplicaciones – para ayudar a los usuarios a contener y migrar sus aplicaciones web ASP.NET y Java existentes. Puede crear las imágenes del contenedor a partir de su infraestructura de aplicaciones existente y luego implementar la aplicación en AKS. La herramienta también se encarga de los archivos de configuración. Mueve el contenido estático como imágenes, archivos CSS, etc. a una ubicación de almacenamiento persistente en la implementación

Modernización para la arquitectura sin servidor

Funciones de Azure es un servicio informático sin servidor de Azure. Le permite escribir una aplicación como una colección de funciones controladas por eventos. Como su nombre lo indica, serverless hace que la infraestructura subyacente sea transparente. Azure se encarga de activar los recursos informáticos, aumentar la memoria y el almacenamiento, parchear y actualizar el tiempo de ejecución de la aplicación. Usted solo es responsable de escribir e implementar el código de la aplicación.

ventajas

 La arquitectura sin servidor elimina por completo la carga de administrar la infraestructura. Ofrece la verdadera agilidad de la nube. En la arquitectura sin servidor, el consumo de recursos es mínimo. Solo pagará por los recursos informáticos que se consumen para el manejo del tráfico. Una aplicación sin servidor inactiva no acumulará ningún costo informático.

Puede escalar una aplicación sin servidor al instante sin tener que preocuparse por activar máquinas virtuales o implementar nuevos pods y contenedores. En cuestión de segundos, una aplicación sin servidor puede escalar desde unos pocos cientos de usuarios para manejar solicitudes de millones de usuarios.

Contras

 Para migrar una aplicación existente a una arquitectura sin servidor, debe realizar una reescritura completa. Podrá reutilizar solo una pequeña parte del código de la aplicación anterior. Utilizará marcos específicos proporcionados por Azure para escribir una aplicación sin servidor para Azure. Por lo tanto, no podrá implementarlo en un proveedor de nube diferente sin volver a escribirlo.

estrategia de migración

Hemos descrito tres enfoques para migrar aplicaciones a Azure. Cada enfoque consecutivo requiere más esfuerzo pero ofrece más agilidad. Pero, el mejor enfoque siempre dependerá del contexto.

Aquí hay algunas consideraciones para elegir el enfoque de migración.

1. Costo

 Cada enfoque de migración consecutivo que describimos exige más costos de migración pero optimiza el costo de la infraestructura. Entonces, podrías calcular un TCO (costo total de propiedad) comparación para su aplicación para cada uno de estos enfoques para averiguar qué método tiene el costo óptimo.

2. Operaciones simplificadas

Puede estar interesado en simplificar las operaciones de TI al migrar a la nube. La contenedorización y la arquitectura sin servidor pueden ayudarlo con eso. Las aplicaciones sin servidor no requieren ninguna gestión de infraestructura, por lo que se vería relevado de todas las tareas operativas.

3. Agilidad

Los enfoques de contenedorización y sin servidor requieren más esfuerzo para la migración. Pero entregarán más agilidad. Podría mejorar su flexibilidad para adaptarse a las actualizaciones de la lógica empresarial, mejorar la escalabilidad y reducir el tiempo de comercialización.

4. Rendimiento de la aplicación

El modelo sin servidor ofrece la mejor rentabilidad. Pero puede que no sea la mejor opción para todas las aplicaciones.

La arquitectura sin servidor puede presentar una ligera latencia. Una aplicación sin servidor está basada en eventos. Por lo tanto, la aplicación está inactiva o inactiva cuando no hay tráfico. Cuando llega una solicitud, la aplicación tiene que despertarse del estado de suspensión. Esto podría ser problemático para aplicaciones con rendimiento en tiempo real.

Modernización incremental

Es posible que prefiera el enfoque de levantar y cambiar porque requiere el menor esfuerzo para la migración. Después de migrar, puede modernizar la aplicación gradualmente implementando partes seleccionadas de la aplicación en Funciones de Azure. El Puerta de enlace API de Azure puede implementar el enrutamiento de solicitudes entre la aplicación heredada y la nueva.

Este método puede modernizar gradualmente una aplicación basada en VM a una aplicación sin servidor.

Estos son solo algunos pasos y tecnologías que se pueden aplicar para la modernización de aplicaciones. Sabemos que no hay escapatoria a las exigencias de la transformación digital que demanda la economía global. La sostenibilidad y el crecimiento vertical comienzan con la innovación y, en este caso, la modernización de las aplicaciones es el camino.

es_CRES