Heroku Proposal (Draft)

Heroku is a “Platform As a Service” (PaaS) product, which we could deploy our entire Digital Collections application on.

Currently, we deploy to “self-managed” AWS (Amazon Web Services) resources. The current approach is not long-term sustainable with the termination of the Systems Administrator position who took care of managing the AWS resources.

Heroku is one option for paying for a more expensive platform that will do for us some of the things the Systems Administrator position used to do.

Heroku is a significant cost – we estimate the monthly cost for our application will be $660-$1240/month. This is mostly on top of our existing infrastructure costs, it doesn’t replace very much of them. However, this is still significantly less expensive than an FTE.

….

Pro

• Eliminate need for local skillset and time to manage AWS resources directly. This is the main motivation for heroku. We would no longer need to maintain the ansible playbook at all. We would no longer need the “management” server that we have now trying to orchestrate our self-managed AWS. We would still be managing our S3 buckets directly in AWS, and maybe some other minor simple services, like SES for email delivery – much simpler AWS products.

• Heroku is a popular and high-quality product. It’s feature set, developer UI, documentation tend to be very good, and we found this true in our testing. It’s been around for a while, has many customers (often startup/ecommerce), specifically including other Rails apps, and is generally considered a top-of-the-line service.

• Easier scaling

• Heroku has no contract. And all billing is pro-rated to the minute. If we ever choose to shift our infrastructure yet again, we can switch at any time.

Con

• cost

• some loss of flexibility/customization

• some developer tasks are slow

• heroku maybe stagnating a bit under current management.

• infrastructure-as-code

Cost Estimate Detail