Can anyone recommend a Rails VPS host that offers everything pre-configured (like Heroku) and just let's you upload and run your app? Heroku becomes expensive really quick as you scale up.
If you want a VPS that is pre-configured, you can try something like these
http://www.turnkeylinux.org/rails
http://bitnami.org/stack/rubystack
and then uploaded it to a VPS provider. I would recommend Linode.
Any service will become expense as you scale up - if you want cheap the likes of Slicehost, Brightbox (UK) offer vanilla VPS boxes but you're going to be setting stuff up yourself and sacrificing scaling. Maybe have a look at dotcloud.com - little more reasonably priced TBH than heroku
If you're looking for cheap hosting then a vanilla vps is very easy to set up. Check out the tutorials at http://articles.slicehost.com/. It's a really satisfying experience and good to know if you're a developer.
I read a lot that heroku is expensive but one free dyno plus a shared db at $15 will serve a lot of pages. Utilising varnish more so.
Depends exactly on what you want. Heroku is a great Platform as a Service offering. This means that they take care of administering the database, app server, etc. In turn, they are a bit more expensive as you scale and have restrictions on what you can and cannot run (to make it possible for them in turn to scale their operations)
If what you are looking is your own VPS, but with everything already setup, you can use BitNami (as pointed out in another answer by #Dex). We recently released BitNami Cloud Hosting, which has a free tier and together with AWS free offering allows you to have a Ruby On Rails environment running on a small machine (600 Mb of RAM, 10Gb disk) completely for free. If you need to scale, then you need to pay for Amazon charges, etc. This is great for starting out. Check it out!
Related
I have been using Heroku up to now, but need to offer something more "enterprise-y" to an organisation that would otherwise insist on local server deployment.
AWS VPC sounds like the ideal infrastructure to use. I'll have Rails + Postgres + AWS S3.
Maybe a silly questions, but is there an automated PaaS that runs on top of AWS? Such that we own the AWS account but can outsource the server admin side? Or is this just a case of having to hire a consultant and deal with upgrades etc. as they arise?
is there an automated PaaS that runs on top of AWS?
Yes, there are LOTS of them. They range in spectrum from "a thin layer on Elastic BeanStalk" to wanna-be Heroku clones. (From my experience, most don't think about HA enough, so it works great, but has plenty of Single Points of Failure that can bite you down the road. But maybe you don't need so many nines of availability at first. Anyone remember Twitter in the early days?)
There are plenty of points in between, such as EC2 Containers, OpsWorks, Flynn, CoreOS, etc. Even Empire which I haven't looked at yet.
Every PaaS is a "Straitjacket" that reduces your "freedom to do anything" in exchange for "simplifying some things". That trade-off is not a constant, nor universal.
A PaaS that works for one company may not work for another, or even the same company six months later. I frequently see companies use Heroku or Google AppEngine for months/years, then suddenly hit a wall and need move off of it. After, they wonder why they put up with the limitations for so long.
we own the AWS account but can outsource the server admin side?
Yes, you can easily pay someone to setup a "PaaS" for you. The problem is they have to have a lot of knowledge to know which one will work best. (Few people have tried them all and talk intelligently about the trade-offs between them all. And new ones get written practically every day.)
The one universal thing: Companies rarely outgrow AWS. (Remember Zynga? They thought they were "spending too much money" on AWS, so they built their own datacenter. It supposedly "saved them money" until their fortunes turned around. Then that datacenter became a boat anchor that pulled them under. Ooops.)
Or is this just a case of having to hire a consultant and deal with upgrades etc. as they arise?
You need to think deeply about what it is that you want.
You could stay high level and run on a 3rd party PaaS. There are no shortage of them (Engine Yard, Heroku, etc). You trade a bit of extra money now (and it's really a few bucks per month) for speed. But you pay a cost later when you have to move off. That's OK, as long as it bought you some time to prove your business model, get customers, etc.
You could hire a consultant to build you a PaaS on AWS. (Why? Is it merely to save money? To gain flexibility? How will you know they are competent? How do you know they aren't a one-trick pony building the same solution they built for everybody else, without knowing where it will work and not work?)
You could bite the bullet and hire (or grow) a cloud guy. They learn AWS and iterate. This will give you the most flexibility in the future. You will be prepared to take advantage of cost savings offered by tuning your application to AWS. (A generic PaaS doesn't encourage you do to this, which means you will loose out of performance or cost savings.)
Long term, I think only the last one makes sense. The 3rd party PaaS is also a fine way to gain speed in the short-term. I'm not so keen on a consultant, unless it's to help accelerate knowledge transfer to your company.
I know this is a topic which is very delicate however the simple question is.... has anyone uploaded a rails app using godaddy.com and if so how did they do it. I'm literally clueless. This is my first time. I cannot use anything else due to my clients choice.
If you're looking for shared hosting, Heroku is your best bet. Although you will need to make some minor modifications to your application to fit this environment, the benefits are considerable.
I would not recommend using regular shared hosting, which is primarily intended for PHP applications, for Rails. You need a VPS at the very least, and if you're not prepared to manage this, you need a managed environment like Heroku or you'll end up in serious trouble.
For small scale or hobby projects, a 512MB VPS is usually sufficient to get started.
If your client is insisting on GoDaddy, Rails may not be a good choice for you. It does seem possible according to the documentation but you need to have the correct account type.
We have a very simple function (We look something up from a third party database and return an answer. It's literally five lines of code.) We would like to offload this task from our main server because we expect a high volume of traffic for this one function and would like to optimize it.
We are thinking about testing the promise of many cloud/PaaS providers, where they handle scaling and performance responsibilities.
We're most interested in Rails environments, but are curious to hear experiences from others about any company in the space.
Here are the PaaS companies we found that supports Rails:
1) Heroku
2) DotCloud
3) Duostack
Questions:
1) Do you know of other Rails-specific companies? Also feel free to list non-Rails companies since we're interested in following other companies in case they eventually provide Rails support.
2) How has your experience been with these companies?
Foreword and disclaimer: I work for DotCloud; so the following might be biased. You've been warned.
DotCloud could be interesting for you if you like the following features:
run something else than Ruby (what about some Django or Pylons code talking with your SQL DB? Or even some PHP blog like WordPress or Drupal, using the same user authentication database?)
experiment with databases like Redis or MongoDB, or background ruby workers, without paying for add-ons
SSH access, crontab access (without requiring an add-on)
cheaper workers (I didn't come up with this one; some of our users coming from the Heroku world told us that workers were insanely expensive there)
Duostack is indeed very nice if you want to mix specifically Rails and Node.js. I've been told that they had awesome auto-configuration facilities.
Finally, if you only plan to do Rails and nothing else, ever, you might as well stick with Heroku since they've been in that business for a while, and are probably more mature than the first two of the batch.
Shameless plug: DotCloud is offering a beta test drive; so if you want to see what it looks like, just subscribe to the beta and you will be quickly enough be able to see for yourself. Heroku has a free tier as well.
You could add EngineYard in the mix - but i'd be inclined to use Heroku as my first choice, Dotcloud second (it's a newish product, and is very good but still in development)
If you want more control over your app/servers or want to run it on any cloud or your own infrastructure without having to download/deploy anything, you can try Cloud 66 (www.cloud66.com)
Disclaimer: I work for Cloud 66
A lot has changed on the scene since this question was asked. We recently looked into these services and settled on Heroku, but even more recently decided to continue managing my own deployments directly on EC2. Here are some points not mentioned in the other answers.
Heroku
Now supports much more than just ruby
Has really great-looking support for PostgreSQL
Uses LXC for process containers, like DotCloud
DotCloud
Is now Docker, and is putting a lot of manpower into developing docker.io
Doesn't have a free tier any more
I'm not sure if DotCloud is using Docker internally or not, since the docs say explicitly it isn't production-ready yet.
Our decision to stick with plain EC2 was motivated by the fact that it's cheaper and affords a lot more flexibility. For example, we use local-only http servers behind our public server to do some of our request processing, which doesn't really fit into the PaaS models out there. We would have had to reimplement all our back-end components as redis workers, and pay for them as additional dynos. The fact that Amazon RDS now supports PostgreSQL was also a compelling factor. Incidentally, Amazon has a full-stack PaaS offering as well, Elastic Beanstalk.
Just stumbled upon the question. There are similar ones around here. The problem is also: The PaaS scene is changing very quickly. New vendors are popping in every week or so.
Nowadays OpenShift from Red Hat might also be mentioned here as a Ruby PaaS.
OFFTOPIC + shameless plug: I have compiled a list of PHP PaaS here: http://blog.fortrabbit.com/comparing-cloud-hosting-platforms/
I have 4 servers behind a load balancer and a staging server, a db server, and a utility server for a web application that hosts a number of web sites.
Should I make the jump to Chef to manage these servers or should I just maintain them manually? The servers were built using sprinkle but at that time there were only two. Now that there are four maintenance is becoming more of an issue.
I'd like to hear experiences and the pros and cons of chef and other chef-like tools.
Thanks!
We moved to Chef, and we now have a 1 minute redeployment for our app. So it certainly pays off.
However it took a long time (a few months) to get to the point where we were happy with the chef deployment strategy. With hindsight we would have had several spare boxes around to try out a 'from scratch' deployment. I certainly wouldn't advise trying chef in a production environment without an exact mirror of the setup and lots and lots of tests, nor would I advise using chef on a setup that hasn't been 'cheffed' from scratch.
Having said that, Chef is far better than the other options we looked at and now that we are out the other side it's a breeze deploying a new version of the app on multiple servers. In future I'll be using it for any staging or production environment I have.
In summary, yes, but only if your client/employer is aware that it may take some time before they see the benefits, which will be considerable.
Chef has a steep learning curve, so it will take a while - at least a few weeks - to become familiar with how to use it.
But once you pick up the basics, it is a very handy system, and can simplify any number of tasks - even for the smallest of infrastructures.
A few notes for when you start.
You will be setting up and tearing down cloud servers dozens of times, just to get the hang of it. Experiment.
The standard opscode cookbooks (github.com/opscode/cookbooks) are very useful. But you will need to extend/customize many of them for your particular case. And you will need to search the 'net for cookbooks that are missing from the opscode/cookbooks repository.
Read the opscode cookbooks, and read the 37signals cookbooks too.
The application and database cookbooks are geared towards standard Rails apps with MySQL and Memcached. To the extent that this describes you, you are way in luck.
I've used straight Mongrel, I've used Mongrel clusters behind Apache, I've looked at Thin, and I'm becoming very intrigued by Passenger. I've looked at Nginx, too. I've looked at MRI, Ruby Enterprise Edition, Rubinius, and JRuby. There are a lot of options, each claiming to be the new holy grail.
What is the best option out there for a brand new, fully up-to-date deployment? The only assumptions are this:
The app is Rails 2.2 based. (I know 2.2 isn't fully released yet, but neither is this deployment.)
The server is Linux-based. Probably Ubuntu Hardy, but really, whatever works best in this case.
Rails will need to be fully functional and probably talk to a MySQL database.
Everything else is negotiable.
Given these especially broad constraints, which combination of software will yield the best result, in terms of concurrency and low overhead?
I'm leaning toward Apache with the "worker" mpm and Passenger + Ruby Enterprise Edition, simply because it offers immediate stability and simplicity of setup and maintenance.
Am I likely to be particularly better off with another option?
I switched from Mongrel Cluster to Passenger two weeks ago (Debian Linux Server). I didn't look back for a second. Passenger is probably the easiest way to get your new server up and running. Performance and reliability are reasonable too.
Personally, I like to spend my time working on exciting new Rails projects rather than dealing with deployment issues - Passenger enables me to do exactly that. However, Mongrel or something else may still be preferable if you have some kind special requirements (doesn't apply for most products).
This morning, DHH talks about this very topic on his own blog:
But somehow the message of Passenger has been a little slow to sink in. There's already a ton of big sites running off it. Including Shopify, MTV, Geni, Yammer, and we'll be moving over first Ta-da List shortly, then hopefully the rest of the 37signals suite quickly thereafter.
So while there are still reasons to run your own custom multi-tier setup of manually configured pieces, just like there are people shying away from mod_php for their particulars, I think we've finally settled on a default answer. Something that doesn't require you to really think about the first deployment of your Rails application. Something that just works out of the box. Even if that box is a shared host!
http://www.loudthinking.com/posts/30-myth-1-rails-is-hard-to-deploy
Tobias Lütke on the topic of switching Shopify (million requests/day) to Passenger:
All this means that the total amount of memory that is used by Shopify during normal operations went from average of 9GB to an average of 5GB. We evenly distributed the savings amongst more Shopify processes and more memcached space which moved our average response time from 210ms to 130ms while traffic grew 30% in the last few months.
In conclusion: I cannot see any reason to choose a different deployment strategy at this point. Its simple, complete, fast and well documented.
http://blog.leetsoft.com/2008/11/15/passenger
We've been using the old standard nginx -> mongrel stack for the last 18 months, and although it was not trivial to set up the first time around, it's proven flexible, and has dealt with some very high traffic sites for us. Nginx in particular has been absolutely rock solid and fast, and if you can get your app page-caching you can deal with a lot of requests.
Stuck mongrels have been an issue, so we use monit to kill them when they misbehave. Again, it was not totally trivial to set up, but we've used the same process on many many sites at this point.
We haven't played with passenger yet, so perhaps it's easier and more stable, I'll defer to the other responders on that one, all I can say is that there's no reason at all you can't build a solid stack with nginx and mongrel.
We have switched fron NginX+Mongrel to Passenger.
I fully believe that Passenger is going to be the new standard for rails, despite NginX and Mongrel cluster being endorsed by some very smart people. Recent advances in Passenger have really propelled it forward.
Our current configuration is something like this:
Web servers
Ubuntu 8.04 LTS
Phusion Passenger on Apache2
MRI Ruby 1.8.6 and friends (form apt)
Ruby Gems 1.3.0 (Installed from source)
Database servers
Centos 5
MySQL Cluster (we just switched to this, but it is promising)
Having standardized on the exact linux distro we've been able to write Capitrano recipes to help deployment (slight variations in configuration have been the source of MANY service outages) and otherwise simplify our lives.
Have a look at Litespeed. You can get a free version that runs on 1 cpu or pay to get multi cpu. It is a bit expensive but is rock solid and handles rails brilliantly (i.e. uses less memory and is less of an overhead to monitor and setup). I run a massive amount of apps on it and it doesn't miss a beat.
We also switched from Mongrel to mod_passenger and found stability greatly improved with this effort required to setup and maintain. Good choice.
Another bit of gold:
Josh Peek's Slicehost gem is full of Capistrano recipes that are much simpler and much more organized than Deprec. Nothing in there is especially Slicehost-specific, either.
I'm hosting my new apps with Apache2 and Passenger on Ubuntu Hardy. Seems like the easiest and best option for most scenarios. I have just joined Slicehost.com for that purpose. They seem to get good reviews and have the most competitive prices of first class hosts.
I can't really endorse them yet because I'm a new client but the set of guides and range of support options is impressive.
What you are not mentioning is how large and popular your app is/will be. This criteria could affect the decision process.
Capistrano + Deprec for actually setting up my stack on Ubuntu and physically managing the deployment.
Nginx proxying to Mongrel clusers for the server architecture. It isn't the newest, bleeding edge technique but it works well, it is getting well-documented, and it is very, very high performance even when working on small VPSes. Assuming you haven't borked the application you can Slashdot a 128 MB Slicehost VPS and it just keeps coming back for more.
Having said that: there were a lot of gotchas the first time around, until I figured out how Nginx actually worked. After that its amazing -- like a little Apachelet with a slight Russian accent.