So far, our deployments have operated with fixed resources. In most cases, this has been fine because we optimize for the anticipated traffic load, and traffic patterns are consistent and in line with our guesses.
However, some apps experience traffic spikes, usually at crucial moments like launch, and fixed resources struggle to or simply cannot meet the demand, resulting in site outages and distress for both developers and clients.
I'd like to investigate whether Heroku's autoscaling capabilities offer a functional and economical solution for these apps.
Proposal
I would like to redeploy the BGA Salaries database on Heroku infrastructure, then use existing load testing scripts to prove out or uncover shortcomings of Heroku's autoscaling capabilities.
Beyond acting as a proof of concept for autoscaling, the current deployment pattern for BGA is unconventional and has proven difficult to debug and maintain. Provided the Heroku re-deployment results in a stable website, we can sunset the problematic production deployment. Additionally, it will provide additional practice working with Websolr (#70) on Heroku.
Deliverables
The deliverables of this work are:
A Heroku deployment pipeline for the BGA Salaries site
A report on load testing against the Heroku deployment, with and without autoscaling enabled
A memo comparing the cost of AWS infrastructure with Heroku infrastructure with autoscaling enabled
Timeline
I expect this will take about two days on uninterrupted time (which is an important consideration for scheduling this effort).
Background
So far, our deployments have operated with fixed resources. In most cases, this has been fine because we optimize for the anticipated traffic load, and traffic patterns are consistent and in line with our guesses.
However, some apps experience traffic spikes, usually at crucial moments like launch, and fixed resources struggle to or simply cannot meet the demand, resulting in site outages and distress for both developers and clients.
I'd like to investigate whether Heroku's autoscaling capabilities offer a functional and economical solution for these apps.
Proposal
I would like to redeploy the BGA Salaries database on Heroku infrastructure, then use existing load testing scripts to prove out or uncover shortcomings of Heroku's autoscaling capabilities.
Beyond acting as a proof of concept for autoscaling, the current deployment pattern for BGA is unconventional and has proven difficult to debug and maintain. Provided the Heroku re-deployment results in a stable website, we can sunset the problematic production deployment. Additionally, it will provide additional practice working with Websolr (#70) on Heroku.
Deliverables
The deliverables of this work are:
Timeline
I expect this will take about two days on uninterrupted time (which is an important consideration for scheduling this effort).