Careers at Triumph Tech

Autodesk Legacy System Migration

 

Autodesk Redshift Lift and Shift & Modernization

Timothy Wong | May 3, 2021


Migrations



Company Name
Autodesk
Case Study Title
Autodesk Redshift Lift and Shift & Modernization
Vertical

Manufacturing

Editors were not able to create content without the underlying applications timing out or crashing. After the migration was completed, Autodesk received no reports of timeouts from content creators.

Start Date

April 1, 2020

End Date

June 20, 2020

Date entered into production

June 21, 2020

Problem / Statement Definition

Autodesk both migrated from their legacy solution and modernized their legacy infrastructure due to the management cost needed to maintain their aging monolithic WordPress-hosted architecture. Managing the inefficiently performing server reduced their ability to curate new content for their online e-magazine, Redshift. Autodesk migrated their existing infrastructure quickly since it impacted their ability to get content out to over nine countries. Autodesk authors could not reliably create new content in Redshift, since the monolithic application caused server timeouts. This stunted their ability to scale and reach their markets.

Proposed Solution and Architecture

Triumph Tech lifted-and-shifted existing server(s) (rehost) and then replatformed them using RDS, EC2, Elastic Beanstalk, Elasticache Redis, Autoscaling, S3, Cloudfront, and Elastic Load Balancing for efficiency. Resource procurement, capacity planning, software maintenance, patching, and any other undifferentiated heavy lifting involved in running the application were no longer needed.

Triumph Tech selected AWS to provide the resources required to fix the problem. We used CloudFormation to deploy all of our resources. This included:

· 1 x code commit repo used to store the CFN
· 2 x VPC (2 public subnets route to internet via IGW, 2 private subnets route to Internet via NAT Gateway, 2 VPC only subnets with only local VPC route)
· 1 x Prod EC2 Autoscaling Group
· 1 x Staging EC2 Autoscaling Group
· 1 x Prod ALB has certs for and routes
· 1 x Staging ALB has certs for and routes
· 1 x RDS MySQL for Prod
· 1 x RDS MySQL for Staging
· 1 x Elasticache Redis – object cache for prod
· 1 x Elasticache Redis – object cache for staging
· 1 x prod Elastic Beanstalk Autoscaling Environment
· 1 x staging Elastic Beanstalk Autoscaling Environment
· 2 x code pipeline :
– 1 x staging
– 1 x prod

Outcomes of Project & Success Metrics

We did a deep dive into the legacy environment in order to understand Autodesk’s application stack.

We discovered that the current architecture was inefficient as it was “monolithic” VM-based.

Project success was determined by modernizing and migrating to an environment that took advantage of PaaS solutions on AWS. The project was considered successful once the monolithic components were de-coupled and running within AWS PaaS-based infrastructure.

Project success was also determined by the ability of editors to create content without the underlying applications timing out or crashing. After the migration was completed, we received no reports of timeouts from content creators.

Describe TCO Analysis Performed

TCO analysis was performed by collecting data from the AWS Billing Console and calculating the maintenance cost of the existing infrastructure, including the time and cost of resources handling capacity planning, software maintenance, and patching.

Lessons Learned

Modernized monolithic legacy infrastructure by migrating to AWS PaaS; this solution frees resources in AWS by offloading capacity planning, software maintenance, and patching.

Modernized by migrating applications away from monolithic architecture to AWS. This
1.) Increases application performance
2.) Allows Autodesk Authors to create content without server crashes.

Summary of Customer Environment

Cloud environment is native cloud. The entire stack runs on Amazon Web Services in the US-East-1 region.