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 also a significant cost. (estimate $660-$1240/month).

The main trade-off of heroku is:

• Elimination of operations and maintenance tasks formerly handled by systems administrator position, for

• Significant budget, and in some cases increased challenge to remaining developers

After some months spent examing and experimenting with heroku, although it is not perfect, the tech team thinks it makes sense to try heroku, if we can afford it, as a solution to the unsustainable absence of the terminated Systems Administrator position.

In the rest of this document are a list of high-level pro’s and con’s of heroku; itemized details of how we arrived at cost estimate; and a list of other possible solutions to explore as alternatives to heroku.

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. We can – if willing to pay for the resources – easily scale up infrastructure to handle traffic spikes, or high ingest loads. This was something we hadn’t had the capacity to create reliably in our current infrastructure, and example of what heroku gives you.

• No-contract, pro-rated billing. 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. Some additional components we will need, as part of a move to PaaS managed infrastructure, are available as heroku add-ons, meaning convenient single-heroku-invoice billing for third-part services with no-contract pro-rated billing.

Con

• Cost. This is the main trade-off. Heroku is known to be a high-quality solution but one of the most expensive ways to deploy. We estimate the monthly cost for our application will be $660-$1240/month. This is mostly on top of our existing infrastructure costs – it will replace only our existing digital collections EC2 costs ($50-$100/month? Not sure). However, this is still significantly less expensive than an FTE systems administrator.

• Some loss of flexibility/customization. While heroku is a very flexible platform, it is still a platform with constraints. Some customization may take more developer work to accomplish, or be impossible.

  • Example: We need to install the vips software package, and it turns out needed the most recent version to avoid a bug effecting us. We had more trouble getting this done on heroku, although ultimately succeeded.

  • Example: Heroku has less flexiblity in how much RAM you have available, fewer configurations. Some of our existing functionality was using too much RAM to fit in certain heroku dyno sizes; we ultimately were able to refactor it to fit, but this will not always be guaranteed, and shows added development challenges are possible in heroku (trade-off for reduced operations challenges).

• Some developer tasks take longer to execute.

  • Opening up a “console” on heroku infrastructure – a common developer task – can take 50-60 seconds of staring at the screen waiting for boot. (Compare to ~5 seconds in current infrastructure). This interupts developer “flow” and is just kind of annoying.

  • Same applies to executing maintenance tasks like a Solr reindex – developer spends ~50s staring at screen waiting for start.

• heroku maybe stagnating a bit under current management.

• infrastructure-as-code

Cost Estimate Detail