Cloud migration and application modernization strategies have become more critical and complex when attempting to keep pace with business requirements and adapting to technology shifts. In order to determine the right strategy, a collaborative effort across multiple teams (IT, CyberSecurity, Application Developers, DevOps, Business etc.,) is required.
A key component of the strategy is to figure out the cloud provider tools needed for application migration. AWS offers many of these tools such as AWS Cloud Formation templates, however, these will require additional stitching to work for end to end solutions. This undertaking is certainly overwhelming and time consuming for the deployment team.
This blog will provide a high-level overview of how Cloudshell native integration with AWS can easily support a re-platform strategy for legacy on-premise applications into the AWS cloud.
Step 1 – Deploy CloudShell in AWS
The initial step is to deploy Cloudshell in your AWS cloud. This is accomplished by using a AWS Cloud Formation template. The deployment process will create a new management VPC and deploy four EC2 instances that facilitate various functions for CloudShell. These functions enable the creation of VM’s, VPC, executing automation and accessing VM consoles. The Quali Server (QServer) can also be installed on-premise and the other three components within AWS.
Step 2 – Connect CloudShell to your AWS account
The next step is to create a new cloud provider resource in Cloudshell that connects it to your AWS account. In this example, AWS EC2 is selected as the cloud provider resource and a descriptive name such as “AWS West Region” is provided.
Additional information is required to complete the connectivity requirements. The following resource detail form provides a simple way to enter the specific details pertaining to AWS connectivity and deployment
Step 3 – Add Your Apps and Services
The Re-Platform strategy for migrating legacy applications requires a combination of native AWS application templates, services, and integration with 3rd party service components. This requirement is supported within CloudShell by providing a cataloging capability for easy selection of components. In order to build the catalog, you have a number of options on how you want to access the resources. Pre-packaged Amazon Machine Images (AMI’s) are available by referencing their AMI ID’s as one option of building your catalog. Another option is to define the API endpoint of the native cloud service. Either method can be used to define the object and associate a category as highlighted below for easy access.
Step 4 – Model Blueprints and Deploy Sandboxes
Once the catalog objects are defined, they can be introduced onto the blueprint canvas with a simple drag, drop and connect activity to easily model your application environment. The beauty of this approach is that you don’t have to worry about the underlying infrastructure definition since a domain administrator has already established that in the previous step. This blueprint design process is illustrated below with a AWS cloud-native Aurora database, pre-packaged AMI Drupal CMS application, 3rd party Nginx load balancer and a Software-as-a-Service Blazemeter load generation tool.
Once the blueprint is completed, the designer tests it and publishes it into the self-service catalog. It is now ready for consumption by the test engineer. The test engineer will select the blueprint, fills in some input parameters if needed, and with a simple click deploys it. The built-in orchestration does the heavy lifting.
Once the blueprint is deployed, the sandbox is active and now you’re in a position to access individual components as warranted or start the value added services such as starting a Blazemeter load and performance test.
Step 5 – Reality Check: Metrics
The rubber hits the road once you start to compare your on-premise baseline load and performance metrics with the AWS Re-Platformed solution. Your organization can tweak configuration parameters that align with your cost models, application response times and other SLA’s that will dictate how you migrate to a public cloud. In either case, key to success is how quickly you can stand up components that impact your application service. The modeling functionality of Cloudshell provides an easy way to incorporate network level, application layer and data structures to validate the effectiveness of your migration strategy.
Summary
Making a decision to utilize public clouds services for cost savings, scalability and agile deployments is a foregone conclusion for most organizations. Cloudshell provides an easy to model, simple to deploy orchestration solution to help you achieve your objectives. To learn more on this “How To” please visit the Quali resource center to access the documents and video resources.
