Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

We do not think the current situation, our infrastructure as we have it now but with no systems administrator position, is sustainable.

However Heroku isn’t the only alternative that could require less systems administration/operations work so be sustainable without a systems administrator/operations position. There are other possible routes we could take, here are some of potential interest. Most of them will be less expensive (sometimes very) but require more hands-on management than heroku (sometimes very).

  • hatchbox.io. Basically a Rails-focused service that sets up your AWS infrastructure for you, including postgres database, redis, Rails web and background workers (with horizontal-scaling and load-balancing). Also has a built-in system for distributing your config/env vars to all machines, like heroku.

    • You still have access to the underlying AWS, it just sets it up for you.

    • We’d still have to do Solr separatel, probably still with SearchStax.

    • Unclear how mature/complete it is, there are some things we’d need to do that it’s not clear to me how it would support, there would definitely be more manual hands-on than heroku, and probably require some custom solutions.

    • But it is much less expensive than heroku, $50-$100/month on top of the AWS resources you pay for yourself.

  • Stay on AWS, but with higher-level “managed” services.

    • We were using AWS in a very “basic” way, raw EC2 instances we installed things on, for instance install postgres ourselves on an EC2 as if it were our machine. Instead, amazon has a bunch of managed services, for instance RDS Postgres or ElasticCache Redis, where you just get a postgres.

    • Instead of raw EC2 for compute (web and dyno), we could try some higher-level Amazon offerings, such as “Elastic Compute” to give us built-in scaling and load-balancing.

    • Or better yet, probably “serverless” option like lambda, for which there are now solutions to run fairly standard Rails apps on. (Does require us to get into Docker I think!)

    • Price would probably be only a bit more than present; much more hands-on, someone would still need to devote significant time to operations, but it would at a higher level with many fewer details to be responsible for than current.

  • Stay on current infrastructure BUT with more support from part-time/contract help

    • Look maybe in our library tech communities for person or vendor that could contract with us on a retainer or as-needed basis to help us do operations things as they come up

    • Might start with a larger project to help us re-design/re-architect our current setup to be based on more contemporary best-practices and be easier to manage

  • Some complicated docker/kubernetes based solution, using a hosted kubernetes platform.

    • This is very trendy right now, but I don’t know much about it. Ostensibly would take care of many operational concerns, but I suspect it would end up requirement more time investment than in utopian portrayals, beginning with investment to understand what it really is and how to set up our app for it.