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 firstname.lastname@example.org 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:
- 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 email@example.com for more information!
More Contino Resources
Contino Blog posts on Serverless
Comparing AWS Lambda performance of Node.js, Python, Java, C# and Go
Introduction to Kubernetes Workshop
AWS re:Invent 2016: From Monolithic to Microservices: Evolving Architecture Patterns (ARC305)
AWS re: Invent 2018: Mainframe Modernization with AWS: Patterns and Best Practices (GPSTEC305)
Strangling the Monolith With a Data-Driven Approach – David Julia, Simon Duffy (Pivotal Software, Inc.)