Engine Yard Cloud Reviews

Web-based software is becoming more and more service-oriented. You probably know about software as a service (SaaS – e.g. Salesforce) and infrastructure as a service (IaaS – e.g. Amazon) but probaby not platform as a service (PaaS). Companies like Engineyard and Heroku make it easier to launch and scale a web application. For the most part, you can setup an account, run a few commands for basic configuration and you’ve launched in the Cloud. This is an order of magnitude easier than it was just 5 years ago. If you just felt your heart skip a beat, please take a few minutes to catch your breath. When you’re ready, let me help you decide what platform to launch your next application on. Heroku is great for quick applications. The best Rails candidates I interview deploy their code challenges on there and send me a link. The smallest configuration on Heroku gives you a 5MB shared database and 1 “dyno”, their unit of measure for CPU. It’s free and you can even get add-on’s like New Relic performance monitoring thrown in. To scale up, you can pay more for dynos and a more powerful database. Setup is fairly painless, though I had to google for help when their “happy-path” documentation didn’t work exactly the way it was intended. The most annoying thing is that for the smallest configuration, the first request you make to the site takes 30-60 seconds to complete because their servers are dynamically provisioning you resources. Heroku hides much of the Operations side of things from you and that’s an intentional choice. It’s clear that they’d like to make the deployment process idiot-proof. I think that’s great for interview code challenges and school projects but if you’re serious about your application, you need to use Engineyard. Why? -- You need to be in control. -- Over the years I’ve seen EBS volumes become read-only all of a sudden, MongoDB refuse to resolve internal hostnames for a subset of instances, and even instances mysteriously become unreachable or “disappear”. Putting your servers in the Cloud has a huge drawback: you don’t have physical access to the hardware. When things go wrong–and they inevitably do–you need to have access. Since you’re saving money by not buying your own hardware up front and using IaaS, the next best thing is having as much control of your instance as possible. With Engineyard, you can ssh into every single machine and customize your own recipes. Essentially, they setup the default configuration but at the end of the day you can do whatever you want. For everything from Cron to Redis, I customize the configuration and understand exactly how processes are running. I analyze the CPU and memory usage and even the IO performance because I need to tune things like how many workers should be on each application instance. Control is critical when debugging issues. You’ll need to install custom monitoring and benchmarking to find out why your Memcached servers are maxing out at 80% memory utilization for example. -- You need expertise. -- PaaS is your world-class Operations team. Even if you hired one or two Operations people, it is unlikely they will be experts in all the technologies you’re using. Given that I’ve never used paid Heroku Support, I can’t speak to their experts, but Engineyard definitely knows their stuff. They try to cover as many areas as possible in-house and through partnerships, cover others. I know that they have a great in-house MongoDB presence because their team helped me with my Sharding migration. I’ve gotten DBAs from Percona to look over my slow mysql queries, advice from Durran Jordan of Mongoid over IRC, and just as I was looking into Neo4j for some graph-based projects, I heard that they were actively talking with Neo Technology about a partnership. When your application has a problem and Google doesn’t help, you can either call a really smart friend like a contestant on “Who Wants to Be a Millionaire” or you can leverage the collective expertise of Engineyard and their network. They know your application and infrastructure really well and you may be seeing the same problem as another one of their clients. This expertise model works and just makes sense. -- You need support. -- When you’re in the Cloud, you need someone to have your back. You can install a Heroku add-on like “Redis To Go”, but what happens when things break? As a engineer I’m pretty paranoid and rightfully so. I’m weary of things labeled “X to go” or “Y in a box”. Furthermore, I believe that if you’re going to use a technology in production, you should install it yourself. It’s critical that you develop a long-term relationship with a team that knows your specific application and infrastructure. When you read an email from Engineyard at 9am telling you how at 5am they detected a problem and brought your site back up without waking you from your precious 6 hours of sleep, you’ll know what I’m talking about. When it’s 3am and you’ve been wrestling with an issue that’s keeping your site down and your friends at Engineyard are still up and walking you through hell, you’ll know what I’m talking about. Heroku support may be just as good, I don’t know. But I’ve been in the trenches with these guys and I can tell you that whoever you choose, you better be able to count on them when the CEO is calling you to ask when the site will be back up. If you’re serious about your application, you’ll take these points into consideration and weigh them heavily against cost and hype. Engineyard’s worth the money. Disclosure: Badgeville is an Engineyard customer and so was Howcast when I was there

It’s worth pointing out that the middle ground between black box cloud hosting like Heroku and vanilla EC2 is Engine Yard Cloud. They give you a tested and scalable Rails stack with a web UI for management, but under the hood you still have root access and the AWS keys, so the billing is transparent, and you can install whatever software and use whatever instance types you like, which is useful if Heroku’s architecture doesn’t fit your load profile, or you need some piece of software that is not available or very expensive as a hosted service. Oh and of course they provide support as well.

#1 “Ease of Use” Heroku blows Engine Yard away. you install the gem and can deploy your application in minutes. There are also commands you can run on your local machine to get information about your application. Engine Yard is moving forward, but it is still pretty technical. It’s really easy if you have a public github repo, but anything other than that starts to get “more complicated” quickly. #2 “Architecture” Engine Yard gives you a “real” virtual machine. This means you’ve actually got a single CPU virutal host that you ssh into and effectively do whatever you want. Heroku gives you a sandbox with walls around it, and I think it’s a shared environment. It’s actually kinda difficult to figure out exactly what they’re running as you cannot log onto the machine direction. #3 “Startup Price” Heroku gives you a free (as in beer) environment. Engine Yard let’s you run a trial environment for free for a period of time, but you eventually have to pay for it… even if nobody ever visits your site. #4 “Flexibility” Heroku lets you do anything you want as long as they’ve preconfigured it to enable you to be able to do it. Engine Yard gives you ssh capability to the machine, which means you can do anytChing you want even if they didn’t think it would be a good idea. Overall, I’d say Heroku is like taking the bus: if enough people want to go the same place at the same time, it’s more economical. Engine Yard is like buying a car: it’s going to be a bit more expensive and you’re going to need to know how to drive, but it is a much more flexible solution. Cheers