7 Strategies for Migrating Applications to the Cloud, introducing AWS Mainframe Modernization and AWS Migration Hub Refactor Spaces

by Jonathan Allen, Enterprise Strategist, AWS Enterprise Strategy

“How emigration is actually lived — well, this depends on many factors: education, economic station, language, where one lands, and what support network is in place at the site of arrival.” -Daniel Alarcón

The most read AWS Enterprise Strategy blog of all time is the 6 Strategies for Migrating Applications to the Cloud written by the founding member of the team Stephen Orban all the way back on the 1st of November 2016 (hey, 5 years ago in cloud is a long time). While Stephen’s blog stands the test of time, and the AWS Services Teams here have innovated with dozens of new additions since then; AWS Application Migration Service, Specialized workloads assistance, AWS Outposts, tons of database migration tooling updates (along with 450,000 databases moved). I am excited today provide more detail on three new significant releases that again increase the speed (and safety) with which enterprises can use to migrate and join customers like Autodesk, BP, Capital One (my alma mater), Disney, Expedia and the thousands of others who have successfully migrated to AWS. In addition, the previously infamous 6 R’s model (from Stephens original blog post) iterated to the 7 R’s mental model with the launch of VMWare Cloud for AWS in late 2017.

And today, I want to expand on how these new services will accelerate starting, refactoring and replatforming.

Getting going – when I started as a customer building on AWS, the team and I went through multiple revisions of creating our landing zone and multi account strategy. Cloud setup and governance can be complex and time consuming, slowing down the very innovation you’re trying to speed up. Customers today no longer have to spend time doing this. AWS Control Tower provides the easiest way to set up and govern a secure, multi-account AWS environment, called a landing zone. AWS Control Tower creates your landing zone using AWS Organizations, bringing ongoing account management and governance as well as implementation best practices based on AWS’s experience working with thousands of customers as they move to the cloud.

This week we launched AWS Control Tower Data Sovereignty – organizations that operate in highly regulated industries or the public sector often need to control where their customer data is stored and processed—a concept known as data residency. Customer data is the personal data uploaded to AWS services under their AWS accounts. With AWS Control Tower, customers can now implement data residency preventative and detective controls in minutes with a set of purpose-built guardrails to help keep their customer data in the AWS Region or Regions they specify, helping you build and use in a highly regulated environment even faster.

Next, we come to Refactoring – looking after the hundreds of people who in turn are responsible for looking after hundreds of applications, and the infrastructure that supports it, is a 24x7x365 job. As a CTO previously I know it’s really tempting, that as you migrate to the cloud, you want to ‘fix the technical debt as you migrate’ and the desire to build ‘Cloud Native’ is strong. This is a totally natural reaction, this is called refactoring, and if you attempt to apply this pattern to all your workloads as you migrate, the hit to your speed of migration could be fatal to your journey. I have seen refactoring sometimes take 20 times longer versus rehosting or replatforming approaches. Changing code, changing architecture, basically changing too many variables at once, and suddenly you can find yourself going too slow.

To accelerate the whole refactoring journey, this week we announced the launch of AWS Migration Hub Refactors Spaces – this enables customers to fast-track refactoring applications, simplify development, and manage existing apps and microservices as a single application.

When using Refactor Spaces, you can start using it with one or more accounts. We recommend starting with three — one for the existing application, one for the first new microservice, and one account to act as the refactor environment owner where Refactor Spaces configures cross-account networking and routes traffic. First, you create a Refactor Spaces environment in the account chosen as the environment owner and share the environment with the other two accounts using Resource Access Manager. Once an environment is shared with another account, Refactor Spaces automatically shares resources it creates within the environment with the other accounts by orchestrating Resource Access Manager and resource policies.

The refactor environment provides unified networking across accounts by orchestrating Transit Gateway, Resource Access Manager, and VPCs. The refactor environment contains your existing application and new microservices. Once you have a refactor environment, you create your Refactor Spaces application within the environment. The Refactor Spaces application contains services and routes and provides a single endpoint to expose the application to external callers. The application models the strangler-fig pattern and orchestrates API Gateway, API Gateway VPC Link, NLB, and resource policies inside your account — orchestrated AWS resources are not hidden, so you can customize them as needed. Using Refactor Spaces’ application, you transparently add new services to a single HTTPS endpoint and incrementally route traffic away from your existing application to new services. This keeps underlying architecture changes transparent to the application consumer.

An application supports routing to services running in containers, serverless, and EC2 with public or private visibility. Services within an application can have one of two endpoint types — a URL in a VPC or a Lambda function. Once an application has a service, you add a default route to direct all traffic from the application’s proxy to the service representing the existing application. As you break out or add new capabilities in containers or serverless compute, you add new services and routes to redirect traffic to the new services.

For services with URL endpoints in a VPC, we automatically bridge all service VPCs within the environment using Transit Gateway. This lets any AWS resources you launch in a service VPC communicate directly with all other service VPCs added to the environment. You can apply additional cross-account routing constraints using VPC security groups. When creating routes that point to services with Lambda endpoints, Refactor Spaces orchestrates API Gateway’s Lambda integration to call the function across AWS accounts.

This provides the following benefits:

1. Reduces the time to setup a refactor environment and time to value when modernizing.
2. Reduces the complexity for iteratively extracting capabilities as new microservices and re-routing traffic from old to new (strangler-fig pattern). Manage existing apps and microservices as a single application with flexible routing control, isolation, and centralized management.
3. Dev teams achieve and accelerate tech and deployment independence. Simplify development, management, and operations while apps are changing.

Jeff Barr and team as usual have created an awesome detailed blog that goes into the technical detail here.

Let’s talk about Mainframes!

One of the worst mistakes I and many engineers have made, is to continue to optimize something that should not exist. Many of the FSI customers I have helped migrate, often have a small but critical percentage of core workloads that don’t run on x86 architecture. When you look at the public statistics that exist for mainframes, it’s interesting. As of 2017, 92 of the world’s top 100 banks continued to use mainframes, and 87% of all credit card transactions and nearly $8 trillion in payments annually are processed on mainframes. From 2008 through to 2018, the aggregate installed base of Millions of Instructions Per Second (MIPS) computing capacity across all types of mainframe processing have grown by a factor of 3.5X. Why has the MIPS usage grown, while the number of mainframe customers has fallen? The answer is simple – as we have added more channels (mobile apps, conversational interfaces) there are a lot more reads happening. At the same time while enterprises have greatly increased the velocity of delivery of the applications that surround the mainframe; DevOps, agile practices and cloud. The mainframe resists this, with many enterprises stuck on once a quarter ‘release cycles’ and 4-year z/OS upgrade cycles (we are currently in the z14 to z15 cycle right now). As one customer recently told me “The moment we finish a mainframe upgrade, we start the next one”. There has to be a better way, and now there is.

AWS Mainframe Modernization – is a unique platform for Mainframe migration and modernization. It allows customers to migrate and modernize their on-premises Mainframe workloads to a managed execution environment on AWS. This enables two popular migration patterns: Replatforming and Automated Refactoring. Customers can access and analyse migration readiness and plan projects. This provides the development, build, and tooling for modernization projects. Once implemented and tested, customers can deploy their Mainframe workloads to AWS with the managed runtime environment.

Using AWS Mainframe Modernization, System Integrators (SI) and enterprise migration teams can assess and analyse their migration readiness and plan their migration and modernization projects. It can be used to refactor mainframe workloads, transforming legacy language applications to Java-based services. Alternatively, the service can be used to replatform mainframe workloads by re-compiling their existing code to run unchanged in a mainframe emulation environment on AWS. AWS Mainframe Modernization also provides a set of development, testing, and deployment tools to help developers with their mainframe software development process end to end. There are no upfront costs for using AWS Mainframe Modernization; customers only pay for the runtime compute environment they provision. The analysis, development, test, and deployment tools are provided at no additional cost.

I’ve had the privilege of working with over 650 enterprises who are migrating, in the last 5 years at AWS, and I’ve been fortunate to present the re:Invent breakout ‘Executing a Large Scale Migration to AWS’ in 2018 and 2020. I am really excited to be doing this signature breakout for third time this year at re:Invent 2021, for those you attending in person it’s session ENT230 ‘Executing a Large-Scale Migration and Modernization’ at 9:15am on the 1st December.

—Jonathan

https://www.ibm.com/blogs/systems/ibm-z-the-banking-platform-for-the-future/
https://www.itjungle.com/2019/09/16/new-system-z15-mainframe-takes-the-heat-off-power-systems/