Migrate an on-premise Application to AWS Public Cloud

Migrate an on-premise Application to AWS Public Cloud

Author:
admin
Published:
June 26, 2018
header-picture

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.

 

Cloudshell-Management-VPC-1024x514

 

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.

 

Page-6-Image-3

 

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

 

Page-6-Image-4

 

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.

 

Page-7-Image-1

 

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.

 

Page-10-Image-2

 

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.

 

Page-13-Image-3

 

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.

 

Page-14-Image-1

 

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.

Topics: DevOps

 

4 Major Business Problems Solved by Infrastructure Automation

Every company and organization that develops software and applications needs environments. As they race toward innovating new products and...

Read More
 

Infrastructure Automation at Scale: Blueprinting vs. Terraform

[This blog was originally published in November of 2019 and updated with new content in May of 2021.] Whether you are a software architect,...

Read More
 

Why Infrastructure Automation Is Critical for Cyber Security

Revelations about the recent SolarWinds hack have highlighted the evolving sophistication and growing effectiveness of cyber attacks,...

Read More