This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.

Engine Yard Cloud for complex application deployment

updated over 7 years ago; latest suggestion over 7 years ago

I've managed a large distributed application on Engine Yard Cloud for several years now and developed a lot of insight into the strengths and weaknesses and best practices for long-term maintainability of an app. A rough outline of what I think could be most useful:

Why choose Engine Yard Cloud?

How EY Cloud fits in with Heroku, vanilla AWS, VPS/managed servers, and colocation. What are the costs and flexibility tradeoffs?

Brief architectural overview EY Cloud

Explanation of the basic moving parts with a focus on what lives in the EY layer and what the developer has access to.

Customising your environment with Chef recipes:

The meat of the talk will be about how to set up your environment to spec:

  • Evaluating what EY gives you out of the box
  • Getting access to early release features
  • Using semi-official recipes from EY's public repo
  • Writing your own recipes from scratch
  • Avoiding conflicts between your custom recipes and EY's builtin stack
  • Best practices for recipe maintenance

Workflow tips tips and tricks:

A grab bag of reference material to improve development, maintenance and debugging of EY Cloud environments cobbled together from experience:

  • Running chef recipes on a single instance
  • Clearing red instances preventing deployment
  • Inspection of EY Cloud internal data

The future of EY Cloud

Engine Yard is just introducing a new cluster technology that greatly increases the flexibility of the platform, particularly for multi-app service-oriented architectures and distributed systems.


  • The proposal author responds over 7 years ago

    At least part of the talk will be a general comparison, so this would be useful for anyone looking at all the options.

    The part about custom chef recipes and some of the architecture talk would be more broadly useful as well since chef is a tool you might use on any cloud, VPS, dedicated, or even development environments.

    One of the reasons I wanted to keep it more focused on EY is simply because I don't have any experience with setting up chef on a vanilla VPS, however a lot of the decisions and architecture of EY are relevant to a wider audience since it is a fairly open platform on top of Gentoo Linux on AWS. That is to say, a lot of the architectural decisions could be ones you would make yourself if building up your own Rails environment on AWS. You get root access so it's not a black box like Heroku and thus everything is a bit more widely applicable.

  • Acd62030df551952268e84c8fff26a5b James Adam suggests over 7 years ago

    I suspect the focus on a specific, relatively expensive hosting provider is going to make this presentation less relevant for a lot of people. For example, if I'm not considering hosting an application on Engine Yard, is this going to be interesting for me?