...
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
vipssoftware 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. There could be other packages we want in the future we have trouble or are unable to get installed. Another way to look at this is that heroku doesn’t entirely get us out of sysadmin skillset/tasks, when we need custom software installed.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.
deploying new code takes longer. to get a code change out after pushing button to do so, on heroku can take 3-10 minutes. On current infrastruture, only 1-2 minutes. Also heroku can involve either more downtime on deploy, or increased developer work to mitigate.
Loss of infrastructure-as-code. Currently theoretically our entire infrastructure can be re-created from zero from source code that is checked into our git repository. This gives transparency and change-history and reproducibility of our architecture. (“theoretically”, I bet we’d have trouble going from 0 to 100, but still a lot/most of it is in code).
The basic simple easy way to use heroku, we end up losing this. Much of the configuration is done via manual web UI on heroky (and add-ons), and isn’t captured in code in source control.
So, recreating it, figuring out what’s there, copying it, is a manual operation, involving looking through various screens in heroku and add-on UI to see what’s configured — assuming you still have access to it!
While there are potentially ways to use heroku to mitigate this, upon analysis they mostly look like they significantly increase the energy we’d need to put into heroku, without even getting us to 100% infrastruture-as-code. While we might explore some later, for now we think it makes sense to consider this just a trade-off, one of the things we lose with heroku. Heroku is simple enough, that we think it will be ok, with some mitigation from a small amount of manually maintained documentation. See more at https://github.com/sciencehistory/scihist_digicoll/issues/875
Some sense that heroku is stagnating a bit. There haven’t been new significant new heroku features in a while, or changes to some parameters (dyno sizes) that seem out-dated to us. We have a sense heroku’s current owner (salesforce) may be resting on the service they got, and we should not expect any new features or fixes or changes. However, the current system is pretty reliable and stable and relatively feature-complete, so we can handle that, at least for now.
...