Implementation of Blue/ Green Environments
An on-prem the Client environment (A) is marked as Blue and the target AWS environment (B) is marked as Green. Once the target Green application is tested, monitored and stabilised, the traffic is moved from A to B, after which A will remain unused. The following are options for implementing Blue/ Green environments for the Client to AWS cloud migration, based on the application architectures and business needs:
- The Client current DNS routing OR AWS Route53: A Domain Name System (DNS) resolves a particular domain name (registered for the application) and routes the requests to the mapped IP address. AWS Route53 can route the traffic to specified AWS resource or to any resource external to AWS based on DNS configurations. It is even easier if the client has its present application on AWS. The new Green environment (B) is rolled out with AWS Opsworks/Sentinel based on the automated scripts (templates) and the associated software. This is thoroughly tested and once stabilised, the traffic can be gradually moved from A to B. The proportion of the traffic can also be controlled at the Route53 (e.g. divert all the test traffic to the B, requests from a specific geography, etc.). Finally A can be disconnected and all the traffic routes through to the new AWS Green environment (B).
- Load Balancer: The same can be achieved with the LoadBalancer where the new AWS environment is added as an additional node to the current LoadBalancer with the weighted distribution. (AWS Elastic loadbalancer can also be used). This is well suited in the case where the Blue environment has to be brought back functionally, in case of Green failure with minimal recovery time, as the Load balancer is already up and running.
- AWS Elastic Beanstalk environment swap: Elastic Beanstalk is a PaaS service of AWS that rolls out the environments with the predefined configurations and software, and also runs multiple versions of application environments. Once the blue/green environments are in place, the EBS-Swap feature can be used with zero-down-time, where EBS console facilitates to swap the A and B URLs. This is applicable for those which are already deployed on AWS.
- EC2 and Elastic IP: An Elastic IP is a static IP address that can be assigned to for any EC2 instance we own. We can reassign the IP to another EC2 instance by a simple API call. In applying Blue/Green cutover, the new EC2 instance with the tested application is assigned with the Elastic IP of the Blue environment. This is applicable for those which are already deployed on AWS.
Choosing the right option is possible following a thorough study of the Business application, data sensitivity, workarounds, downtime, data volume exchanged amongst the interfaces, etc.
An example of a complex Migration with Blue-Green approach, based on IBM Maximo (customised), is depicted below:
However, some applications which like desktop based, or Modelling tools and the Blue-Green approach does not fit. In this case, the applications are migrated on AWS, and the users are communicated to access the new URL to access the applications.
Data Synchronisation between On-prem and AWS
The following are possible scenarios for the Data migration and Synchronisation are:
Simple Migration: This is the migration approach for less critical applications and data volume, which can be shut down for 1 to 3 days. In this approach, all the data in the source database is extracted, loaded and thoroughly tested in the target database. Once all the validations are passed, the application can point to the database on AWS. In this case, the migrated database is in sync with that of on-premises version.
Migration with Minimal Downtime: This is a two-step process, where the application will have minimal down time. The data is backed up and restored in the target Database, after which the database is thoroughly tested. After the restoration, any changes made to the source database, are replicated in the target database until the two databases are synchronised and the application points to the destination database, thereby the source database is shutdown/decommissioned. The data is migrated with either the Native Migration tools of the respective Databases or AWS Data Migration Service (DMS). Also, Replication is found as a feature of Native tools as well as also AWS DMS.