Live data from Hacker News

16 TB and 20,000 IOPS EBS Volumes

aws.amazon.com

31–38 of 38 posts

Re: 16 TB and 20,000 IOPS EBS Volumes

#31
post #24
post #5

Earlier quoted context omitted.

Can you completely snapshot those volumes at any time, recreate them and attach them to new servers? Could you take these snapshots and easily copy them around the world?(again assuming you could snapshot). Are those SSD's automatically replicated to 2 different storage devices behind the scenes to give you near-instant failover? When they go boom are you then driving out to the datacenter to replace them (assuming y…

> Can you do all of this without any upfront cost or excess in capacity?? The price premium of using AWS is high enough that it's trivial to afford leasing tons of excess capacity to handle failures and still save tons of money. But by and large it's not really necessary - most hosting providers can provide rapidly provisioned managed servers or VPS's in the same data centres as their colo offerings these days, which…

"The price premium of using AWS is high enough that it's trivial to afford leasing tons of excess capacity to handle failures and still save tons of money."

"AWS certainly is convenient, but it's also so expensive I'm charging my highest day rates ever for projects to help clients move off AWS these days."

This is FUD and nothing more than FUD. As bad as the article the other day that said a company saved 50% moving off AWS. Show me a company that can save 50% by moving off AWS, and I'll show you a company that isn't using AWS properly at all.

When you compare a single piece of hardware that you can buy and run yourself to an instance in EC2, you are leaving a lot off the equation.

Such as:

Deployment tools (CloudFormation, CodeDeploy, EB, OpsWorks)

Monitoring tools (CloudWatch (sure it leaves some to be desired)

Machine Image building/tracking tools

Hardware provisioning tools

Security tools ( Security Groups, NACL's in VPC, plus the stuff you don't see in the infrastructure)

More varied hardware than you'd have in house.(different amounts of ram/cpu/storage).

More hardware than you'd have in house. (no need for spare parts cabinets, waiting on vendors for replacements).

Storage (EBS, S3, local).

When you pay for EC2, you get all of this. Doing this yourself isn't free in any way shape or form, even with opensource tools. A company with a good ops team that is cloud savy is going to be several times more effective at a smaller size than a team that has to manage a datacenter, all the hardware, and all these other bits. Folks discredit all of these when they do apples to apples comparison of hardware you can buy to a service that you use.

Let alone that most people don't understand per-server network, space, and power cost over its lifecycle. (I've spent months with companies doing datacenter ROI analysis and having no idea what things cost).

And going to a managed hosting provider, you're either locking yourself into the frozen tech world they are in, small development resources, and typically constrained resources. You don't hear of managed hosting providers building any of the above themselves, so you continue to have a higher management overhead than a true cloud provider like GOOG, AWS, MSFT.

Re: 16 TB and 20,000 IOPS EBS Volumes

#32
post #31
post #24

Earlier quoted context omitted.

> Can you do all of this without any upfront cost or excess in capacity?? The price premium of using AWS is high enough that it's trivial to afford leasing tons of excess capacity to handle failures and still save tons of money. But by and large it's not really necessary - most hosting providers can provide rapidly provisioned managed servers or VPS's in the same data centres as their colo offerings these days, which…

"The price premium of using AWS is high enough that it's trivial to afford leasing tons of excess capacity to handle failures and still save tons of money." "AWS certainly is convenient, but it's also so expensive I'm charging my highest day rates ever for projects to help clients move off AWS these days." This is FUD and nothing more than FUD. As bad as the article the other day that said a company saved 50% moving…

Show me a company that can save 50% by moving off AWS, and I'll show you a company that isn't using AWS properly at all.

Using AWS "properly" usually means moving most of your stuff off AWS.

AWS has a few very narrow sweet-spots. Your average web-stack is not one of them.

Re: 16 TB and 20,000 IOPS EBS Volumes

#34
post #22
post #16

Earlier quoted context omitted.

I actually have to get some sleep now - it's after 1AM here in Aussie, I wanted to stress that I'm absolutely not against using cloud hosted services - just that they're not the answer to all situations and there's a lot to be gained from ensuring you don't get sucked in to too much of the 'Spin' that vendors provide.

np! at the end of the day we all hate on call. cheers.

I used to, but we rarely get a single alert out of hours these days - if we do, we're probably doing something wrong.

Re: 16 TB and 20,000 IOPS EBS Volumes

#35
post #7
post #4

Did the IOPS (and better yet, enhanced IOPS) help any big user? DataStax and Eleasticsearch Inc recommend to stripe instance stores (doing raid0), which in the cloud is not the worst idea as long as you have multiple nodes and proper ring designed. That being said, now I lose the ability create snapshot because the volumes are not EBS. From my experience the IOPS isn't very stable.

Provisioned IOPS are quite stable, in my experience. That's their entire point.

But with AWS' provisioned tiers you're kind of losing out on your cost savings...

Re: 16 TB and 20,000 IOPS EBS Volumes

#36
post #27

Earlier quoted context omitted.

Well your security is definitely worse than Amazon's. Please prove me wrong. http://aws.amazon.com/compliance/ I think the fallacy in you comment is that you think about storage as it was not using energy and network. If add those costs to the bill, are you sure that you are still cheaper? On the other hand, I much rather pay a monthly fee that I can turn off if things go sideways, than buy extremely expensive gear t…

Amazon's bandwidth rates are more than 10 times what we can get locally, and power is included in our colo rental fees. I'm assuming that will pretty much be the situation for mrmondo too. In terms of monthly costs, all the gear I deal with is lease to own: We pay less per month when the servers are new, and 3 years down the line our bills drop. There's no reason to have large capital expenditures just because you wa…

I was going to reply to the parent comment but you've summarised exactly what I would have said - sounds like you've done your research and come to similar conclusions to us as well.

Re: 16 TB and 20,000 IOPS EBS Volumes

#37
post #25
post #17

Earlier quoted context omitted.

Ok the latency is high. But I was seeing numbers in the 300,000 IOPS range for ramdisks.

A naive guess is that most of that is filesystem overhead. Were you using tmpfs?

It wasn't my benchmark, but that's my guess too.

Re: 16 TB and 20,000 IOPS EBS Volumes

#38
post #30

Earlier quoted context omitted.

> most ppl will never need more than 100k IOPs, let alone 500k+ These types of statements are always false. If there is anything the computing industry has taught us is that people always need more resources. Always.

I sincerely hope you are joking here.

I sincerely hope YOU are joking, right?

I can think of many examples why even small businesses need more than 100k IOPS. Case in point: 5 years ago I did consulting work for an email marketing company that was generating a daily report on a database of about 1TB. The report took 10+ hours to generate due to the SQL queries aggregating data from joined tables in more or less random patterns. I upgraded their DB server from a 2-way RAID0 on 15kRPM HDD (about 500 IOPS) to a single SSD (20k IOPS), and it cut down report generation time to 15 minutes. 4 years later their database has continued growing and generation took 1 hour. They called me up again, I upgraded them to a 4-way SSD-based RAID5 (I benchmarked 250k IOPS) and again it cut down report generation to 6-8 minutes. This was a small company: a dozen marketers, 1 software guy.

Post reply on HN