Live data from Hacker News

Rubygems.org AWS bill for Feb 2014 [pdf]

dropbox.com

61–70 of 153 posts

Re: Rubygems.org AWS bill for Feb 2014 [pdf]

#61
post #6

While one could probably knock a couple thousand bucks off that if one cared to (which is probably penny wise and pound foolish but invariably comes up in HN discussions of hosting costs), the amazing thing is that hundreds of thousands of people worldwide are able to use core infrastructure which costs less than the fully-loaded cost of a single billing clerk in your local municipal water department.

What is funny is that Github is footing the bill for most package systems, which were likely inspired by ruby gems, yet Github itself was built with Ruby gems. I am pretty sure the hosting costs for homebrew/npm round to nil (I could be wrong).

If you mean the npm homebrew package, then yes. If you mean npm packages, then you might be living under a rock.

Re: Rubygems.org AWS bill for Feb 2014 [pdf]

#62
post #50

I thought I'd answer some of your questions, as the person that pays the bill. 1. This can be cheaper on AWS. We've been meaning to move to reserve instances, paying a year at a time, for a while and simply haven't done it yet. 2. Fastly has already donate CDN usage to us, but we haven't fully utilized it yet as we're (slowly) sort out some issues between primary gem serving and the bundler APIs. 3. RubyCentral pays…

How have the costs changed in the last year or so? It would be cool to see a month-over-month graph.

Re: Rubygems.org AWS bill for Feb 2014 [pdf]

#63
post #53

Earlier quoted context omitted.

Do you know who are the biggest consumers of bandwidth? I would guess the CI servers (Travis, Circle)

A very good question. I'll see about crunching some of the logs to break it down by subnet.

Great. Whoever the major commercial users are have a financial incentive to keep the service performant. They should all at least be sponsors at some level if they're not already.

Re: Rubygems.org AWS bill for Feb 2014 [pdf]

#64
post #17

Earlier quoted context omitted.

Have you worked for Rackspace, Linode or Digital Ocean?

I've worked for one of their (direct) large competitors, but haven't worked for those three companies. I've currently got active accounts with all three of those VPS providers - I love them, and use them every day - particularly Linode, but also Slicehost/Rackspace, and DigitalOcean. I even have a bare metal server at ServerBeach - which I realize I need to shut down... At this exact instant I have six terminal windo…

But they are just using Amazon's Cloudfront. They aren't using SQS or anything.

What technology risk is there in setting up Varnish and nginx on Digital Ocean? Or better yet some kind of out-of-the-box open source CDN. You would save a lot more than $2-3k.

Re: Rubygems.org AWS bill for Feb 2014 [pdf]

#65
post #58
post #55

Earlier quoted context omitted.

Did you consider using a mirror network, with servers run by external organizations, instead of going with AWS bandwidth for rubygems? Seems like that would be a good approach for the static/bulk part of your dataset, and there are lots of companies and universities who are set up to serve software. (The mirror I manage serves about 50 TB/month for several Linux distros, and many sites are larger.) Do the work and in…

It's been discussed many times before, yes. Rubygems usage pattern by our users make any kind of mirror delay unacceptable. We currently run a number of mirrors, configured as caching proxies. I want to get us going on a CDN like Fastly soon because they provide effectively the same functionality but distributed to many, many more POPs that I will ever setup.

If it's just the sync delay, you could track each mirror's last-updated time and only direct users to a mirror that had synchronized with the master since the package in question was released. Otherwise, serve the content from AWS. Though I'm sure this couldn't beat the service that Fastly's donating.

Re: Rubygems.org AWS bill for Feb 2014 [pdf]

#66
post #50

I thought I'd answer some of your questions, as the person that pays the bill. 1. This can be cheaper on AWS. We've been meaning to move to reserve instances, paying a year at a time, for a while and simply haven't done it yet. 2. Fastly has already donate CDN usage to us, but we haven't fully utilized it yet as we're (slowly) sort out some issues between primary gem serving and the bundler APIs. 3. RubyCentral pays…

Do you know who are the biggest consumers of bandwidth? I would guess the CI servers (Travis, Circle)

I think that bandwidth consumed by Circle should be free, since we're also hosted in AWS. Maybe somebody who knows more about the details of Amazon's billing can confirm/deny.

Re: Rubygems.org AWS bill for Feb 2014 [pdf]

#67
post #10

The thing is there are many providers who can do the same and most of them will do it for less than half of this. Some less than 1/5th. I think they should move this to Digital Ocean and save $5000. The bias towards AWS for this type of application is ridiculous and a big waste of money.

I guess host it in AWS is a benefit for the integration with other services hosted in Amazon like TravisCI (the most popular CI for open-source Ruby projects) and Heroku (the most popular hosting for Ruby projects)

Re: Rubygems.org AWS bill for Feb 2014 [pdf]

#68
post #50

I thought I'd answer some of your questions, as the person that pays the bill. 1. This can be cheaper on AWS. We've been meaning to move to reserve instances, paying a year at a time, for a while and simply haven't done it yet. 2. Fastly has already donate CDN usage to us, but we haven't fully utilized it yet as we're (slowly) sort out some issues between primary gem serving and the bundler APIs. 3. RubyCentral pays…

How have the costs changed in the last year or so? It would be cool to see a month-over-month graph.

I'll put that on my todo list.

Re: Rubygems.org AWS bill for Feb 2014 [pdf]

#69
post #65
post #58

Earlier quoted context omitted.

It's been discussed many times before, yes. Rubygems usage pattern by our users make any kind of mirror delay unacceptable. We currently run a number of mirrors, configured as caching proxies. I want to get us going on a CDN like Fastly soon because they provide effectively the same functionality but distributed to many, many more POPs that I will ever setup.

If it's just the sync delay, you could track each mirror's last-updated time and only direct users to a mirror that had synchronized with the master since the package in question was released. Otherwise, serve the content from AWS. Though I'm sure this couldn't beat the service that Fastly's donating.

The caching mirror configuration achieves nearly the same thing. In the past, people have wanted to run their own mirrors that we directed people to, but that's got reliability and security issues.

Re: Rubygems.org AWS bill for Feb 2014 [pdf]

#70
Package Control is a far cry from the scale of RubyGems. PC uses a little over 2TB a month, whereas my calculations show RubyGems using around 50TB.

That said, early on I chose Linode because of their generous bandwidth that is included with the boxes. For the price of less than 1TB of AWS bandwidth, I get 8TB, plus a decent box. The bigger boxes have an even bigger proportion.

I'm not posting this to give any suggestions for RubyGems - I know nothing of the complexity of that setup. Mostly just figured I'd share the research I did for finding reasonably priced bandwidth.

Post reply on HN