3 ms·

>> why do people chose to waste their very precious time writing software to deal with EBS failures (and other AWS deficiencies) instead of just not using AWS?

>> why do people chose to waste their very precious time writing software to deal with EBS failures (and other AWS deficiencies) instead of just not using AWS? 1) Proven Scale. Netflix. They're bigger than I will be until such time my company can afford to buy it's own data centers. At that point, I can re-evaluate. 2) Operational overhead. Startup, running hundreds of hosts, thousands of requests per second, 5 developers, 0 sys-engineers. 3) Lock in. We use Cloudwatch, Dynamo, RDS, Beanstalk, S3, EMR and more. We also use Heroku. No one else out there has the full suite of offerings. Not using AWS would require us to stitch together offerings from several vendors, some technology wouldn't be feasible having to hop across the internet (do you want the lag to get to your database from one data center to another?) 4) Billing. We get 1 Bill which we can predict. AWS takes credit cards, will do Net 30 billing, and are generally pretty flexible. 5) Customer Service. Don't get me wrong, support at AWS is ... not it's strong suit. We also don't spend enough to be a "big fish". However, if we used 10 different providers to get our infrastructure together, we'd me a minnow to each one. By consolidating, we're a small-medium sized customer which is enough to get into beta's, info on their roadmap ahead of time, and some personal service. 6) Excuses for downtime. So many high profile companies are on AWS that if we have an outage directly attributable to AWS, the odds are a lot of the rest of the internet is down, too. Seriously. It sounds stupid, but it's a huge reason. 2 years ago we were raising money. Right in the middle of our final week (when all our investors were visiting our site and making sure they really wanted to sign on the dotted line), we had an outage that lasted several days. This was the AWS outage that took out Heroku for a few days, and ours was one of the last databases to get restored. If we were using almost anyone else, investors might have been like "oh, this team doesn't really know what they're doing, they're not really that technically competent, I'm not going to invest". But since Netflix, Foursquare, and dozens of other companies were all offline at the same time, the investors were just like "they're using AWS, if Netflix can't keep online with hundreds of engineers, then I'm not going to expect that this little startup is going to do better". 7) Could I really do it better? Is anyone else doing better? AWS is the leader, so we all see the warts ... but at least they keep their certs updated (ahem microsoft)

ghshephard 14y ago
Some more items: o Liquidity of engineering talent - thousands of engineers know how to immediately work with the AWS infrastructure o Design Patterns - They are constantly being updated, discussed, improved upon. People share how to work around AWS issues. o Commitment to reducing prices - AWS is constantly dropping the prices for everything. o Commitment to increasing the number of services - AWS is constantly releasing new and useful services on their infrastructure. o Likelihood of being in business in 3 years. AWS isn't going anywhere. You can rely on them being around. o Really good post mortems. Each time they fail, they do pretty transparently, and deliver a really painful post mortem that encourages me to believe they are committed to constantly improving. o Multiple Availability and Region zones. I can, with very little effort, make my services available in redundant regions. I don't think there has ever been a multi-region failure with AWS, and, at most, it's only happened a couple times in their history. Multi-Availability zone failures have happened (and Amazon has apologized - that shouldn't happen) - but, it's < half a dozen times. o Market Leader Advantage - The market leader tends to win. Microsoft for Desktops, Oracle for Databases, Linux for simple Web/Database/PHP stacks. This isn't always the case (Juniper can beat Cisco in a lot of places) but you know Amazon will be a Top-3 contender for at least the next 5 years. I realize a lot of these are "Business" reasons, which is incredibly frustrating for people who are comfortable with hosting bare metal, and realize that, given just half the money, they could go into a CoLo, rent a cabinet, buy some servers, routers, firewalls, storage - install it, and return twice the performance that they would get on AWS. But quite often, the business argument is a more important driver for CxO people making decisions (and assigning budget) than technical reasons. And, with all that said - I've been in about a dozen Tier-1 data centers in the last 15 years, and, with one exception, every one of them has had multiple sustained outages. (The exception has been Switch SuperNap in Las Vegas - 3 years and no major outage.) - So, failures are part of the business. I'm not expecting Amazon to eliminate them, so it doesn't disappoint me when they happen.
luser001 14y ago
Serious question: You have hundreds of hosts, but you don't think the savings of colocating your own hardware won't pay for an engineer to take care of the machines?

ghshephard 14y ago

Some more items: o Liquidity of engineering talent - thousands of engineers know how to immediately work with the AWS infrastructure o Design Patterns - They are constantly being updated, discussed, improved upon. People share how to work around AWS issues. o Commitment to reducing prices - AWS is constantly dropping the prices for everything. o Commitment to increasing the number of services - AWS is constantly releasing new and useful services on their infrastructure. o Likelihood of being in business in 3 years. AWS isn't going anywhere. You can rely on them being around. o Really good post mortems. Each time they fail, they do pretty transparently, and deliver a really painful post mortem that encourages me to believe they are committed to constantly improving. o Multiple Availability and Region zones. I can, with very little effort, make my services available in redundant regions. I don't think there has ever been a multi-region failure with AWS, and, at most, it's only happened a couple times in their history. Multi-Availability zone failures have happened (and Amazon has apologized - that shouldn't happen) - but, it's < half a dozen times. o Market Leader Advantage - The market leader tends to win. Microsoft for Desktops, Oracle for Databases, Linux for simple Web/Database/PHP stacks. This isn't always the case (Juniper can beat Cisco in a lot of places) but you know Amazon will be a Top-3 contender for at least the next 5 years. I realize a lot of these are "Business" reasons, which is incredibly frustrating for people who are comfortable with hosting bare metal, and realize that, given just half the money, they could go into a CoLo, rent a cabinet, buy some servers, routers, firewalls, storage - install it, and return twice the performance that they would get on AWS. But quite often, the business argument is a more important driver for CxO people making decisions (and assigning budget) than technical reasons. And, with all that said - I've been in about a dozen Tier-1 data centers in the last 15 years, and, with one exception, every one of them has had multiple sustained outages. (The exception has been Switch SuperNap in Las Vegas - 3 years and no major outage.) - So, failures are part of the business. I'm not expecting Amazon to eliminate them, so it doesn't disappoint me when they happen.

luser001 14y ago

Serious question: You have hundreds of hosts, but you don't think the savings of colocating your own hardware won't pay for an engineer to take care of the machines?