On Tue, Apr 26, 2011 at 8:01 PM, Wes Gamble <we...@att.net> wrote: > I would like to understand this statement from the Heroku post-mortem > better: > > "2) Block storage is not a cloud-friendly technology. EC2, S3, and other AWS > services have grown much more stable, reliable, and performant over the four > years we've been using them. EBS, unfortunately, has not improved much, and > in fact has possibly gotten worse. Amazon employs some of the best > infrastructure engineers in the world: if they can't make it work, then > probably no one can. Block storage has physical locality that can't easily > be transferred. That makes it not a cloud-friendly technology. With this > information in hand, we'll be taking a hard look on how to reduce our > dependence on EBS." > > I read about EBS a bit, and it sounds like filesystem, basically. Although > their use of the word raw and block together was somewhat confusing. > Anyhow, I'm wondering to myself "Why couldn't Amazon distribute copies of > the data in an EBS instance across multiple regions/availability zones?" > That does seem potentially network-intensive and I would accept that doing > that on all EBS instances might be crazy. Or perhaps there's no easy way to > abstract away the reference to the block device so that an EBS client could > easily switch to a copy even if you could make a copy?
One of the comments that I've heard is that EBS is like a NAS drive, except its generating traffic on the same interface as the application. The more the app load that triggers more DB/file system load, the higher the chances of network congestion. You can't access a disk drive that's sitting across a different region because of the geo latency. You might be able to get away with the throughput, but the latency will be very visible. This is partly why an EBS in a particular AZ has to be used by an instance in that AZ. These are all guesses into a black box that we don't necessarily know how things operate. People are guessing based on the constraints presented by Amazon and the variability in performance. K. --- http://blitz.io http://twitter.com/pcapr http://labs.mudynamics.com -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
