En este artículo se describe un enfoque de migración para replatar las cargas de trabajo de AIX en la nube. Puede usar Azure Functions para una arquitectura sin servidor o usar Azure Virtual Machines para conservar un modelo con servidor.
Considere una estrategia de migración de replataforma para cargas de trabajo de AIX para maximizar la rentabilidad de la inversión (ROI) al migrar aplicaciones heredadas a Azure. Las migraciones de replataforma requieren cambios mínimos, pero ofrecen ventajas nativas de la nube similares a una migración de refactorización.
Entre las ventajas de una migración de replataforma se incluyen:
- Reducción del costo total de propiedad (TCO).
- Agilidad empresarial mejorada.
- Resistencia operativa mejorada.
Descargue un archivo Visio de esta arquitectura.
Este flujo de trabajo corresponde a la arquitectura anterior.
Las solicitudes de usuario y las integraciones de API entrantes se transfieren a Azure Application Gateway en TCP/443 (HTTPS), que proporciona una funcionalidad de firewall de aplicaciones web (WAF). Application Gateway envía las solicitudes, como solicitudes de proxy inverso, a varios servicios hospedados en Red Hat JBoss Enterprise Application Platform (EAP).
Java Web Services interroga la base de datos de Oracle (TCP/1521). El tiempo de respuesta de la solicitud web sincrónica es inferior a 50 milisegundos (ms).
Una solicitud asincrónica, como programar una tarea por lotes, coloca un registro en una tabla de base de datos que actúa como una cola dentro del nivel de aplicación.
Nota
En el futuro, Azure Queue Storage reemplazará la tabla de base de datos, por lo que siempre puede tener acceso a los trabajos de análisis en ejecución.
El trabajo cron, escrito en el script de KornShell (ksh), se traslada a Bash y se ejecuta en un servidor de Red Hat Enterprise Linux (RHEL) independiente en Azure Virtual Machine Scale Sets. El trabajo cron se ejecuta cada 15 minutos, incluido el inicio del sistema, para consultar la cola en la base de datos de Oracle. Los trabajos se ejecutan de uno en uno por host. Virtual Machine Scale Sets paraleliza trabajos de análisis de larga duración. Esta solución no requiere el procesamiento por lotes fuera de horas punta para limitar el efecto sobre el rendimiento del sistema durante las horas de oficina.
Azure Communication Services envía alertas por correo electrónico a través de la herramienta Azure CLI (docs). Identidades administradas asignadas por el sistema de Azure, como
az login --identity, autenticar la máquina virtual (VM).Los resultados del trabajo de análisis van a un recurso compartido de Azure Files a través de SMBv3 seguro (TCP/445), que también usa identidades administradas asignadas por el sistema.
Microsoft Entra ID elimina la confianza basada en la red y proporciona identidades administradas asignadas por el sistema, lo que mejora la seguridad.
Azure App Service elimina la necesidad de administrar un sistema operativo y un servidor, lo que aumenta la eficiencia operativa y la agilidad empresarial.
Application Gateway es un servicio totalmente administrado y escalable que proporciona firewall de aplicaciones web y funcionalidad de proxy inverso.
Azure Files proporciona informes de datos que se publican a través de un servicio administrado.
Azure Functions es una plataforma de proceso sin servidor controlada por eventos que se usa para desarrollar código de forma eficaz en el lenguaje de programación especificado.
La base de datos de Oracle y los nodos de análisis de SAS usan una
Azure Virtual Machines. Azure Compute Gallery compila y almacena imágenes para los nodos de análisis de SAS y la base de datos de Oracle. Hay dos galerías: una en la región primaria y otra en la región de recuperación ante desastres.
Communication Services envía correos electrónicos con una utilidad CLI. Este servicio reemplaza el
mailxcomando en AIX.
Una alternativa es una arquitectura completa con servidor que conserva todos los componentes de middleware tal como está.
Esta solución es similar a la arquitectura original, que cumple con un mandato similar al que operan muchas organizaciones de TI. Esta solución alternativa también cuesta lo mismo que la arquitectura original, pero no proporciona las ventajas que proporciona la arquitectura de replataforma. Por ejemplo:
Ahorros en licencias: la solución alternativa conserva WebSphere y agrega más nodos de RHEL.
Eficiencia operativa: la solución alternativa conserva el mismo número de servidores que mantener.
Agilidad empresarial: con la solución alternativa, los informes permanecen limitados a las noches solo sin escalado automático, análisis todo el día.
Elija un modelo sin servidor o con servidor en función de la portabilidad de las aplicaciones existentes y la preferencia de flujo de trabajo y la hoja de ruta tecnológica del equipo.
Al igual que la arquitectura original, la arquitectura de replataforma tiene una base de datos de Oracle, pero se replata a un sistema operativo RHEL en Azure Virtual Machines. Para el Azure App Service totalmente administrado en la arquitectura de replataforma, Red Hat JBoss EAP reemplaza la aplicación WebSphere Java.
Descargue un archivo Visio de esta arquitectura.
Este flujo de trabajo corresponde a la arquitectura anterior.
Las solicitudes de usuario y las integraciones de API entrantes se transfieren al equilibrador de carga F5 local en TCP/443 (HTTPS) y, a continuación, invierten el proxy a varios servicios web de Java hospedados en WebSphere de IBM.
Java Web Services interroga la base de datos de Oracle a través de TCP/1521. En la mayoría de los casos, el tiempo de respuesta de la solicitud web sincrónica es inferior a 1 segundo (s), pero más de 300 ms según las pruebas y el análisis de weblog.
Una solicitud asincrónica, como programar una tarea por lotes, coloca un registro en una tabla de base de datos de Oracle que actúa como una cola dentro del nivel de aplicación.
Un trabajo cron, escrito en script ksh, consulta la cola en la base de datos de Oracle y recoge los trabajos de análisis de SAS que se van a ejecutar. El cliente debe realizar el procesamiento por lotes durante la noche para limitar el efecto en el rendimiento del sistema durante el horario comercial.
Las alertas por correo electrónico notifican a los usuarios y administradores a través de SMTP (TCP/25) los tiempos de inicio y finalización del trabajo y los resultados de éxito o error.
Los resultados del trabajo de análisis van a una unidad compartida a través de NFS (TCP+UDP/111,2049) para la recopilación a través de SMBv3 (TCP/445).
Esta arquitectura original evalúa una aplicación Java monolítica que se ejecuta en IBM WebSphere y evalúa el procesamiento por lotes de SAS que orquestan los scripts ksh. Una base de datos de Oracle que se ejecuta en un host de AIX independiente admite las cargas de trabajo de ambas aplicaciones.
Considere la carga de trabajo original que se ejecuta en AIX para determinar si una estrategia de migración de replataforma se adapta a su presupuesto de migración. Trabaje hacia atrás desde los resultados deseados para determinar una ruta de migración transformadora centrada en la aplicación a la nube. Asegúrese de que la mayoría del código de la aplicación esté escrito en un lenguaje que admita servicios nativos en la nube, como arquitecturas sin servidor y orquestadores de contenedores.
En este escenario, Tidal Accelerator analizó el código de la aplicación Java y determinó su compatibilidad con JBoss EAP. Al principio del proyecto, Azure Pipelines o GitHub Actions se usa para recompilar la aplicación como piloto. A continuación, el cliente puede establecer agilidad a partir de canalizaciones de integración continua y entrega continua (CI/CD) en un servicio administrado, como Azure App Service. El cliente no puede obtener esta funcionalidad en su entorno local de WebSphere.
En este ejemplo se conserva la base de datos de Oracle en esta fase debido a la cantidad de PL/SQL que detectó Tidal Accelerator durante la fase de análisis. Los futuros esfuerzos del cliente incluyen la migración de la base de datos de Oracle en RHEL a una base de datos de Azure Database for PostgreSQL totalmente administrada, la adopción de Azure Queue Storage y la ejecución de trabajos SAS totalmente a petición. Estos esfuerzos se alinean con la hoja de ruta tecnológica del cliente, los ciclos de desarrollo y la dirección empresarial que se determinó en la entrevista de Application Owner. En la captura de pantalla siguiente se muestra una entrevista en Tidal Accelerator.
Puede usar esta arquitectura para las migraciones de AIX a Azure que abarcan análisis de datos, administración de relaciones con el cliente (CRM), capas de integración del sistema central en una configuración de nube híbrida y otras soluciones de software personalizadas en escenarios de administración de inventario y almacenamiento.
Puede usar esta arquitectura para cargas de trabajo de aplicaciones tradicionales con tecnologías como:
- Oracle Siebel
- Oracle E-Business Suite
- SAS
- IBM BPM
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.
Esta arquitectura usa Azure Site Recovery para replicar las máquinas virtuales Azure de la base de datos en una región de Azure secundaria para una rápida conmutación por error y recuperación ante desastres si falla una región de Azure completa. De forma similar, Azure Files usa almacenamiento con redundancia geográfica.
Los nodos de procesamiento de datos usan discos administrados con redundancia de zona (RA-ZRS) para proporcionar resistencia durante las interrupciones de zona. Durante la interrupción de toda una región, puede volver a aprovisionar nodos de procesamiento de datos en una región diferente a partir de su imagen de máquina virtual dentro de la Azure Compute Gallery redundante.
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.
Esta arquitectura adopta un enfoque de infraestructura inmutable para las implementaciones de aplicaciones y examina de forma proactiva el código en las canalizaciones de Azure para ayudar a proteger los datos confidenciales en producción. Incorpora un enfoque de desplazamiento izquierdo para el examen de seguridad y ejecuta con frecuencia implementaciones habilitadas para canalización de CI/CD para mejorar el cumplimiento actual del software y reducir la deuda técnica.
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.
Esta solución elimina tantos componentes con servidor como sea posible, lo que reduce los costos operativos en más del 70 %. Esta arquitectura reduce los costos de licencias de proceso y software.
La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.
El equipo de productos se admite en Azure, lo que reduce el tiempo de resolución de los tickets de incidente notificados. Además, el recuento de rebotes de tickets o el número de tickets asignados de un grupo a otro es cero porque un equipo de producto admite toda la pila de aplicaciones en Azure.
La eficiencia del rendimiento es la capacidad que tiene la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan realizado sobre ella. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.
El cliente adopta Azure App Service siempre que sea posible para que pueda escalar verticalmente y escalar horizontalmente automáticamente sus requisitos de proceso para alinearlos con la demanda de la aplicación. Esta elasticidad garantiza un rendimiento coherente de la aplicación durante las horas punta. Este enfoque también es rentable.
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
Richard Berry| Responsable de programa senior
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Para obtener más información sobre el uso de una solución de Tidal Accelerator, póngase en contacto con el equipo de Microsoft Tidal Cloud.
Para más información sobre la migración a Azure, póngase en contacto con el equipo de ingeniería de migraciones heredadas.