The Challenge
A client was hosting their main business application (Tourism booking system) with the supplier. This solution wasn’t scalable and wasn’t up to the spike load and reliability requirements the client had.
The Architecture and why we chose Amazon
The services consisted of a Postgres database, multiple virtual machines running various incarnations of Linux and nginx/apache offering services from booking forms, to API interfaces.
Our work consisted of training the in-house developers to start to build containers for all their services to a point that they were supplying containers to our testing environment and we were then shipping those containers into the production environment as business testing allowed.
There were some legacy services which were difficult to put into containers as they stored client state in local files. These were put into production as single containers so that if they ever failed, the container was simpler and faster to restart than an entire VM.
By using ECS and ECR we managed to get all the production services apart from the database running in containers and as this allows simple cross AZ support for replication, we have had no downtime in production since the changes.
The database is running on Postgres Aurora with a read replica in another AZ.
The ECS clusters (and each service) use health checks, and cloud watch metrics to auto scale the services and cluster as required using AWS Lambda to re-balance tasks after a scaling event and now easily allows the solution to scale during peak periods.
The Benefits and the Future
This solution has given the client high up times, low cost and scalability during peak times without any of the complications of the previous suppliers co-location solution.