Migrating the Monolith to the Cloud with Incremental Application Modernization

Note: If you are interested in Contino running this immersive, hands-on training session on Incremental Application Modernization, with your team, email awsappmod@contino.io for more information!

Contino and the AWS team recently ran a joint full-day training session on Incremental Application Modernization. This session covered incremental application modernization techniques using AWS serverless services. The serverless development lifecycle and architecture were presented along with hands-on labs for attendees. We invited engineers and product owners from various NYC organizations in multiple fields, including financial services, insurance, and retail.

More and more businesses are embracing the cloud, but the migration of monolithic applications is challenging. Application and Infrastructure teams have first to understand what it means to do a cloud migration, then work through that; this path could take years.

With this training session, we helped attendees understand that their cloud migration does not have to be all at once. Below is a diagram that helps explain the differences between a cloud migration and a modernization effort that can be followed to decrease the burden of cloud migration.

Incremental modernization can be used to migrate high-value applications into the cloud.

Using the Strangler pattern, the first step in starting to modernize your application is rehosting the app in the cloud by completing a minimal viable refactor, MVR. That is, changing and updating just enough of the app or infrastructure to run in the cloud.

This MVR could include tasks such as upgrading, and testing cloud supported operating systems on EC2; removing sensitive data from the application configuration and moving it into a vault provider, like AWS SSM or even moving databases to a cloud-managed service that is compatible with the application’s existing database such as MySQL on AWS RDS.

Once the MVR completes, the next step is to measure the high traffic or hot spots of your application by overlaying it with AWS API Gateway. Once the application is instrumented and monitored with AWS Cloudwatch, developers can start assessing the hot spots and migrating that functionality into either Lambda, containers, or as a last resort, EC2.

The Strangler pattern in these high-level steps:

Rehost
Facade with API Gateway
Detect and measure hot spots
Create Lambda for hot spots
Canary release to Lambda
Iteratively strangulate

Example Architecture of applying the Strangler Pattern on AWS

AWS Lambda, ELB, EC2 are among some of the compute services used during the modernization. Now that the functionality has been broken up into specific units, built for purpose databases can be implemented as well. Smaller changes and smaller teams can help manage this functionality.

Splitting out functionality gives architects and developers the ability to leverage other compute services inside AWS such as serverless. One key advantage of doing this is in the image below. As we move further to the right of this arch, traditional datacenter operations are being removed and pushed off to the cloud provider. In our training session, attendees learned about these services and performed labs that re-enforced these patterns.

Below is an example of an on-premise architecture that is incrementally migrated to AWS Serverless technologies:

Migrate static assets and other front-end code to S3
Utilizing AWS Cognito, application authorization, access, and authentication can be serverless
Application functionality can be migrated to Lambda as described above with the strangler pattern
Powered by AWS Global CDN, CloudFront, API Gateway can load balance requests globally
Lastly and most importantly, the application database moves to a serverless cloud-managed Database like RDS.

Lambda is at the heart of the serverless offering from AWS. It is integrated into many of the other serverless services as well. Below is a list of just that. Here is a link to the 5 Killer Use Cases for AWS Lambda.

Services That Invoke Lambda Functions Synchronously:

Elastic Load Balancing (Application Load Balancer)
Amazon Cognito – Use Lambda to create custom authorizers
Amazon Lex
Amazon Alexa
Amazon API Gateway – API Gateway will pass requests to Lambda to execute
Amazon CloudFront (Lambda@Edge)
Amazon Kinesis Data Firehose

Services That Invoke Lambda Functions Asynchronously:

Amazon Simple Storage Service – Lamdba can monitor and execute tasks in response to s3 API events
Amazon Simple Notification Service
Amazon Simple Email Service
AWS CloudFormation – Execute tasks during Cloudformation provisioning
Amazon CloudWatch Logs – Execute actions based on log events or alerts.
Amazon CloudWatch Events
AWS CodeCommit
AWS Config

Services That Lambda Reads Events From:

Amazon Kinesis
Amazon DynamoDB – Executes tasks when data changes in Dynamodb
Amazon Simple Queue Service

These services and architecture patterns can be learned and applied, but with an AWS Premier partner like Contino helping your team, we can supercharge your cloud adoption. Read about how Contino and AWS helped NAB successfully migrate 30 applications in 50 days to AWS.

If you are interested in Contino running this training session with your team reach out to your AWS Account Team or email awsappmod@contino.io for more information!