In this video, you’ll see how to modernize applications using Customizations for
AWS Control Tower (CfCT) and AWS Migration Hub Refactor Spaces.
With this solution, you can incrementally transition to a microservices-based
architecture by using CfCT to deploy related CloudFormation templates
across multiple AWS accounts, and use the refactor environment to simplify
routing from the legacy application to the new microservice.
Before we start, let’s take a quick look at the solution architecture.
We will use three AWS accounts.
The Refactor Spaces Environment Owner account is the foundation
account that holds the resources for our refactor spaces.
The Legacy Application account holds the resources associated with our
Amazon Relational Database Service (RDS) database and Amazon Elastic
Compute Cloud (EC2) instance.
The Shopping Cart account is a microservices account that will host our
DynamoDB and our Lambda functions.
Let’s begin in the AWS console, where we’ll navigate to the Management
account for the AWS organization, which is where the CfCT solution is installed.
Under CodeCommit, we can view our CfCT repository.
We’ll open the manifest.yaml file, and ensure that it’s using the latest CfCT version.
This file controls all the resources that will be installed by the CfCT solution.
Let’s edit the file to include the resources we want to create.
We’ll specify the target account and resources for each stack in a top-down
manner, starting with our Legacy Application account.
For the second stack, we’ll specify the Refactor Spaces foundation account.
The third stack will launch the DynamoDB table and Lambda
functions for our microservices application account.
For demonstration purposes, we have already uploaded each stack’s template
to an Amazon Simple Storage Service (Amazon S3) bucket.
We’ll commit the changes to the main branch.
Let’s navigate to AWS CodePipeline to view the CfCT pipeline.
The CfCT pipeline is currently in progress.
This CfCT pipeline has four stages.
The Source stage is initiated by the customized configuration package.
The Build stage uses AWS CodeBuild to validate the contents of the configuration package.
The Service Control Policy stage executes resources for the service control policy.
The final CloudFormation Resource stage confirms the resources and
creates the stacks from the templates specified in the manifest file.
We can view the progress details in CodeBuild.
Here are the build logs.
We can open the tail logs to view the ongoing process.
Once the pipeline is complete, we can review the CloudFormation stacks in the target accounts.
Let’s open our Legacy account to locate the stack set we created.
In CloudFormation, we can see the stack set has been created.
We can view the stack’s resources, events, and outputs.
These outputs are used as input to the other stacks within the CfCT framework.
To test that the site has been created successfully, let’s open the website URL.
Our website is called The Unicorn Shop.
Let’s sign up.
We’ll enable developer mode to monitor the backend.
The object is referencing an EC2 instance because we’re currently using
the Legacy backend for the application.
We’ll copy the uuid that was created for the user.
Let’s log in and add some items to the cart.
As we add items to the cart, the cart number increases.
Let’s remove an item from the cart.
The application is currently saving the data directly to our EC2 instance.
To facilitate the move from the Legacy backend to our microservices backend,
we’ll return to our Refactor Spaces foundation account and implement Amazon API Gateway.
We'll select the unistore API that was created by our CfCT stack.
Let’s drill down to locate the invoke URL.
We’ll copy this URL so we can invoke the API from our other accounts.
Now, let’s navigate to our Legacy account, which contains the S3 bucket with our UI.
We’ll use AWS CloudShell to update the bucket’s config.json file.
We’ll create a local copy of the UI bucket config.json file that we can modify.
Let’s update the host to send traffic through the API Gateway REST API.
Now, let’s copy our updated file back into the bucket.
Next, we’ll enable public-read access so the object can be used by all our accounts.
Let’s open the S3 service to ensure that Block Public Access settings
are disabled for this account.
Let's go back to the Unicorn Shop and confirm that it’s using the API Gateway for the backend.
We’ll refresh the page.
The host is now referencing the API’s invoke URL.
We can add and remove items from the cart.
Next, we’ll update our microservices application to redirect traffic to our
Lambda functions so that the Amazon DynamoDB table is used.
Let’s return to our Management account and navigate to the manifest file.
Let’s scroll to the bottom and paste in our shopping cart microservices.
The first stack we added will create the Shopping Cart microservices.
The second stack will update the API Gateway service to redirect traffic to the microservices.
Note that the function uses the alfred helper to reference the SSM Parameter Store.
This allows it to reuse output from previous stacks as input into stacks in multiple accounts.
Let’s commit the changes.
The change will trigger an update to our code pipeline.
The pipeline execution is now in progress.
Let’s view the details for the CloudFormation Resource build.
Let’s review the tail logs.
We can see the Shopping Cart services are now running on the CloudFormation stack.
Let’s check the progress of our microservices account.
In the CloudFormation console, we can see the stacks we created earlier.
Let's look at our Lambda functions.
We can see the services for our website.
Next, let’s look at our DynamoDB table.
We’ll explore the table items.
When service traffic is redirected to our microservices DynamoDB table,
we will see the cart items displayed here.
Let’s return to the CloudFormation console to view the Shopping Cart stack resources.
We can see that the routes and services have been created to make calls to Refactor Spaces.
Let’s navigate to our Foundation account and review the Refactor Spaces environment.
Under the Services and routes tab, we can see the services we redirected.
The cart services use a different account than our legacy service
and utilize the Lambda functions in our microservices endpoints.
The routes have also been updated to use the new target endpoints.
Our environment is shared with the microservices account using AWS
Resource Access Manager.
Now, let's go to the Management account to check on the CfCT pipeline.
The CfCT pipeline execution has succeeded.
Let’s view the updates in the Unicorn Shop.
When we last visited the site, we had two items in the cart.
Let’s refresh the page.
Our cart is now empty because we have moved from an EC2 instance database
to a microservices DynamoDB table.
Let’s view the table in DynamoDB.
We’ll explore the table items to monitor the status of the cart.
As we update our cart, the DynamoDB table entries will change.
Let’s return to the Unicorn Shop and add some items.
We’ll run the scan to update this page.
One item was returned. Let’s take a look.
Two items were added to the DynamoDB table.
Now, let’s switch to the Unicorn Store and remove one item from the cart.
We’ll rerun the query.
The table has updated successfully.
You’ve just seen how to modernize applications with Customizations for
AWS Control Tower and Refactor Spaces.
You can learn more about this topic in the description and links for this video.
Thanks for watching. Now it’s your turn to try.