The Hydra Production Stack

I was at Case Western Reserve University last week leading HydraCamp.  Many of the folks attending were from institutions new to Hydra and eager to get repositories up and into production – and they had lots of questions about setting up Hydra in production environments.   As we progressed through the development content that the course covers, it became clear that the Hydra community hasn’t spent as much time describing the production operation of Hydra nearly as well as we have covered development topics.

Once you have a Rails development environment setup, the instructions in the Dive into Hydra tutorial will get a development environment up and running in less than a morning (as proven by our HydraCamp attendees!)  Our typical development environment  simplifies many setup and configuration decisions by relying on a handful of useful rake tasks and the installation of hydra-jetty which provides a pre-packaged java server with Solr and Fedora pre-installed and configured for development environments.

In a production environment, simplifying assumptions made for development environments aren’t appropriate.  When outside systems and support staff get involved in your project, they will want to understand all the parts involved.  As I looked around the developer and project wiki, I realized there wasn’t much that spoke to the large set of moving parts involved in a production environment.  So in the process of starting to try to answer the questions folks were asking, I thought I’d try to write down what I had floating around in my head so far:

SYSTEM STACK represents the hardware, operating system, and core resources that systems and support folks often have strong opinions about, especially in regards to installation, patches, and operational support.

RAILS STACK items are things that are driven by Hydra, Rails, and your local development practices.  This part of your production stack is probably driven and governed by your development team as much or more than your production support team… unless you have a true DevOps model in place (if you do, we’d love to hear how you got there!)

OPTIONAL MODULES fill in the gaps between your core infrastructure and your Rails application. These are mostly linux utilities and rails gems that give you access to system tools and resources from within your rails apps.  They might include file characterization and rendering utilities and/or authentication and authorization libraries that help Rails talk to the rest of your environment.

Even this picture isn’t complete:  “Hardware” encompasses a lot of detail all by itself – disk and memory size, processor cores, network configurations, etc.;  “Bunder & Gemfile + Dependencies” encapsulates a lot of complexity; nearly every bullet point requires some time and effort to install correctly.  So, even though the slide isn’t exhaustive, it gave us a place to start talking.  And I think we began some good conversations.  We’ve been doing a lot of thinking at DCE about how to make Hydra deployment easier and more reliable and we plan to share more of our thoughts and ideas as they evolve over the coming months.