Problem: Ebay’s problem is the same problem shared by any large site in the internet today; how to handle many users accessing large amounts of services/data, with the data being updated millions (or billions) of times per day.
Solution: Ebay’s solution rely’s upon 5 principles that Ebay has almost embraced: partitioning, asynchrony, automation of configuration, acceptance of failure, and (almost) embracing inconsistency. My main criticism of the Ebay work rest upon the requirement of immediate consistency for bids and purchases. I wonder how seriously they have considered almost immediate consistency resolved by the application with a timestamp when “immediate consistency” is required at present.
I am heartened by Ebay’s use of 3rd-party cloud services. I am curious as to the present implementation details. I noticed the mention of event-based transactions in “eBay’s Scaling Odyssey”, but there are scant details. It seems that eBay has separated the application from the storage in delivery of their service, but I wonder how fundamental their separation is in implemenation.
Finally, I am curious as to how open eBay would be to a completely distributed storage layer.
Future influence: I think that Ebay’s work will be highly influential in the coming decade. Ebay seems willing to embrace a separation between the application and data in order to provide a scalable dynamic service to many millions of users per day. Ebay’s present work is a stepping stone to a truly scalable model of services and sub-services that will be adopted by any similar large deployment out of necessity.
I would like some comment from the class on my thoughts here. We should embrace the blog structure on the paper comments for sharing ideas.
Subscribe to:
Post Comments (Atom)
It's very impressive that Ebay managed to go from .com boom startup to carefully-managed application built on solid design principles when so many businesses failed that transition. I think it will be especially interesting to ask them what this transition entailed and whether they have any interesting war stories from it. As the first slide set says, there is a need for "feature velocity" and adaptability - changing and adding features - on a competitive website. How do you reconcile this with solid engineering? I'd like to know what the process for building a new feature in ebay is, e.g. what kind of design documents and tests you have to go through to show that it's scalable and safe.
ReplyDeleteI was also pleasantly surprised like you about their positive view of clouds. If ebay thinks it may be worth pushing some work to an external cloud, this makes a very strong case for utility computing. I'd like to know what features exactly they are thinking of pushing out. One advantage of ebay in this regard however, unlike something like Facebook, is that most of the data on the site is public, so for example they can push out things like search without fear of endangering users' privacy.
Franco Travostino talk
ReplyDeleteHere is a summary of what I learned from Franco:
eBay only embraces fundamental change when it experiences disaster; otherwise the Titanic only turns very slowly. Franco’s description of himself as Odysseus listening to the sirens while making sure he is tied down is a good analogy for his role at eBay. I spoke to Franco after class and was able to understand the reasoning behind such inertia. There is a large overhead to any change and a new approach must be able to overcome the cost not only of resources, but of the change of mindset and training of people to handle the change. Also, the solution must be readily reversible. So, eBay looks for solutions that are already proven and can be readily taken up by a consumer.
I will soon add some info about eBay’s challenges.
It is more than inertia when deciding to make the transition to clouds; it's whether it makes business sense or not. Franco's point that you need to consider all the costs associated to the transition is an excellent one!
ReplyDelete