EngineYard Solo – The Retrospective
So I just finished up almost 2 months of using EngineYard Solo as my hosting platform. I recently cancelled my account and moved back to a Linode VPS (720) and I am actually much happier than I was on Solo. I figured since there are no reviews of the service to be found, I would write one.
I originally demoed Solo at MountainWest RubyConf’s Hackfest. Ezra Zygmuntowicz sat me down and took me through all setup process, posted our hackfest application, and than gave a whirlwind tour of the other features in the Solo control panel. I was very impressed even given the deployment hiccups we encountered (but Ezra was right there fixing them as they came up, if only I got that one-on-one service everywhere! 
). I got the app running, played around with different configurations, Apache + Passenger & Nginx + Mongrel. I was blown away by how easy it was to roll out an entirely new configuration, and within 2 weeks, I cancelled my Linode slice and moved exclusively to Solo. Maybe I expected too much, but that is when fighting the control panel became a daily activity.
Since a basic EC2 instance has 1.7GB of RAM, I moved 3-4 applications over from Linode. The control panel for Solo is awesome when it comes to establishing gem dependencies, and different application configurations (Rack, Merb, or Rails), but don’t expect the nginx / apache configuration to be as easy. As a default, when you create a new application it will only create a vhost configuration like:
<VirtualHost *:80>
ServerName refactorme.com
DocumentRoot /data/refactorme/current/public
</VirtualHost>
This configuration works fine if your only hosting one application on your instance, but most people are not doing that (from other’s I know who also use solo). When you have more than 1 application running on an instance, and lets say you added refactorme second, and you visit www.refactorme.com, apache will route you to the ‘default’ or first application defined. This caused many headaches because I would have to manually login to the box, add ServerAlias www.refactorme.com, save, and issue an apache config reload. Not so bad, right? WRONG! If you ever change your configuration from the control panel, it is like your deploying a fresh instance, that configuration file you manually changed isn’t saved. This makes the main selling point of EY Solo completely useless when redeploying configurations actually causes more work. I reported this bug several times to the #ey-solo channel on IRC, but to no avail, it was never fixed. Somehow Flex and all these other redeploy features were added, but a simple task like defining an application to sit at a subdomain was never addressed.
It leaves a bad taste in your mouth to see new features being added that help make configuration and automated tasks being added only to see that you cannot use them since every deployed instance requires personal attention to add a mundane configuration change. Don’t get me wrong, the EngineYard Solo control panel is an excellent idea, but when your paying a $40/mo+ premium on top of EC2, but it can’t even get Apache configurations right, why would someone pay a premium to fight the control panel that is supposed to make deployment easier? Some may argue that EY Solo was intended as a staging box for testing and sharing apps between them, that would work fine if you only have one application running at a single time, but what happens the minute you need to QA two applications concurrently? Isn’t it supposed to mimic production, meaning that www.domain.com would point to the same place as domain.com?
June 4th, 2009 at 5:24 pm
I got around it by deploying a rack application as my default app. Kinda ghetto, but functional.
http://gist.github.com/110713
June 5th, 2009 at 6:16 pm
Hello Justin,
First off I want to apologize for the confusing way Solo handled multiple domains initially. We’ve been working hard on this and now support more than one domain/application per environment through the user interface. Which alleviates the counter-intuitive “reset switch” that would occur when you restarted an instance.
The way that Amazon EC2 works, every time an instance is created it has to be built from an Amazon Machine Image (AMI). Our custom AMI doesn’t have your configuration for each domain stored in it. So we rely on user input in the user interface to store the configuration for each domain so that we can rebuild the entire thing each time you boot an instance.
Here’s an article outlining the steps to configure this:
https://cloud-support.engineyard.com/faqs/using-engine-yard-cloud/configuring-multiple-domain-names-on-one-environment
This application is under constant improvement and unfortunately we disappointed you before this was fixed. We deploy on a weekly basis and we try to keep our customers in the loop about improvements, but this may not have been communicated to you in time.
Thanks for your compliments and the blog post!
PS. Linode rocks. I have an account myself and if you know what your doing, it’s a great service. If you don’t want to worry about it, we can help.