|Case Study Title||Autodesk Redshift Lift and Shift & Modernization|
|Start Date||April 1, 2020|
|End Date||June 20, 2020|
|Date entered into production||June 21, 2020|
|ARR / SMC||$178,370
|Case Study Short Description||How Triumph Tech helped Autodesk., a Manufacturing company modernize their monolithic legacy infrastructure by migrating to AWS PaaS.|
|Problem / Statement Definition||Autodesk needed to migrate away from their legacy Solution hosted with WordPress Engine and modernize their legacy infrastructure quickly due to the management overhead required to maintain their aging monolithic architecture. The cost of managing the server due to performance inefficiencies was taking away from their ability to curate new content for their online e-magazine, redshift. Autodesk needed to migrate and modernize their existing infrastructure rapidly, as it was impacting their ability to get their content out to over 9 countries worldwide. Autodesk authors were not able to rely on their ability to create new content within the redshift platform as the inefficiency of a monolithic application, caused server timeouts. This effected their ability to scale and reach their markets.|
|Proposed Solution and Architecture||Triumph first lift and shifted existing server(s) (rehost) and then replatformed by using RDS, Ec2, Elastic Beanstalk, Elasticache Redis, Autoscaling, s3, cloudfront, and Elastic Loadbalancing, in order to be more efficient as you don’t need to worry about resource procurement, capacity planning, software maintenance, patching, or any of the other undifferentiated heavy lifting involved in running your application.
Triumph chose 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)
· 1x Prod EC2 Autoscaling Group
· 1x 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
· 1x 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” ec2 based.
Project success was therefore determined by modernizing and migrating into an environment that took advantage of PaaS solutions on AWS. Project would be considered successful once the monolithic components were de-coupled and running within AWS PaaS based infrastructure.
Project success was additionally determined by the ability of editors to be able to create content without the underlying application timing out or crashing. After the migration was complete, we received no reports of timeouts being experienced by content creators.
|Describe TCO Analysis Performed||TCO analysis was performed by collecting data from the AWS Billing Console along side of adding up the cost of maintain the existing infrastructure taking into account the amount of time and cost of resources handling capacity planning, software maintenance and patching.
|Lessons Learned||Modernizing legacy monolithic infrastructure by moving to AWS PaaS solutions frees up resources by offloading capacity planning, software maintenance, and patching to AWS.
Modernizing by migrating applications away from monolithic architecture, increases application performance and in the case of Autodesk, allows their Authors to continue to create content without fear that their server is going to crash.
|Summary Of Customer Environment||Cloud environment is native cloud. The entire stack is running on Amazon Web Services. Stack is being deployed in the US-East-1 region.|
Deployments are tested and validated through a promotion strategy. The only branch which automatically deploys without approval is the development branch, which is deployed to the isolated staging environment. At this point, the team will QA and validate application functionality and approve a promotion to the production environment. A pull request is submitted to source control and merged into Master. Workloads are then deployed to the production environment.
In both the staging and production environments, security scanning is automated via a vulnerability scanner called Trivy. If a critical issue is found, Trivy will produce a non-zero exit code and the build will fail. No container image artifact will be published to EB. Client must patch the vulnerability and the vulnerability scan must pass in order to publish the image to EB.
All code assets are version controlled within GitHub.
All CloudFormation assets are stored within AWS CodeCommit.
CloudWatch application logging is integrated by default into all of our container and serverless workloads. We include this as an “in scope” item for all modernization and migration projects. This provides a centralized system where error logs can be captured and aid in operational troubleshooting