Introduction
Client is a Fortune 50 company and is one of the largest Telecom service providers in the US and offers multiple products and services to consumers and enterprises. Being a large enterprise, the IT foot-print is huge and there is a plethora of applications both COTS and internally developed. The vision of the Business and IT leadership teams is to migrate applications from Data centers to public cloud infra-structure in a phased manner. Each business portfolio and the associated IT operations have chalked out a plan to migrate application workloads to AWS Cloud in 2 to 3 years’ time.
Current System overview:
Each of the business units had undertaken a DevOps transformation exercise prior to migrating applications to the cloud through a structured enablement process. There were about 18 Java/.NET applications with DB2, MS SQL and Oracle Databases, ESSBase, WebLogic on RHEL/Windows environment. There were about 300+ VMs to be migrated along with the Databases.
Key Business/Systems requirements:
“Migrate the DC to AWS Cloud.”
The Client has enumerated the following requirements for mandatory compliance while designing an approach to migration.
• Automated Server Provisioning.
• Software Installation & Configuration (SSO, Java, IIS, IBM MQ, DB2, Oracle, OBIEE, ODI, etc.)
• Automated Code Deployment
• Continuous Monitoring
• Scheduled Backup implementation
Solution Considerations
DC/infra consolidation
Primary objective was to migrate applications from physical Data centers to optimize TCO and utilization of resources, so that the scale can happen as the business grew. The on-premise legacy applications were robust and must perform exactly in the same fashion in the public cloud. Some of the key technical considerations were related to end to end automation of the different environments: Development/UAT and Production.
Application modernization
The client after a detailed assessment of the efficacy of modernization and its impact on the migration timelines and investments and decided to adopt a “lift and shift” approach. The diversity of tech stack, time pressures and the complexity of licensing of COTS, the decision to use a model of IaaS looked prudent and manageable.
Choice of Migration approach
The proposed approach was to use DevOps led migration strategy so that the end to end automation of creating different environments is streamlined as part of the migration process. Some of the salient points of the proposed architecture (ref. diagram) are:
• Client Specific Global AWS AMI for SQL,
• End to End Pipeline using ICP (Infrastructure Certification Pipeline) Process using Cloud Formation, Ansible,
Power Shell and Shell Scripting
• AMI backup/retention, DB backup/retention, App related files to S3
• S/W’s & App Configuration Backup in AWS Snapshot.
• Firewall Management
• AWS Cleanup for Unused Volumes, AMI’s, Instance, Snapshot to avoid Cost
• Inventory Management
Design Considerations:
Architecture
Performance
The applications when migrated to AWS environment must meet the following criteria to be validated:
Dev /SIT Environment:
• Base AMI Web/App [ < 3 Hours]
• Base AMI DB [ < 4 Hours]
• Initial Base AMI [ UAT Environment:
• Base AMI Web/App [ < 3 Hours]
• Base AMI DB [ < 4 Hours]
• Pre-Baked AMI [ Prod Environment:
• Base AMI Web/App [ < 3 Hours]
• Base AMI DB [ < 4 Hours]
• Pre-Baked AMI [
Implementation Phase:
Timelines
The project started in late 2017 and is expected to complete by 2020 when the DC will be retired in favor of AWS infra-structure with production servers. All the three environments are running on Non-prod AWS infra-structure and the migration process has been smooth.
As of now, all the 300+ VMS running 18 applications have moved to Pre-Prod AWS environment with most of the solution considerations having been met. There is a process of cost optimization that is being done, after tweaking performance issues over the past 5 months.
Team structure
Apart from the business and IT stakeholders of the company who played an active role in the planning phase, the migration tasks were completed by a team of 4 people led by a seasoned architect. All the members of the team were AWS certified at Professional level and had 5 years of Cloud experience on an average.
Use of DevOps tools
Jira, Confluence, Artifactory and Jenkins were used in the process of migration extensively.
Validation – Project closure (Lessons learnt)
The project team worked closely with the enterprise IT team at the client premise and resolved some of the issues that impacted delivery. The client is a large enterprise and the application is business critical
The team faced certain challenges due to:
• Access issues,
• Certification issues,
• Software installation/Configuration issues,
• SSO Issues.
The current phase was completed in December 2017, but there is further work being done to optimize the deployment.
Operations and Optimization
Some of the key areas for focus in the operations phase are:
✓ Reserved Instance usage
✓ Horizontal scaling based on OS resources
✓ AWS health-checkup to clean-up instances, AMIs, volumes, snapshots
✓ Schedule stop/start instances based on triggers
The production deployment would consider DR implementation on AWS, as the current configured like AWS as DR for the DC.
The typical deployment architecture is given below:
Deployment architecture
AWS services used:
The project team had agreed at the planning phase to use a set of DevOps tools and the AWS services to complete the migration.
VPC, EC2, S3, Lambda, CloudWatch, Autoscaling, ECS, RDS, CloudTrail, IAM and ACM.
Security considerations and implementation
The focus on security was present right through the process of migration and the enterprise has clear guidelines around this and the project team implemented them.
✓ Hardened Image provided by Enterprise AWS AMI Team
✓ Enabled with SSO login
✓ VPC design, security groups, network access control were implemented with the help of IT team at the client place.
✓ Application specific IAM Policy which applies in EC2, S3, RDS in all resources
✓ TLS Enabled from application end
✓ Encryption of data using the proprietary tool of the client
Business benefits of the migration:
The migration project is envisaged to give the following benefits to the client in a virtual data center environment as and when the physical DC is shut down
Infrastructure Benefits:
• Automate approach for App/Web/DB
• Scalability
• Centralized Login mechanism
• Automated Backup and restoration strategy
• Pro-active Monitoring and remediation
Deployment Benefits:
• No downtime for deployments
• No Maximum resource
• Frequent deployment
• No week end deployments