Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rubygems.org AWS bill for Feb 2014 [pdf]

dropbox.com

Post reply on HN
Print view View original

101–110 of 153 posts

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

#101

Post by jtrtoo »

jtrtoo wrote: post #100

Since it can take a bit of time to read through the invoice, here's a summary of the bill: CloudFront $1,071 Data Transfer $3,597 EC2 $2,184 S3 $ 228 While "bandwidth" costs equate to ~$4,668/month, only $1,071 is CDN (CloudFront), with the balance just raw Data Transfer. Since lots of folks are commenting, and not everyone realizes the difference it's also a good time to point out the CloudFront vs. Data Transfer di…

Is any of this good/bad/right/wrong? I have no idea. That depends quite a bit on what THEY are doing with it and why. For example, it can be cheaper to distribute from CloudFront versus straight from S3 for some use cases. Though, generally, you are not only looking at using CloudFront to save money over S3 ...there's typically a performance reason.

And sometimes the hosting costs simply don't matter. It's easy for us engineers - siting here on HN - to sit at our keyboards and play around with hypothetical ways to save money. This isn't necessarily a bad thing, but there are numerous things in IT that it doesn't make sense to optimize. Why? Because the ROI on the engineering time, CapEx, and OpEx (and the time, energy, and focus of ANYONE involved or impacted at all) to do the optimization doesn't outweigh the opportunity cost.

Sometimes there are simply better uses of our limited capital and time.

Not everything needs to be optimized. And the argument gets stronger when there are other factors more difficult to factor in: adopting a platform that isn't as widely known or isn't backed by a similar level of maturity (even with it's quirks, at least they are well known), etc.

The risks/concerns not only vary between organizations, but often from one period of an organization's growth to the next. The beauty is every organization gets to make their own decision ...and none of them have to give a damn if the HN community agrees or not. :-)

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

#102

Post by [deleted] »

evanphx wrote: 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…

[deleted]

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

#103

Post by hurrycane »

We run into the same cost-related problems for our CDN. What we did to solve it was to rent dedicated servers that are near AWS regions. We used Route53 latency based routing to route traffic to that dedicated servers + Nginx + LUA. We're serving 300+ TB of traffic per month and the total price is just a percent of the RubyGems AWS Bill. There is some maintenance included with this solution and the problem is finding the right dedicated server providers.

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

#104

Post by newobj »

stickydink wrote: post #15

Right now we're a top 25 grossing iPhone game developer. The last AWS bill I saw was January's, a little under $200k. I'm not on the server team, so I don't know exactly what contributes most to it. But part of me really thinks it could be reduced!

I love that you qualify it with "right now". Applaud your anti-hubris, stickydink.

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

#106

Post by michaelt »

sitkack wrote: post #79
evanphx wrote: post #69

Earlier quoted context omitted.

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.

Mirrors shouldn't be a security concern, the signatures of packages should come from "headquarters", same goes for reliability, clients should be able to, and SHOULD pull from multiple sites simultaneously.

Even if package signing works perfectly, when I connect to a mirror and request a patch for foo, the mirror learns my IP address and the fact I have an as-yet-unpatched version of foo.

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

#107

Post by vacri »

saurik wrote: post #11
incision wrote: post #9

At a glance, this looks like AWS being used like a dedicated host, which as demonstrated, isn't exactly cheap. There's no spot or even reserved pricing, just a bunch of on-demand instances that were up 24/7 for all 28 days in February. Seems like a genuine dedicated host, reserved instances or an architecture that leverages the elastic in elastic compute cloud would be worth considering.

A lot of the price is bandwidth. They are effectively being reamed by using CloudFront instead of negotiating a better rate with a "real" CDN (which will also give then much better performance, as CloudFront doesn't have many edge locations). (Although, actually, while I verified their total dollars spent is greater than what would be required to get a fundamentally better deal on bandwidth, I didn't take into consid…

CloudFront doesn't have many edge locations

This is nonsense. They have more edge locations than most. I didn't try all comparators in the list, but out of half of them I tried, none had more than Cloudfront: http://www.cdnplanet.com/compare/cloudfront/maxcdn/

So if Cloudfront has 'not many', who has 'many', and how many is that?

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

#108

Post by jasonkester »

grey-area wrote: post #98
evanphx wrote: 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…

It would be really interesting to see the bandwidth broken down by gem - I suspect rails would be at the top, but it'd be interesting to see. If most of the installs are on servers, have you considered talking to server providers about setting up internal mirrors on their networks? That might save everyone a lot of bandwidth. Of course, people shouldn't really be installing their gems from ruby gems on servers anyway…

Hey, a chance to plug my thing!

I built S3stat (https://www.s3stat.com/) to fix this opaqueness that comes with using Cloudfront as a CDN and get you at least back to the level of analytics you'd get if you were hosting files from one of your own servers.

RubyGems guys, if you have logging set up already, I'd be happy to run reports for all your old logs (gratis, naturally) so you can get a better idea of which files (and as another commenter wondered about, which sources) are costing you the most.

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

#109

Post by fivethree »

duaneb wrote: post #8
patio11 wrote: 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.

> which costs less than the fully-loaded cost of a single billing clerk in your local municipal water department. To be fair, a lot of maintenance value goes into the software that is never quantified. Broken software breaks hard, not partially, so maintenance is even more crucial.

When a levy breaks people die. Software maintenance and damage is nothing compared to real engineering.

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

#110

Post by NKCSS »

ksec wrote: post #92
driverdan wrote: post #78

Earlier quoted context omitted.

Having volunteers spend countless hours to setup and maintain their own CDN is a preposterous idea.

Here http://psyphi.net/blog/2013/12/content-delivery-network-cdn-... I have 10 fingers, so that is definitely not "countless" hours of work. And No, Maintenance are minimal or non existent. You could even get smaller VPS behind each node balancer as HA. Since Linode VPS ( Unlike DO ) are deployed on physically different hardware. While i say it is fair enough to use AWS because money doesn't matter, i thought there a…

Loved the blog posting :)
Post reply on HN