Helping a non-profit music and video gaming festival migrate to AWS native capabilities

The main issue our client faced was a lack of resources. The core of our client’s operations is a small team of seven employees, with one primary employee managing the development side of the business. This employee was overloaded with responsibilities to keep the operation afloat, and they didn’t have time to look for and embrace new features. Additionally, our client’s developer didn’t have time to embrace DevOps principles or focus on the issue of scalability.

As our client is a music and gaming festival, they experience a sudden acceleration of online activity in September when tickets are released. Ticket prices are structured in a way where the cheapest tickets are released first, followed by more expensive ones. The system must cater to sudden demand when customers rush to buy the less expensive tickets, and then return to low-level use for the rest of the year. If our client can’t cater to demand, they risk facing frustrated customers and a PR issue. But the existing application was not straightforward to scale. It caused significant cost overruns during peak usage times and could not handle requests when load was underestimated.

Our client was using DigitalOcean for their Virtual Machine (VM)-based application, although the container solutions weren’t suitable, and they didn’t want the operational overhead of running and maintaining Kubernetes. Similarly, the support for managed services for Redis, PostgreSQL, and RabbitMQ was insufficient. Every instance of the application was running on its own VM and was not containerised, leading to hotfixes being lost or untracked in source control.

As part of the AdaptaKind effort (Adaptavist’s give back program for charity), Adaptavist’s professional services team members helped with the project. Our client’s employees, coding contractor, and a team of volunteers joined in implementing the solution, which was split into two stages.

Our client was using Salt, a configuration management and orchestration tool, to deal with application deployment, scaling, automation and anything related, so the process involved moving it to be containerised and more cloud-focused. 

The first phase of the transformation was to establish our client’s major pain points and move the services that were easier to switch from DigitalOcean to AWS. This included moving the client’s database server into AWS RDS, AWS ElastiCache for their Redis server, and AWS SES for sending emails.

The second phase of the transformation was to move the client’s old systems. Our client needs to access historical data, so we moved their legacy event servers into AWS as part of this migration. We migrated the data into systems and used containers running inside AWS ECS as a test bed environment to work out some of the issues in a trial-and-error process. During the process, we faced challenges replicating the load from scaling events. We worked out how to predict these loads and pre-scale the system to handle the load.