14 ‐ Practical Scenario: On‐Premises to OCI Migration in the Airline Domain - SanjeevOCI/Study GitHub Wiki

Practical Scenario: On-Premises to OCI Migration in the Airline Domain

Scenario Overview

An airline company is running its flight booking system and customer management platform on on-premises infrastructure. The system includes:

  1. Frontend: A web-based booking portal built with Angular.
  2. Backend: Java-based microservices for flight search, booking, and payment processing.
  3. Database: Oracle Database for transactional data and PostgreSQL for analytics.
  4. File Storage: On-premises NAS for storing flight schedules, customer documents, and logs.
  5. Key Management: On-premises HSM for encryption keys.
  6. Challenges:
    • High operational costs for maintaining on-premises infrastructure.
    • Limited scalability during peak booking seasons.
    • Need for disaster recovery and global availability.

The airline decides to migrate its systems to Oracle Cloud Infrastructure (OCI) to leverage its cost-effectiveness, scalability, and native support for Oracle Database.

Migration Goals

  1. Scalability: Handle seasonal spikes in flight bookings.
  2. Cost Optimization: Reduce operational costs by moving to OCI.
  3. Disaster Recovery: Implement a robust DR solution across OCI regions.
  4. Modernization: Use OCI-native services for better performance and management.

Migration Steps

Step 1: Assessment and Planning

  1. Inventory Assessment:
    • Identify all on-premises components: frontend, backend, databases, and storage.
    • Evaluate dependencies between applications, databases, and external systems (e.g., payment gateways).
  2. Migration Strategy:
    • Use Rehost (Lift-and-Shift) for the backend and database to minimize downtime.
    • Use Replatform for the frontend by deploying it on OCI's Object Storage and CDN.
  3. Sizing and Cost Estimation:
    • Use OCI Sizing Tool to determine the required compute, storage, and network resources.
    • Estimate costs using the OCI Pricing Calculator.

Step 2: Infrastructure Setup in OCI

  1. Networking:
    • Create a VCN (Virtual Cloud Network) with subnets for frontend, backend, and database layers.
    • Configure Internet Gateway for public-facing components and NAT Gateway for private subnets.
    • Set up Security Lists or Network Security Groups (NSGs) to control traffic.
  2. Compute:
    • Provision OCI Compute Instances for the Java-based backend microservices.
    • Use Instance Pools for auto-scaling during peak traffic.
  3. Database:
    • Deploy Oracle Autonomous Transaction Processing (ATP) for the transactional database.
    • Use OCI Database Service for PostgreSQL to handle analytics workloads.
  4. Storage:
    • Use OCI Object Storage for storing flight schedules, customer documents, and logs.
    • Enable Object Lifecycle Policies to move infrequently accessed files to Archive Storage.
  5. Key Management:
    • Migrate encryption keys to OCI Vault for secure key management.

Step 3: Data Migration

  1. Database Migration:
    • Use Oracle Data Pump to migrate the Oracle Database to Autonomous Database.
    • Use OCI Database Migration Service for PostgreSQL migration.
  2. File Migration:
    • Use OCI Data Transfer Appliance for large file transfers from on-premises NAS to OCI Object Storage.
    • Alternatively, use OCI CLI or rclone for smaller datasets.
  3. Application Data:
    • Export application data and configurations to be re-imported into OCI.

Step 4: Application Migration

  1. Frontend:
    • Deploy the Angular-based frontend on OCI Object Storage (Static Website Hosting).
    • Use OCI CDN for faster content delivery globally.
  2. Backend:
    • Containerize the Java-based microservices using Docker.
    • Deploy the containers on OCI Container Engine for Kubernetes (OKE) for orchestration.
    • Use OCI Service Mesh for secure communication between microservices.

Step 5: Testing and Validation

  1. Functional Testing:
    • Test the application end-to-end to ensure all components work as expected.
  2. Performance Testing:
    • Simulate peak booking traffic to validate scalability.
  3. Security Testing:
    • Verify that all security policies (e.g., NSGs, IAM roles) are correctly configured.
  4. Data Validation:
    • Ensure data integrity after migration by comparing source and target datasets.

Step 6: Cutover

  1. DNS Update:
    • Update DNS records to point to the OCI-hosted frontend and backend.
  2. Monitoring:
    • Enable OCI Monitoring and Logging to track application performance and errors.
  3. Rollback Plan:
    • Keep the on-premises system operational during the initial cutover as a fallback.

Step 7: Disaster Recovery Setup

  1. Cross-Region DR:
    • Replicate the Oracle Autonomous Database and Object Storage to a secondary OCI region.
    • Use OCI Traffic Management Steering Policies for failover.
  2. Backup:
    • Enable OCI Backup Service for regular backups of databases and files.

Step 8: CI/CD Pipeline

  1. Code Repository:
    • Migrate the application code to OCI DevOps Code Repository or integrate with GitHub.
  2. CI/CD:
    • Set up a CI/CD pipeline using OCI DevOps for automated builds, tests, and deployments.

Outcome

  1. Scalability: The airline can now handle seasonal spikes in bookings with auto-scaling backend services.
  2. Cost Savings: Reduced operational costs by eliminating on-premises infrastructure.
  3. Global Availability: Improved user experience with OCI's global regions and CDN.
  4. Disaster Recovery: Robust DR setup ensures business continuity.
  5. Modernization: Leveraged OCI-native services for better performance and reduced management overhead.

Conclusion

This migration scenario demonstrates how an airline can move its critical systems from on-premises to OCI to achieve scalability, cost savings, and modernization while ensuring high availability and disaster recovery.