Mindtree helped one of our long standing customer to achieve 84% cost savings on infrastructure by migrating to AWS. This article talks about what was the migration about, how did we go about it and couple of learnings out of this endeavour by using the "Lift-Tinker-Shift" methodology of Cloud Migration.
The Customer had IBM WebSphere Application Server 7.0, IBM HTTP Server, Oracle 12c RAC based three tier Web Application in shared environment. The Customer was interested in moving applications one by one out of the shared infrastructure into a Cloud based platform. The end goal was to leverage all the benefits of moving to the Cloud i.e Cost Optimization, Reliability, Performance Efficiency, Security, Operational Excellence.
We advised the customer to migrate from WebSphere Application Server 7.0 to TomEE V7.0, Oracle 12c RAC to Amazon Aurora Postgres, IBM JDK to Open JDK.
Steps in migration:
1. Migrate the Database - Use of AWS Database Migration Service
Oracle 12C was migrated to Aurora PostgreSQL using AWS Database migration service. We used Schema Conversion Toolkit (SCT) to get schema definition files corresponding to the Aurora Postgres.
2. Tweak the web application
Refactor the application to use a Custom Content Rendering feature instead of using Adobe Experience Manager and also got rid of WebSphere DynaCache by use Custom Cache component.
3. Test the tweaked application in standalone environment
We ensured that the modified application worked fine with the new tech stack.
4. Set-up the environment in AWS
We deployed a 3 Tier Web application across two availability zones to keep it highly available and scalable. The Web Tier was front ended by an Application Load Balancer and between the Web Tier and Application Server Tier there was an internal Application Load Balancer. Aurora Postgres was deployed in a single AZ with no read replica, since the RTO for the application allowed the time for recovery.
“If you have an Amazon Aurora Replica, in the same or a different Availability Zone, when failing over, Aurora flips the canonical name record (CNAME) for your DB Instance to point at the healthy replica, which is in turn is promoted to become the new primary. Start-to-finish, failover typically completes within 30 seconds."
If you do not have an Amazon Aurora Replica (i.e. single instance), Aurora will first attempt to create a new DB Instance in the same Availability Zone as the original instance. If unable to do so, Aurora will attempt to create a new DB Instance in a different Availability Zone. From start to finish, failover typically completes in under 15 minutes." From the FAQ
5. Set-up CI/CD processes
Following tools were used:
- GitHub : Version Control System tool
- Jenkins – Open Source Continuous Integration tool which can also help in Continuous Delivery.
- JFrog Artifactory – Binary Repository Manager
- SonarQube – Java Source Code analysis
- Veracode - Java Source code security analyzer
6. Set-up Logging and Monitoring
Splunk was used for Logging and Monitoring of the Web Server and App Server logs.
7. Test the application
Selenium scripts were used for automated functional testing and Apache JMeter was used for Performance Testing.
- SCT tool while migrating the schema ignored the views that were based on aliases instead of column names.
- SCT tool was not able to handle nvarchar2_array type encountered during stored procedure conversion. These types were missing in Aurora Postgres schema. These were replaced by Text data type to make the stored procedures work.
The customer was able to achieve a cost savings of about 84% per year which primarily included licensing costs of Oracle 12c RAC, WebSphere, Solaris and AIX.