Refactoring and Replatforming Applications Briefing

Today, more companies than ever are moving to the cloud. Some are doing so in hopes of leveraging the scalability and flexibility public cloud providers offer at the press of a button. Others have heard the buzz around the features and services available from cloud compute and deployments. Many may simply be looking to get out of costly long-term data center or hardware refresh contracts.

Regardless of your reasons, if your organization is one of the many starting your journey to the cloud, remember that there is scarcely a good replacement for careful and solid planning. In the rush to move applications and services to the cloud quickly, far too often companies fall back to the default of a "lift-and-shift" pattern. This approach — where applications, data or services are rehosted directly into managed VMs in a public cloud's data center — is appreciated for its simplicity and is sometimes an appropriate pattern to follow. However, these rehosted applications generally gain little to no benefit from living in a cloud-hosted environment because they do not take advantage of the features that native cloud offers (e.g., managed services, elastic compute, container deployments, etc.). To better leverage native cloud features, an application generally must be "replatformed" or "refactored" to run in an intended native cloud way.

This briefing will take you through a sample legacy application, demonstrating a variety of ways in which WWT cloud architects refactored it to leverage many of the services and benefits the public cloud provider offers. This includes scaling based on demand, decreasing operational costs and using managed services to get deployed and running quickly with lower long-term operational overhead. The briefing starts with a simple lift-and-shift demo, but progresses into other architectures that better leverage capabilities that are gained by running in the cloud.

After participating in this demo, you should:

• Understand how application code can be updated to work with any of the above scenarios in the cloud.
• Understand how automated deployments can be performed with any of the above scenarios.
• Understand how Terraform can be used to automate provisioning of cloud resources in each of the above scenarios.
• Understand trade-offs between each of the above scenarios and associated architectures.
• Be familiar with various AWS services (Aurora, Dynamo, Elastic Beanstalk, API Gateway, Lambda, etc.) and what benefits those services provide.
• Evaluate which services you should use for your application(s).
• Be familiar with the process of breaking down a monolithic application into smaller microservices along with pros/cons of that effort.

Demo details

The sample application uses AWS as the target cloud provider. It contains a React front-end and .NET Core back-end APIs. Regardless of the cloud provider and languages used, architectures shown in the lab can be used for most of the major cloud providers (Azure, Google Cloud Platform, etc.) and programming languages (Angular, Java, Python, etc.).

The demo shows how an application can be run in AWS using the following scenarios:

If you are only interested in a subset of the above scenarios, the demo can be focused on those scenarios upon request.

Technologies

• .NET Core
• React
• MySQL
• Terraform
• Powershell
• Shell scripting
• AWS
  • VPCs/Subnets
  • EC2
  • Auto-scaling groups
  • Elastic Beanstalk
  • ECS
  • EKS
  • API Gateway
  • Lambda
  • Code Deploy
  • Cloud Formation
  • ECR
  • Serverless Application Model (SAM)
  • RDS
  • Aurora
  • Aurora Serverless
  • Dynamo DB
  • S3
  • Parameter Store
  • Cognito