This article describes a migration approach to replatform your AIX workloads to the cloud. You can use Azure Functions for a serverless architecture or use Azure Virtual Machines to retain a serverful model.
Consider a replatform migration strategy for AIX workloads to maximize your return on investment (ROI) when you migrate legacy applications to Azure. Replatform migrations require minimal changes but deliver cloud-native benefits that are similar to a refactor migration.
The benefits of a replatform migration include:
- A reduced total cost of ownership (TCO).
- Improved business agility.
- Improved operational resiliency.
Architecture (replatformed)
Download a Visio file of this architecture.
Workflow
This workflow corresponds to the preceding architecture.
User requests and inbound API integrations transfer to Azure Application Gateway on TCP/443 (HTTPS), which provides a web application firewall (WAF) functionality. Application Gateway sends the requests, as reverse proxy requests, to various services that are hosted on Red Hat JBoss Enterprise Application Platform (EAP).
Java Web Services interrogates the Oracle database (TCP/1521). The synchronous web request response time is less than 50 milliseconds (ms).
An asynchronous request, such as scheduling a batch task, places a record in a database table that acts as a queue within the application layer.
Note
In the future, Azure Queue Storage will replace the database table, so you can always have access to running analysis jobs.
The cron job, written in KornShell (ksh) script, is ported to Bash and runs on a separate Red Hat Enterprise Linux (RHEL) server in Azure Virtual Machine Scale Sets. The cron job runs every 15 minutes, including on system startup, to query the queue in the Oracle database. Jobs run one at a time per host. Virtual Machine Scale Sets parallelizes long-running analysis jobs. This solution doesn't require off-peak batch processing to limit the effect on system performance during business hours.
Azure Communication Services sends email alerts via the Azure CLI tool (docs). Azure system-assigned managed identities, such as
az login --identity, authenticate the virtual machine (VM).The analysis job results go to an Azure Files share via secure SMBv3 (TCP/445), which also uses system-assigned managed identities.
Components
Microsoft Entra ID eliminates network-based trust and provides system-assigned managed identities, which improves security.
Azure App Service eliminates the need to administer an operating system and server, which increases operational efficiency and business agility.
Application Gateway is a fully managed and scalable service that provides web application firewall and reverse proxy functionality.
Azure Files provides data reports that are published via a managed service.
Azure Functions is an event-driven, serverless compute platform that is used to efficiently develop code in the specified programming language.
An Azure VM is used by the Oracle database and SAS analysis nodes.
Azure Compute Gallery builds and stores images for the Oracle database and SAS analysis nodes. There are two galleries: one in the primary region and one in the disaster recovery region.
Communication Services sends emails with a CLI utility. This service replaces the
mailxcommand on AIX.
Alternatives
An alternative is a complete serverful architecture that retains all middleware components as is.
This solution is similar to the original architecture, which fulfills a like for like mandate under which many IT organizations operate. This alternative solution also costs about the same as the original architecture but doesn't provide the benefits that the replatformed architecture provides. For example:
Licensing savings: The alternative solution retains WebSphere and adds more RHEL nodes.
Operational efficiency: The alternative solution retains the same number of servers to maintain.
Business agility: With the alternative solution, reporting remains limited to nights only with no autoscaling-powered, all-day analysis.
Scenario details
Choose a serverless or serverful model depending on the portability of your existing applications and your team's workflow preference and technology roadmap.
Like the original architecture, the replatformed architecture has an Oracle database, but it's replatformed to a RHEL operating system on Azure Virtual Machines. For the fully managed Azure App Service in the replatformed architecture, Red Hat JBoss EAP replaces the WebSphere Java application.
Architecture (original)
Download a Visio file of this architecture.
Workflow
This workflow corresponds to the preceding architecture.
User requests and inbound API integrations transfer to the on-premises F5 load balancer on TCP/443 (HTTPS) and then reverse proxy to various IBM WebSphere-hosted Java Web Services.
Java Web Services interrogates the Oracle database via TCP/1521. In most cases, the synchronous web request response time is less than 1 second (sec) but more than 300 ms according to testing and weblog analysis.
An asynchronous request, such as scheduling a batch task, places a record in an Oracle database table that acts as a queue within the application layer.
A cron job, written in ksh script, queries the queue in the Oracle database and picks up SAS analysis jobs to run. The customer must do batch processing at night to limit the effect on system performance during business hours.
Email alerts notify users and administrators via SMTP (TCP/25) of the job start and completion times and success or failure results.
The analysis job results go to a shared drive via NFS (TCP+UDP/111,2049) for collection via SMBv3 (TCP/445).
Scenario details
This original architecture evaluates a monolith Java application that runs on IBM WebSphere and evaluates batch processing from SAS that ksh scripts orchestrate. An Oracle database that runs on a separate AIX host supports both application workloads.
Consider your original workload that runs on AIX to determine if a replatform migration strategy suits your migration budget. Work backwards from your desired outcomes to determine a transformative, application-centric migration path to the cloud. Ensure that most of your application code is written in a language that cloud-native services, such as serverless architectures and container orchestrators, support.
In this scenario, Tidal Accelerator analyzed the Java application code and determined its compatibility with JBoss EAP. Early in the project, Azure Pipelines or GitHub Actions is used to rebuild the application as a pilot. The customer can then establish agility from continuous integration and continuous delivery (CI/CD) pipelines in a managed service, such as Azure App Service. The customer can't get this capability in their on-premises WebSphere environment.
This example retains the Oracle database in this phase because of the amount of PL/SQL that Tidal Accelerator discovered during the analysis phase. The customer's future endeavors include migrating from the Oracle database on RHEL to a fully managed Azure Database for PostgreSQL database, adopting Azure Queue Storage, and running fully on-demand SAS jobs. These efforts align with the customer’s technology roadmap, development cycles, and the business direction that was determined in the Application Owner interview. The following screenshot shows an interview in Tidal Accelerator.
Potential use cases
You can use this architecture for AIX to Azure migrations that cover data analytics, customer relationship management (CRM), mainframe integration layers in a hybrid cloud configuration, and other custom software solutions in inventory and warehouse management scenarios.
You can use this architecture for traditional application workloads with technologies like:
- Oracle Siebel
- Oracle E-Business Suite
- SAS
- IBM BPM
Considerations
These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that can be used to improve the quality of a workload. For more information, see Microsoft Azure Well-Architected Framework.
Reliability
Reliability ensures your application can meet the commitments you make to your customers. For more information, see Design review checklist for Reliability.
This architecture uses Azure Site Recovery to mirror the database Azure VMs to a secondary Azure region for quick failover and disaster recovery if an entire Azure region fails. Similarly, Azure Files uses geo-redundant storage.
Data-processing nodes use zone-redundant (RA-ZRS) managed disks to provide resiliency during zone outages. During an entire region outage, you can reprovision data-processing nodes in a different region from their VM image within the redundant Azure Compute Gallery.
Security
Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Design review checklist for Security.
This architecture adopts an immutable infrastructure approach to application deployments and proactively scans code in Azure pipelines to help secure sensitive data in production. It incorporates a shift left approach for security scanning and frequently runs CI/CD pipeline-enabled deployments to improve software current adherence and reduce technical debt.
Cost optimization
Cost optimization is about looking at ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Design review checklist for Cost Optimization.
This solution removes as many serverful components as possible, which reduces operating costs by more than 70%. This architecture reduces compute and software licensing costs.
Operational excellence
Operational excellence covers the operations processes that deploy an application and keep it running in production. For more information, see Design review checklist for Operational Excellence.
The product team supports themselves in Azure, which reduces the resolution time for reported incident tickets. Additionally, the bounce count for tickets, or the number of tickets that are assigned from one group to another, is zero because one product team supports the entire application stack in Azure.
Performance efficiency
Performance efficiency is the ability of your workload to scale to meet the demands placed on it by users in an efficient manner. For more information, see Design review checklist for Performance Efficiency.
The customer adopts Azure App Service where possible so they can automatically scale up and scale out their compute requirements to align with application demand. This elasticity ensures consistent application performance during peak times. This approach is also cost efficient.
Contributors
This article is maintained by Microsoft. It was originally written by the following contributors.
Principal author:
Richard Berry| Sr. Program Manager
To see non-public LinkedIn profiles, sign in to LinkedIn.
Next steps
For more information about using a Tidal Accelerator solution, contact the Microsoft Tidal Cloud team.
For more information about migrating to Azure, contact the Legacy Migrations Engineering team.