It wasn't until a couple of the customers who used it explained what's really required. There appears to be a problem with having a single point of failure around distributing the load over machines and how DNS is handled in the patterns explained. However, the persistence issue seems to have some patterns defined that work pretty well. You definitely have to architect to work effectively for this environment.
There seems to be a very clear case if you are doing batch computing over objects, or if you have widely varying computing needs or want cheap storage of blobs. I'm assuming that Amazon will get the DNS/load distribution issue figured out and then this would seem to be a pretty compelling offering.
As it stands, there are a few cases where it would have applied on projects I've worked on:
- LivePlanet - could have used it to bulk up for each contest, store videos and scripts on S3, and possibly do format conversions. A lot of the examples that Amazon used were media related.
- Other storage of media: GreenLightJobs - store media / portfolio elements, LoanToolBox - content elements/videos.
- eHarmony and MyShape seem they could use it to distribute load around matching especially during media events. There are periodic intensive compute cycles and the need to ramp up quickly based on particular needs. This would seem to be a good case for us to separate off matching and making that a more scalable operation on EC2.
No comments:
Post a Comment