Industry
Fintech, banking
Location
Poland
Time
10.2022 - 02.2023
Company
Ideamotive
Typically, migrating from Heroku to AWS is driven by the desire to save costs or improve application scalability. In the case of this project, it was necessary to implement the so-called PAM (Privileged Account Management), which works with AWS, not Heroku.
Since the end client was a finance company, a strong emphasis was placed on security issues. PAM allows for greater control over the system, visibility into login history, and more. Additionally, the client expected the creation of a scalable, highly available environment for both production and development.
Devopsity was hired for the project by the software house that served the end client - Ideamotive. The company was torn between two offers, and the decision was ultimately based on an internal recommendation because Devopsity and Ideamotive had previously collaborated, including on the migration from Heroku to AWS.
The first step was to audit the existing resources in Heroku, SemaphoreCI, and Cloudflare. Specifically, the team examined which services the application used, how it was built, and what dependencies existed between services and microservices. Next, the team had to check the resources already existing in AWS because they had been created and the application also used them. The next step was to select AWS services that could fully replace what was created in Heroku and design an architecture that adhered to best practices in terms of security, reliability, and scalability. It was then deployed, and the development environment was moved to verify how the application would behave in it. Furthermore, the entire CI/CD process and monitoring of all services had to be prepared for the AWS environment.
After completing the audit and preparing the architecture for the entire infrastructure, the Devopsity team was ready to start working. Using the Terragrunt tool, they began creating individual infrastructure components while containerizing the Heroku applications (ECS Fargate was chosen as the hosting location). The following individual infrastructure elements were created:
Compute/Workload - ECS
PostgreSQL - RDS
ElasticSearch - OpenSearch
Redis - ElastiCache
Cron Scheduler - EventBridge
Environment Variables - Systems Manager
Load Balancing - Application Load Balancer
Static Content - CloudFront+S3
Container Registry - ECR
After creating the required elements for the applications, the process of migrating the applications to ECS began. In ECS, services were created for each component of the application, and if necessary, an ALB (Application Load Balancer) was connected. After connecting each part of the application, it functioned as intended, and any configuration errors were captured using CloudWatch, as each application had its own log streams set up there. While the application was being tested by QA, the team started building the CI/CD process for the new environment using the existing SemaphoreCI tool in the project. This was the team’s first encounter with this tool, but fortunately, it proved to be intuitive like other tools of its kind, and the differences in YAML syntax were not significant, allowing them to build the entire build and deployment process for the ECS and S3+CloudFront application quite smoothly.
Issues the team had to deal with during the project implementation:
The work and setup were very well planned, resulting in a smooth migration with only 3-4 hours of service unavailability. All the core objectives were achieved. With the help of Devopsity, a simple and efficient infrastructure was created that met the client's requirements. Heroku environments were fully migrated to AWS, and the entire infrastructure was created using code (Terragrunt). The environment is fully automated, and performance has significantly improved. The implementation of PAM will be a priority and the most significant measurable outcome, in which Devopsity will also be involved.
