AWS RE:Invent 2021 Highlights – Part 2
Part two of our AWS RE:Invent highlights focuses on what PTS considered to be two must-attend sessions dedicated to AWS Migration Hub. PTS Principal Consultant, Ken Taylor explains how from the highest level, there is an appropriate usage of technology to make incremental application migration easier.
AWS had two sessions during the AWS RE:Invent 2021 that were considered must-attend sessions by PTS. These were the sessions dedicated to their AWS Migration Hub. At PTS we are frequently working with clients on cloud migration issues, so there is a high degree of interest in what the Migration Hub brings to the table.
In this post we will discuss two related sessions from the show:
Modernize faster with AWS Migration Hub Refactor Spaces
Simplify multi-account refactoring with AWS Migration Hub Refactor Spaces
From the highest level, there is an appropriate usage of technology to make incremental application migration easier. The key components are:
- Usage of the Strangler Fig pattern. The Strangler Fig Pattern is an incremental process for refactoring applications. It is a method whereby a new system slowly grows in parallel to the old system, using alternate routing to replace pieces until the old system is “strangled” and can be removed.
- Usage of Event Storming to figure out how to convert processes from monolithic to cloud native. More on this later.
- Migration Hub Refactor Spaces technology for routing between old and new application components. This includes
- Amazon API Gateway
- Network Load Balancer and VPC
- AWS Transit Gateway
The basic idea is that once you have set up the Migration Hub Refactor Space, then you can incrementally change the application or parts thereof and have the Hub direct traffic to the newly refactored components while it continues to route traffic to the unchanged monolithic application components until those have been re-designed. In this way, you can make your cloud-native redesign changes incrementally, and ultimately “strangle” the old code as it no longer gets referenced.
So far so good. Now we need to examine what is behind Event Storming a bit more closely. This is a manual re-design process including workshops with teams of subject matter experts and business owners, workshops, sticky notes, and you get the idea.
The problem with this is that for many enterprises, that deep level of understanding of legacy applications no longer exists. The ability to bring together a team of technical development and business SMEs to be able to map out how to re-design existing processes with event storming seems like it could be a bridge too far for many organizations.
With Event Storming the goal would be to manually deep dive into the following decomposition patterns:
- Auxiliary Services
- Business Capability
- Business Transaction
- Services Per Team
- Business Sub-Domain
Overall, some decent work by AWS to provide infrastructure to aid with application refactoring. The hard part of refactoring still requires additional solutions to reduce the reliance on manual effort.
Author: Ken Taylor
Role: Principal Consultant
Location: Boston