
Photo credit: notsogoodphotography on Flickr - “hey son, get out of the clouds”
Way back at the end of February I blogged about the fantastic experience that I’d had launching (or preparing to launch) OpenIndie on the Engine Yard Cloud platform. That post received fantastic feedback from both other developers and Engine Yard staff and resulted in me being asked to give a testimonial for the Engine Yard site, which was very flattering.
In that post I promised to reflect upon the experience of deploying the site into the cloud with EY and also my feelings about the platform one month on. Sadly I wasn’t able to post this exactly one month after launch (on April 1st) as I promised. Development of OpenIndie and other business commitments such as preparing for DIY DAYS NYC have taken up my time. However, I did want to return to the subject and give you my thoughts after using the product for a reasonable amount of time.
Launch went incredibly smoothly. There wasn’t a single hosting issue to be resolved on the day. We launched the site, had to make some adjustments, specifically to our smtp settings, and then redeployed without a hitch. The interface is so simple, again not something that you normal hear a developer praise, however, in this instance I am the only developer on the project and I need to abstract my hosting concerns in the simplest way possible. This, I believe, is vital to a business with such a small team. If Rails sped up development of our site by 1.5x then Engine Yard Cloud has to have saved us the same, if not more, time in terms of hosting infrastructure.
That isn’t to say that we haven’t encountered any problems. Times where we did come up against issues were in no way attributable to Engine Yard. The key issue we came across was when using their experimental stack in order to utilise Unicorn. This was obviously our choice and a known, but measured, risk. In our testing Unicorn had performed very well but in the production environment we had some issues. Whenever we redeployed after pushing changes back to Github the site would start throwing Method Not Found errors.
This error then required a complete termination and restart of the instance in order to resolve the problem. As a relative newbie in the Rails world I began exploring issues with my own code but eventually tried the codebase on a different stack and discovered that using Passenger or Mongrel the site redeployed without a hitch. Hrm… time to start using a more stable stack. We switched to Passenger a week after launch and then after some further testing (after an Engine Yard deploy) we have now actually moved back to Unicorn, all inside one month. That’s how easy it is to test, diagnose problems and make decisions on EYC.
In line with their pre-launch service EY staff have been absolute rockstars, these include but are not limited to @ezmobius, @tmornini and @abheek. With any query we’ve had their team has replied instantly with clear concise advice. There have been a few frustrations with having to delay a deployment of our software because Engine Yard have been deploying theirs, but this is extremely minor. Likewise, we’ve been keen for a long time to use Ruby 1.8.7 and this was something that wasn’t previously available on EYC. However, two weeks after asking, low and behold a beta program with 1.8.7 became available to enable on your environment. Perfect!
I genuinely don’t have a bad word to say about Engine Yard, they have successfully created a product that is to hosting what Rails is the development. It makes our life easier, pure and simple. It’s developer friendly and takes a huge weight off my shoulders by managing our hosting infrastructure for us, brilliant!
Once again, OpenIndie hasn’t had a big fat cheque or any free hosting from Engine Yard in return for this praise, we just think they’re kicking ass and we’re extremely pleased with our choice of host!
Kieran Masterton
OpenIndie Co-Founder