One thing - if you're outsourcing to a third party (not rackspace) for sysadmin, it would be much cheaper to just use a colo with 'bare metal' machines you order yourself - so why do you use rackspace?
We're a bootstrapped company and the initial capital outlay for servers would be a serious investment at this stage. Rackspace gives us access to hardware on-demand at monthly prices that fit our budget. In addition, we have a partnership deal with RS that gives us a discount on hardware. As we continue to grow, any of these criteria may change, at which point we will re-evaluate the situation.
We've had discussions about selling Haystack licenses before, but that requires a fair amount of work to get it in shape to do so. It's possible we will open source it someday instead. Nothing has been decided at this point.
Oh, okay. Do you think you could share some specifics of it at some point (in a blog post like your architecture posts perhaps) so that open source clones could be made?
So pretty technical question about the svn support. It's my understanding that the way svn does certain operations basically requires massive responses, and svn doesn't support chunked responses; how do you guys not blow up on RAM serving those?
we do basically just build up the response in memory (using a Rack::Response object), but the largest response is generally the size of the latest checkout, which is rarely very big, and only has to be there for a few seconds.
if it becomes a problem, we can figure out how to buffer it differently pretty easily by replacing the rack response object we're using, but i doubt it will come to that.
Perfect timing, I'm giving a ten-minute talk on BERT and Ernie tonight at the Buenos Aires Ruby Meetup, this is a good reference to point people to.