No, I didn’t take down Amazon

Uncategorized 1 Minute

Amazon's front door

Yikes, I write about Amazon’s Web services last night and today those services go down for the first time I can remember. CenterNetworks has info on the outage too. Looks like things are coming back online now, though. More on TechMeme.

Published by Robert Scoble

I help entrepreneurs build their technology business' story, help with getting ready for investors, with other launch plans, and many other strategic things that can help your new startup. Call to talk: +1-425-205-1921 (text first).

Published

37 thoughts on “No, I didn’t take down Amazon”

  1. Thanks Robert – what’s funny is that I was just about to put my article online about S3 on CN and how we use it — and then it died. Now I must adjust my article accordingly.

    Like

  2. Thanks Robert – what’s funny is that I was just about to put my article online about S3 on CN and how we use it — and then it died. Now I must adjust my article accordingly.

    Like

  7. @Wreck, I hope to one day be lucky enough to own two baskets, then if one basket breaks, I will still have 1/2 a website…that is 1/2 of a useless, broken website. There’s no difference between using S3 or any other hosting provider. They are all susceptible to going down. If you break a few eggs or piss on your basket, the result is still usually the same. Of all the services, S3 up to this point has been a very reliable and affordable service – and I think they still are.

    Like

  8. @Wreck, I hope to one day be lucky enough to own two baskets, then if one basket breaks, I will still have 1/2 a website…that is 1/2 of a useless, broken website. There’s no difference between using S3 or any other hosting provider. They are all susceptible to going down. If you break a few eggs or piss on your basket, the result is still usually the same. Of all the services, S3 up to this point has been a very reliable and affordable service – and I think they still are.

    Like

  9. Interesting, perhaps lots more people signed up to use it after your original article.

    Following on from my comment on your original story where I posed a couple of questions with regard to Disaster Recovery and Business Continuity plans. It looks like they have some, but it looks very patchy indeed. When they say its back, and then that maybe its a bit spotty doesn’t fill an enterprise, who perhaps have business critical data residing on those servers, with confidence.

    To answer your question from yesterday, you wouldn’t be allowed access to primary and back-up site as you have no need to know where they are situated and I wouldn’t either as I am not conducting a Physical Site review.

    I hope that Companies considering placing data on any box consider some of the risks and appraise correctly.

    Mike Ashworth
    Business Coaching and Consultancy
    Brighton and Hove, Sussex, UK

    Like

  10. Interesting, perhaps lots more people signed up to use it after your original article.

    Following on from my comment on your original story where I posed a couple of questions with regard to Disaster Recovery and Business Continuity plans. It looks like they have some, but it looks very patchy indeed. When they say its back, and then that maybe its a bit spotty doesn’t fill an enterprise, who perhaps have business critical data residing on those servers, with confidence.

    To answer your question from yesterday, you wouldn’t be allowed access to primary and back-up site as you have no need to know where they are situated and I wouldn’t either as I am not conducting a Physical Site review.

    I hope that Companies considering placing data on any box consider some of the risks and appraise correctly.

    Mike Ashworth
    Business Coaching and Consultancy
    Brighton and Hove, Sussex, UK

    Like

  13. Exactly why storage in the cloud is a ways off. Even if they fix the problem, it’s a mental setback to people that make the decisions.

    @Jon Henshaw, about all the eggs in one basket. Yes, for any given app, having S3 go down is no different than having your DB server go down. Except that:
    – You control your DB server and your redundancy options and you very likely can get *your* data back up quickly.
    – Your DB server going down does not cause my DB server to be unavailable, but S3 going down takes down many subscribers data.

    “All the eggs” doesn’t necessarily mean all of “your” eggs, but all of “everybody’s” eggs.

    Like

  14. Exactly why storage in the cloud is a ways off. Even if they fix the problem, it’s a mental setback to people that make the decisions.

    @Jon Henshaw, about all the eggs in one basket. Yes, for any given app, having S3 go down is no different than having your DB server go down. Except that:
    – You control your DB server and your redundancy options and you very likely can get *your* data back up quickly.
    – Your DB server going down does not cause my DB server to be unavailable, but S3 going down takes down many subscribers data.

    “All the eggs” doesn’t necessarily mean all of “your” eggs, but all of “everybody’s” eggs.

    Like

  23. When I saw the news today, the first thing that came into my mind was Valleywag linking your visit to the S3 downtime. Good you came out before they could switch on their imaginations 🙂

    Like

  24. When I saw the news today, the first thing that came into my mind was Valleywag linking your visit to the S3 downtime. Good you came out before they could switch on their imaginations 🙂

    Like

  25. Pingback: Amazon Web Services first complete outage (AWS S3, EC2, SQS, …) « viralfriends

  28. Amazon needs to work at having an infrastructure like Google.

    Server goes down? No problem! Another one kicks in with the user unaware of the issue. After all, they are famous for their network/database redundancy.

    Perhaps Google should get in this business!

    On another note: It is strange that I just signed up for an Amazon web service just a couple days ago! I don’t think about ten sample calls to it would bring it down though! 🙂

    Like

  29. Amazon needs to work at having an infrastructure like Google.

    Server goes down? No problem! Another one kicks in with the user unaware of the issue. After all, they are famous for their network/database redundancy.

    Perhaps Google should get in this business!

    On another note: It is strange that I just signed up for an Amazon web service just a couple days ago! I don’t think about ten sample calls to it would bring it down though! 🙂

    Like

  34. Server redundancy does not mean good security. They still have to worry about being victims of a major DDoS attack. Almost nothing can stand up to a massive DDoS, even if the router security people do blackhole routing — the connection is simply just overrun with gazilliions of packets.

    The smart thing to do is have your data made redundant by hosting at multiple sites with immediate failover. That’s what the pros do. Hosting at a single site, even with redundancy at that one site is nuts.

    Like

  35. Server redundancy does not mean good security. They still have to worry about being victims of a major DDoS attack. Almost nothing can stand up to a massive DDoS, even if the router security people do blackhole routing — the connection is simply just overrun with gazilliions of packets.

    The smart thing to do is have your data made redundant by hosting at multiple sites with immediate failover. That’s what the pros do. Hosting at a single site, even with redundancy at that one site is nuts.

    Like

  36. There is a very important question you have to ask yourself before deciding whether to use S3: what are you really looking for – remote storage, content delivery, or both. These are crucial to distinguish.

    What I observe is that most people treat Amazon S3 as a content delivery service. While this is not inherently wrong, one has to notice that S3 was especially designed to be a STORAGE service. S3 does not claim to be a CDN.

    The point is, since terabyte hard drives are affordable nowadays and internet traffic grows steadily, the stress goes much more on content delivery and network infrastructure rather than on storage. If you are not concerned about using remote storage, there are much better services especially suited for content delivery.

    SteadyOffload.com provides an innovative, subtle and convenient way to offload static content. The whole mechanism there is quite different from Amazon S3. Instead of permanently uploading your files to a third-party host, their cachebot crawls your site and mirrors the content in a temporary cache on their servers. Content remains stored on your server while it is being delivered from the SteadyOffload cache. The URL of the cached object on their server is dynamically generated at page loading time, very scrambled and is changing often, so you don’t have to worry about hotlinking. This means that there is an almost non-existent chance that the cached content gets exposed outside of your web application.

    It’s definitely worth trying because it’s not a storage service like S3 but exactly a service for offloading static content.

    Watch that:
    http://video.google.com/videoplay?docid=-8193919167634099306 (the video shows integration with WordPress, but it is integrable with any other webpage)
    http://www.steadyoffload.com/
    http://codex.wordpress.org/WordPress_Optimization/Offloading

    Cost of bandwidth comes under $0.2 per GB – affordable, efficient and convenient. Looks like a startup but lures me very much. Definitely simpler and safer than Amazon S3.

    Like

  37. There is a very important question you have to ask yourself before deciding whether to use S3: what are you really looking for – remote storage, content delivery, or both. These are crucial to distinguish.

    What I observe is that most people treat Amazon S3 as a content delivery service. While this is not inherently wrong, one has to notice that S3 was especially designed to be a STORAGE service. S3 does not claim to be a CDN.

    The point is, since terabyte hard drives are affordable nowadays and internet traffic grows steadily, the stress goes much more on content delivery and network infrastructure rather than on storage. If you are not concerned about using remote storage, there are much better services especially suited for content delivery.

    SteadyOffload.com provides an innovative, subtle and convenient way to offload static content. The whole mechanism there is quite different from Amazon S3. Instead of permanently uploading your files to a third-party host, their cachebot crawls your site and mirrors the content in a temporary cache on their servers. Content remains stored on your server while it is being delivered from the SteadyOffload cache. The URL of the cached object on their server is dynamically generated at page loading time, very scrambled and is changing often, so you don’t have to worry about hotlinking. This means that there is an almost non-existent chance that the cached content gets exposed outside of your web application.

    It’s definitely worth trying because it’s not a storage service like S3 but exactly a service for offloading static content.

    Watch that:
    http://video.google.com/videoplay?docid=-8193919167634099306 (the video shows integration with WordPress, but it is integrable with any other webpage)
    http://www.steadyoffload.com/
    http://codex.wordpress.org/WordPress_Optimization/Offloading

    Cost of bandwidth comes under $0.2 per GB – affordable, efficient and convenient. Looks like a startup but lures me very much. Definitely simpler and safer than Amazon S3.

    Like

Comments are closed.