More than it is sane or not, if you are not a sysadmin and will take care of it, you will become a sysadmin, real fast. Are you up to it?
:)
I might be missing the point here, but let me tell a bit of my experience being a ruby dude playing as sysadmin on amazon:
There is a lot of tricks that you need to do to run on amazon:
- The ELB (Elastic load balancer) on amazon is only a CNAME record, so you cant make yourdomain.com point to the ELB, so you will need to have one webserver with a elastic ip to have a .htaccess or reflection or whatever is the rewrite thing on nginx or unicorn. Plan for it so it doesnt bit you back.
As far as thin vs unicorn, it is a design strategy beyond amazon in this case. I never used thin but heard good thinks for long pooling connections comet style. Amazon should be just fine for long lived connections, IMHO. If you even want to go safer, you can use the sticky cookies to make sure the client browser sticks to only one server.
"Am I stepping into a quagmire of cost?"
Yes, it gets expensive fast on amazon.
"Am I stepping into a quagmire of maintainability?"
Yes and no. I was used to having the machines "with a few miles" where i could go and hit reset or replace a harddrive. On amazon, you need to be prepared to have one of your machines go stale, and you will have to reboot it. So you need to plan to either have a strong image and keep it updated or go for a chef or puppet thing to manage your servers (and go crazy, that is so hard to get it setup, took me a month, but I did learn from 0 )
"Am I stepping into a quagmire of performance?"
Remember that the disk io is far from ideal, so DB for writes gets slow if your database does a lot of writing, definitely do simple trial to make sure the speed is good enough. And also, you will have to use EBS for database files.
The processor speed and memory are pretty good. I wouldn't worry.
And also, I would go bigger instances before going horizontal on many small instances, unless you plan to run out of ports because of those long pooling connections. If you want to have better performance, it is cheaper to scale vertically until you hit xlarge, instead of spinning tons of machines.
"Am I stepping into a quagmire of maintainability?" --- again
If you have a ton of small machines you want to elastic bring machines up and down, and it is a hassle to do it.
If you want developer friendly, i would go with EngineYard and check if you can deploy with their service. It is worth it.
Please feel free to ask questions!
Best Answer
I figured it out. In the location section of the nginx configuration file, I had to add two additional proxy parameters: