In this video, you’ll see how to simplify app refactoring with AWS Migration Hub Refactor Spaces.
With this feature, you can quickly set up an infrastructure for refactoring, rewriting and rearchitecting apps,
operate these apps at scale regardless of app changes
and focus on delivering value from refactoring without having to create the environment.
To get started, let’s navigate to AWS Migration Hub and open Refactor Spaces.
AWS Migration Hub Refactor Spaces is the starting point for incremental application refactoring to microservices.
Before we create our refactor environment, let’s look at the application we are going to refactor.
For the purposes of this example, our application is an online store called The Unicorn Shop.
The Unicorn Shop is a typical monolithic application, and we’d like to break out two pieces of key functionality.
The first is the catalog of products for sale.
The second is the shopping cart.
We want these two services to be independent of each other for scalability and development purposes.
Let’s go back to Refactor Spaces and create an environment.
An environment is a multi-account network fabric consisting of peered VPCs.
We’ll call this environment “UniShop.”
We’ll call our application “UnicornStore.”
Next, we’ll select the application’s proxy VPC.
The proxy lets the front-end application use a single endpoint to contact multiple services.
If an application is made up of multiple AWS accounts,
we can share the refractor environment and its application with other AWS principals.
Refactor Spaces then sets up the networking fabric that allows those services to communicate seamlessly.
In this case, let’s move on and create the environment.
Now that our environment and application have been created, let’s drill into the application.
The first thing we want to do is create a proxy that will pass through to the existing monolith.
To do that, let’s create a service.
We’ll call it “Legacy.”
Next, we’ll select the VPC where our current service resides and specify the existing service endpoint.
Now we’ll set this as the application’s default route and create the service.
We’ve created our proxy, but our default route is simply routing traffic straight through our monolithic application as before.
Let’s return to the application.
The development team for The Unicorn Store has been busy refactoring out the application’s catalog and shopping cart capabilities.
The new microservices were deployed into our serverless container service, Amazon ECS on AWS Fargate.
Let’s navigate to Amazon Elastic Container Service (Amazon ECS) and take a look.
Next, we’ll specify the VPC endpoint for the catalog service.
Here are our cart service and catalog service.
Next, we’ll begin routing the functionality in our monolithic application to these distinct microservices.
Before that, let's quickly define what we mean by microservices and monolith.
In this context, our Unicorn store is a legacy monolith application where all the functionality and components are tied together,
and thus must be deployed together.
As part of this demonstration, we're splitting out key components of this legacy monolith and creating independently deployable microservices,
so we're able to easily scale those individual components as needed.
To create these microservices, let’s go back to Refactor Spaces to start the process.
We’ll call this one “Catalog service.”
Let’s select a VPC to add to the environment’s network bridge.
Let’s also add a health check endpoint for this service.
Let’s enter a source path for the route and create the service.
Now that the route has been provisioned,
let’s go to The Unicorn Shop and refresh the page to ensure our catalog is still working.
Our catalog is still being serviced,
but let’s verify that it’s with the new service we just provisioned and not the old.
To do that, we’ll navigate to CloudWatch and take a look at our logs.
Let’s find the latest log.
Here we can see that our health check endpoints are working properly.
Here’s our new catalog service.
We see that it issued a request to the database to get all unicorns.
The response has been written here and completed.
Now that we’ve confirmed that our catalog is using our new microservice,
let’s go back to Refractor Spaces.
Next, let’s get our unicorn store to leverage our new microservice for the shopping cart functionality.
Let’s create another service.
We’ll call this one “cart service.”
Let’s specify the VPC, endpoint, and health check endpoint.
Here we’ll specify the source path for our shopping cart functionality.
Next, we’ll go to The Unicorn Shop and test our shopping cart functionality.
Let’s add some items to the cart.
The items have appeared in the cart.
Let’s take a look at our developer tools to confirm how things are going behind the scenes.
If we ring up the cart, we go to our proxy URL with our user ID.
Once again, it’s not apparent where this request is being serviced.
We could inspect the CloudWatch logs again, but instead let’s try to find the relevant entries in our database, Amazon DynamoDB.
This entry should correspond to our user ID.
Here are the two unicorns we added to the cart.
There’s the ID for one unicorn.
Here’s the ID for the other unicorn.
We’ve confirmed that our application’s catalog and shopping cart functionalities are now running out of Amazon ECS on AWS Fargate.
We were able to move the traffic from our monolithic application into these new microservices
without having to configure any networking infrastructure and while keeping the architecture changes transparent to app consumers.
You've just seen how to quickly set up app refactoring with AWS Migration Hub 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.