Hacker News Reader

Comment by dboreham | Hacker News Reader

It has always been the case that owned metal is much cheaper than cloud. Cloud wins for things like very small machines (you can't buy 20% of a metal box); temporary deployments; and startups where the investors don't want to be on the hook for big $$ capex that they end up needing to shift on eBay post flame-out. Also where you just don't have the ability to run hardware (increasingly the case) and where for whatever reason the cost to deploy and run metal would add up to more than your $70k delta (easy if it needs one more person on staff).

Also remember that funky storage card may have a firmware bug that costs you hundreds of hours to track down and get resolved. That time could have been burned by Jeff Bezos' guys instead..

View on HN

I never understood this. Just rent a dedicated box or ten. There's no capex, it's way cheaper to have 3-5 times the capability you will need just sitting there instead of renting stuff from Amazon with all the I/O unpredictability, complexity, w/e. People talk as if colo and cloud is the only solution -- and I am like, rent dedicated is the only solution. I do not readily know how huge your site needs to be for colo to worth it but Examiner was ~75th on Quantcast and we ran it on a dozen dedicated boxes and colo would'v been ridiculously more expensive.

Renting a dedicated box doesn't have that cool "we can scale INFINITELY!" vibe. ;)

YAGNI.

Exactly. The only time the cloud services really pay off are when you need to scale up or down massive capacity overnight. The odds of that happening at most companies are very, very slim, even most of the web companies.

If you're really concerned about that though, I'd say go for the cloud option - just make it so you can start small on a single physical server, but can scale onto the cloud, then migrate that to physical hardware as needed. With this set up, you save massive cash and avoid vendor lock-in.

Or if you are a team like mine that develops/manages 200 servers, 15 RDS database instances, 500 TB of compressed S3 data, and provides accessibility to all of that through API's with only 5 developers because of how easy AWS makes it for us.

While our server costs are probably higher than going bare metal, how many developers would it take you to manage all of that on bare metal hosts?

The expense of one's outlay to Amazon is not a persuasive statistic. It only shows that you have a lot of incentive to keep confirmation bias in gear.

AWS is specifically designed to maximize instance count (that is, cost). The reason "devops" has exploded since EC2 hit critical mass is that before EC2, people were reasonable with the number of servers they needed. With EC2, it's all water, and it's so easy to press "create instance" that people just do it without thinking, and wonder how they ended up paying Amazon $100k/mo for something that used to cost them $5k/mo.

I'm engaged on a project now that has similar figures to what you've quoted here. It could be done with less than two dozen bare-metal servers. I know because it was done with less than two dozen bare-metal servers before someone in the C suite felt left out and suggested some "modernization" via the cloud.

I think that cloud zealots are mostly people who were either deathly afraid of sysadmin or people who were cutting their teeth as cloud got hyped, because there's no way any competent person who was doing this type of stuff before 2008-2009 can pretend that Amazon is not laughing all the way to the bank.

This is not to say that cloud has no advantages or that its use is always inappropriate, but what you're describing is pure fantasy. Yes, a small team of coders should be more than capable of managing the servers that they need, especially if they are renting dedicated boxes from a professional datacenter facility that handles hardware swaps and similar failures for them.

Our EC2 costs are about the same as S3, RDS is the most as I forgot to mention the backup servers we have in each region but we are trying to move all of that data to S3, and more than our SQS costs.

I'm pretty new to the backend design cost/benefit (have only used AWS since I graduated college) but I'm curious to here about bare metal storage solutions for 500 TB of compressed json as I have not read any compelling solutions for that data requirement (Outside of MongoDB but I have heard good and bad things about that).

In 2017, 500TB is easily within the realm of colocated bare metal.

There are many build it yourself options, which would involve things similar to this SuperMicro JBOD [0] + some other servers/external RAID controller to handle distributions over the disks. You could also go really barebones and do a couple of home-built "RAIDZilla"-style devices. [1]

For the cost of one month's S3 storage, you can buy a pre-built Backblaze Pod from a third-party supplier [2]. I've found this to be the case with Amazon; the monthly cost is about 50%-100% of the permanent cost for the actual hardware (which will usually last at least 3-5 years). Even if you have to hire a couple of your own hardware jockeys, you're going to be saving 6x.

For a less DIY route, any SAN provider will be able to accommodate 1PB (for redundancy) without breaking a sweat. Of course, this will be a large upfront expenditure, but it should still easily be cheaper than S3 over the long run. There are tons of options and storage engineering is a big field. Look around and I'm sure you'll find something acceptable.

-----

All this said, I really have to be skeptical that you need 500TB of (compressed!) JSON data. I would look into how much of that data you really need to keep, set up some retention policies, and seriously consider reworking your storage format to make these numbers more reasonable (JSON is obviously not space-efficient), which will not only greatly reduce infrastructure costs but also make the project much easier to handle.

You may also wish to look into modern compression codecs if you haven't already. LZMA provides the best ratio but the compression cycle is slow (decompression is fast). Brotli and zstd are new compression options that are at least comparable to gzip in ratio and much faster. Data deduplication should also help.

[0] https://www.cdw.com/shop/products/Supermicro-SC417-BE1C-R1K2...

[1] https://www.glaver.org/raidzilla25/

[2] https://www.backblaze.com/blog/open-source-data-storage-serv... (estimates cost of third-party pod at $12,849.40; S3 cost calculator says 500TB of storage in us-east-1 is $12,407.17 without any bandwidth, request costs)

Grab small servers with one or two big disk (Hetzner will give you two 4TB disks for 39.00 EUR, OVH one 6TB for about 30 USD w/ an ARM CPU, less than 50 USD for two 4TB under the soyoustart brand), serve them over iSCSI, use RAID-Z3 to create a nice huge ZFS filesystem. Do not forget to have hot spares. Done. Costs about half or even third of what S3 costs and it's a filesystem instead of an object storage. Also has transparent compression. ZFS grows online. Both OVH and Hetzner and I bet other such providers have API so you can just script the whole thing to grow as soon as you cross a threshold.

Also keep in mind that literally every hardware vendor has no problem giving great lease terms on actual hardware that you take possession of. Certainly more overhead, dev ops work, etc but yet another way to go about a desired technical approach while also being able to (largely) satisfy any policy/strategy/whatever with regard to capex.

With public cloud, you're paying for the control plane. Period.

Yes the raw compute cost is much higher (and the performance often less) than bare metal, but software development is really, really expensive. With the public cloud you get the result of literally millions of programmer-hours "for free". To many that's worth it (at least at first, below a certain scale).

This is also one reason why Kubernetes is really exciting, BTW. It's a control plane that you don't have to rent.

I really badly do not understand what EC2 gives you that a dedicated box doesn't. Yes, if you use all the other services, then there's a value but then again for example SQS is a particularly shitty queue.

It gives you dev ops out of the box. For small projects it has its merits. For most developers tinkering with the server isn't high in their priority list. I'm with you on dedicated but if I were to run an asynchronous crawler I'd rather go with AWS and save me the trouble of setting up the proper environment.

> SQS is a particularly shitty queue.

Do you have any other recommendations for queue systems that can handle a million messages per minute (our use case)?

A million messages per minute ? How's that a problem? Please see http://bravenewgeek.com/dissecting-message-queues/

Almost all of the systems tested hit 17k / s (aside from NSQ) -- on a laptop. NATS (gnatsd) hits 0.2M per second, that's a magnitude above what you need and that's a brokered system, if your task fits with a brokerless one then nanomsg is yet another magnitude. I do not particularly see where the problem really is?

Our messages range from a few KB to a few MB (we store a pointer to S3 for the large ones) but that look pretty interesting.

Thanks

It's not ec2, it's the ecosystem.

DDOS, multi-path, multi-az, dr, snapshots, hardware redundancy, elasticity, freedom from datacenter contracts, fiber contracts, driving to rack stuff, jammed fingers, staff costs, firmware bugs, bad hardware batches, cdn, compliance costs. I have more but I'll stop there.

It doesn't make sense at very small or large scales but it captures a hell of a lot of the middle.

Most of what you described is colo and not dedicated boxes...

And honestly, even colo doesn't take that much time unless you're scaling up like crazy. Once we racked our machines, we almost never had to touch them. You can get a LOT of resources in a single box for $10k/server these days.

I would've agreed with you a couple years ago, but now things have changed. Clouds like AWS and GCE are increasingly offering services that one can't replicate on their own dedicated box. ML, Managed Databases, etc. can't really be replaced.

Another thing is the skills one needs to efficiently manage and deploy everything. The sysadmin, devops positions in a startup have vanished because now that's AWS and GCE. Sure, AWS/GCE are expensive, but the developers don't need to worry about uptime, and if something happens to their instances, they just hit 'delete instance' and start up a new one.

The new theme seems to be developer productivity rather than cost effectiveness. With the new automatic deploy tools, and automatic load balancing, there's not really a need for anyone to worry about managing systems. It might seem like premature optimization, but you're saving the paycheck that needs to be paid to the sysadmin who has to be there for 24/7 monitoring.

This is all assuming one of the existing developers on the team isn't also a rockstar sysadmin, security guru and an insomniac who doesn't have a family.

>where you just don't have the ability to run hardware (increasingly the case)

Softlayer has 'on demand' bare metal plans. I'm not sure how cost effective it would be compared compared to running your own box, but the simplicity is nice and they had me up and running in under 2 hours (assembled with customizations).

http://www.softlayer.com/bare-metal-servers

As a customer, I can tell you we're very, very happy (Singapore SoftLayer, our Asian DC). No upfront capex, I can add or subtract hardware as necessary (I can say the same, they usually take about 2 hours to have it up and configured as requested), and my favorite benefit is when new hardware is available, we just spin up new servers and retire the old ones; bill ends up being the ~same.

It runs substantially cheaper than our colo here in Irvine, but that's also not apples-to-apples. That said, I don't plan on continuing with colos unless there's a pressing reason, after almost 15 years of them being my default. Bare Metal is the sweet spot in my eyes, the benefits of cloud without the downside of shared/inconsistent resources.

How custom can you get with the hourly machines? The order page (without logging in) looks like you have to pick a ram size (and they don't go beyond 256GB), and you can only go up to 4 disks. That said, I know the order page for monthly has maximum ram sizes listed below some of the monthly machines I manage, so maybe the hourly page is a simplified version of the truth too.

I'm not really sure about hourly plans. When I was configuring my machine (~1-2 years ago) I was able to select hourly or monthly billing (hourly would've been outrageously expensive).

Reply on news.ycombinator.com