Domain: allthingsdistributed.com
Stories and comments across the archive that link to allthingsdistributed.com.
Comments · 11
-
Aurora uses local SSD, not EBS
Aurora doesn't use EBS (like RDS does).
Aurora has a storage cluster, that uses instance storage on EC2 instances, with a client to this storage cluster in the storage engine in the database instances.
See figure 5 in the Aurora paper: https://www.allthingsdistribut...
-
How are costs lower than S3?
According to this article, Cloud Drive is based on S3. The cost per GB for Cloud Drive is $1 per GB per year, where as S3 is $.14 per GB per month, or about $1.68 per GB per year plus transfer costs. Even if they're using reduced redundancy, Cloud Drive is still cheaper and S3 has transfer costs. Cloud Drive does require annual payments, so that may be a factor, but assuming they provide some sort of API to Cloud Drive or it's http and someone writes a library to access it, why would you pay more for S3?
-
Re:"Demonstrates..."
Facebook does not really use MySQL but rather MySQL they've rewritten to use as a backing store for their gazillion memcache servers.
Erm... wait... what?
Wouldn't that be, the software they've written in front of MySQL that knows how to use memcached? I don't see why you'd have to touch the MySQL code itself.
At the other end of the spectrum, Amazon and telcos use Oracle,
Interesting, because Amazon also does Dynamo, which is very decidedly not Oracle.
-
Startups don't have data centers
Startups outsource data center work to cloud providers. These big companies that are struggling to manage their data centers are really only battling their own inertia and internal vested interests while the world around them changes. There is no reason, from 2010 onwards, for 90% of current data center efforts to not be in one of the clouds. The growth in usage of Amazon's AWS cloud is amazing. Avoiding data center management is the reason nimble companies working to get there.
-
Better link
Don't judge based on this article. The author's "young guys playing fast and loose" vs. "stuffy but reliable old guys" way of explaining things misses the point. Either he's a bad writer, or he doesn't know what he's talking about. A much better treatment can be found here.
-
A little dabbling in EC2 - eventual consistency
Until seeing this article I had no knowledge of the existence of either GoGrid or AppNexus. After attending 3 different talks/sessions about Amazon Web Services among TSSJS & JavaOne confs, I had begun to play with AWS. I really like EC2 & S3. I'm still trying to get my mind around the concept of "eventual consistency" which the speaker of 2 of these talks told me to look into. Presumably if you use the AWS, you must architect your applications to tolerate eventual consistency. Once I well-understand the other AWS services (SimpleDB, SMQ, etc.) in the context of eventual consistency I think I'd be able to see how to make good use of Amazon in real-world production. There was also a presentation by a company that uses AWS in production. What they use, how they do things, and the tradeoffs. The specific example had to do with news media and the need to encode a video clip into various quality, resolution, and format variations for distribution in the media website and footage archive. Naturally lots of video encoding lends itself well to cloud computing for on-demand processing capability as well as storage of all the generated artifacts. Pretty cool stuff!
-
Re:central
I don't think there is a good generic recommendation. It depends on your application.
The main thing that I think people need to do is to think beyond the notion of The One True Database and focus more on grouping data and related computation behind clean interfaces. Sometimes behind that interface you use a traditional SQL database, and sometimes you do something else. But so many people build systems where the database is both the internal API and the single integration point, turning a historical accident into a key architectural feature.
As examples of what people are doing once they think outside the SQL box, take a look at Dynamo, Bigtable, or Mnesia. But my point isn't that you should build your system around one of those instead; it's that you should be thinking of any given solution like that as a tool in your toolbox, something that your system might use for now.
-
Re:Solution
These sites are pretty useful when it comes to planning high performance websites:
http://highscalability.com/
http://www.allthingsdistributed.com/ -
check these out...
These are both decent starting points. Please report back if you find something good -- I'd be very interested.
http://highscalability.com/
http://www.allthingsdistributed.com/ -
i think you missed the point
Vogels was a distinguished academic in distributed systems prior to Amazon. Read his blog some time. He is quite insightful, and this queuecast was a great one. Yours is the first comment I've seen in many forums over the past few months that seems to think it was tripe, so I find it curious.
His point is that Amazon has found that a decentralied archtiecture that can work reliably but still respond to new demands with agility. That's a huge deal, considering the contortions, pain, and centralized bottlenecks that most large IT shops have to deal with. Not to mention over-obsession with technological buzzes instead of looking at the business architecture of the firm.
Perhaps that's obvious, but perhaps it's important to restate the obvious when most people don't follow it. -
Blog Discussions about Werner's Post
A conversion list talking about Werner Vogel's recent post about Naked Answers. It is amazing to see so many bloggers are talking about it, including Scoblizer, Matthewingram, Rick Segal, etc.