views:

113

answers:

1

After a down vote, I humbly realized that my post was an enormous rant. So I've edited it and summed this down to just the question I'd really like to know. I apologize for my brash comments prior to this edit ;)

It seems that the only tutorials out there talking about using Amazon's SimpleDB in a rails site are using AWSDBProxy... Personally, I find this counter-intuitive to scaling out, considering the server layout of a typical Rails site below (using AWSDBProxy):

Plugin here: http://agilewebdevelopment.com/plugins/aws_sdb_proxy

Image here: http://www.freeimagehosting.net/uploads/91be4e0617.png

As you can see, even if we add more mongrels, we have two problems.

  1. We have a single point of failure far less stable than our load balancer
  2. We have to force all our information through this one WEBrick server

The solution is, of course, to add more AWSDBProxies... but why not then just use the following code in say, a class, skipping the proxy all together?

service = AwsSdb::Service.new(Logger.new(nil),
                                CONFIG['aws_access_key_id'],
                                CONFIG['aws_secret_access_key'])
service.query(domain, query)

So what I'm getting at, is if you are using AWSDBProxy, what are you justifications for it? And if you are indeed using it, what is your performance like? If you have hard numbers, this would be even more appreciated!

Thanks!

+1  A: 

I'm not using it, nor have I ever heard of it, but this is what I would think are reasonable reasons.

  1. You're running your main app server on EC2, so the chance of Internet FAIL doesn't really affect you more than once.
  2. You run one proxy on each of your app servers. So it's connection going down is no worse than it's connection(s) to the database going down.
  3. Because it can be done. This is as good a reason as any in an open source project. Sometimes it takes building a thing before you know whether said thing is a good/bad idea.
  4. You don't have the traffic levels to need a load balancer. Then your diagram squashes down to a line, if not a single machine.
Otto
All good reasonings. I guess I just don't like the idea of having to deal with internal web requests when in memory objects and simple classes will do. The only thing I didn't agree with is #4, since I was asking about scaling out :D But, a proxy per application server isn't so bad...
Keith Hanson
I'm going to wait to see if someone with some hard numbers posts, since that's what I'm most interested in. The ease of use is great, but I just feel that squeezing your multiple application instances into a single proxy server defeats the purpose, heh. Thanks for hte answer though!
Keith Hanson
Agreed, internal HTTP requests are almost certainly a code smell... aside from the HTTP proxy like apache or the load balancer. :)I worked on one project where they put an HTTP interface on every one of their EJBs and then rewrote them all to talk to each other over HTTP. That sucked.
Otto
Haha. Was this around the era of the buzzwords of Service Oriented Architecture? Because I worked for a company for one of my first programming jobs and they demanded that we build a webservice that accessed the database, and our data models asked the WS for the data, bahaha :D Indeed, smelly!
Keith Hanson
I might add that we never used the WS for anything else, hahaha. It was just "The Right(tm)" thing to do at the time *rolls eyes*
Keith Hanson