On a semi-related note, the fact that cloud providers offer managed Postgres databases is great, but things like this keep pushing me to think about bare metal in colo. A $20,000 server/backup combo with a couple of these will give me 5x the performance of a server that costs me $70k/year on AWS before provisioned IOPS. That's a huge gap to play with for taking care of your own maintenance costs.
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..
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).
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.
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.
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?
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.
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).
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)
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.
Do you have any other recommendations for queue systems that can handle a million messages per minute (our use case)?
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?
Thanks
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.
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.
It's so much cheaper than AWS, and you get unlimited bandwidth.