Migration of VIS Legacy Application to AWS Cloud
United States Citizenship and Immigration Services (USCIS) is a component of the United States Department of Homeland Security (DHS). The Verification Information System (VIS) program verifies the eligibility of aliens requesting benefits within US. The VIS program supports Employment Eligibility (E-Verify) and Systematic Alien Verification for Entitlements (SAVE) programs. E-Verify, SAVE and VIS applications are typical n-tier legacy internet systems that interact with many external agencies to verify alien data. Most of these applications are housed in a typical data center and reside on multiple web and app servers. As part of the modernization effort, the customer wants to migrate the existing infrastructure to AWS cloud.
Our ApproachWe identified all the tasks required for a Minimum Viable Product (MVP) release and recorded them in LeanKit. A core team of Subject Matter Experts with in-depth knowledge of the entire VIS application including its integration with various external partners (both modernization and existing) was assembled together. Our prior experience on practicing Agile and DevOps methodology helped us get up to speed within a few days as per the expectations of our customer. We set up a tiger team of AWS Certified DevOps engineers and started to brainstorm both internally and with our customers. We had a few challenges as some of the COTS products that we currently use in our Data Center were not supported or came with a huge price in AWS. COTS like Solaris OS, Documentum, TFS, Telerik Test Studio, HPE Load Runner and OAS 10g. With our customer’s emphasis on Open Source technology, some of the substitutes were a no-brainer. We replaced Solaris OS with Amazon Linux, Documentum with S3 bucket, TFS with GitHub and Jenkins, Telerik Test Studio with Selenium and SpecFlow, HPE Load Runner with JMeter and OAS 10g was upgraded to OAS 11g on Amazon Linux. Currently our Oracle 11g database is running on Solaris. We had difficulty running Oracle as an RDS service and so we decided to port Oracle 11g on to Linux RHEL. There are a few reports that are accessed by our GUI that relies on data from not just our OLTP but also OLAP database. The decision was made by the customer not to move OLAP database over to cloud and so we had to create materialized views within OLTP database and incrementally refresh nightly so that the reports can still continue to function seamlessly.
For Minimum Viable Product (MVP), the choice was made to adopt hybrid cloud approach as some of the external partners were not ready to transfer files to the new destination in AWS. We decided to follow best practices and script all the infrastructure as code. Blue green deployment practice was discussed. We have some challenges here to move towards “zero downtime” during deployment because of code buried in the app tier for message queue processing. We decided to create Chef cookbooks that would launch Cloud Formation to create EC2 instances. The Chef cookbooks are being auto triggered through Jenkins jobs. We also are updating our deployment Powershell scripts to compile once and deploy multiple times on various environments. The code gets compiled once and the deployment artifacts are stored in Nexxus repository. Jenkins jobs then runs the deployment scripts which in turn injects environmental variables and encrypts them and deploys the code to web, app and database servers on various stacks.
ConclusionWe were given six months to complete all the above tasks and with a few hiccups and learning along the way, we are on target to successfully migrate one of the most critical legacy application to AWS cloud.