Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS: the good, the bad and the ugly

blog.awe.sm

Post reply on HN
Print view View original

41–50 of 88 posts

Re: AWS: the good, the bad and the ugly

#41

Post by jaytaylor »

blantonl wrote: post #24

This is a great writeup and is completely on target for realistic deployments on AWS. We're a big user of AWS (well, relative, but we run about $10K/month in costs through AWS), so I'd like to supplement this outstanding blog post: * I cannot emphasize enough how awesome Amazon's cost cuts are. It is really nice to wake up in the morning and see that 40% of your costs are now going to drop 20% next month going forwar…

You might try using the SendHub API (https://www.sendhub.com) for your SMS alerts. Way easier to get started with than Twilio's, and the groups feature makes it very easy for people to subscribe to groups of alerts.

Disclaimer: I work at SendHub, but I've done it both ways and I definitely prefer ours ;)

Re: AWS: the good, the bad and the ugly

#42

Post by jeffbarr »

pearkes wrote: post #27
blantonl wrote: post #24

This is a great writeup and is completely on target for realistic deployments on AWS. We're a big user of AWS (well, relative, but we run about $10K/month in costs through AWS), so I'd like to supplement this outstanding blog post: * I cannot emphasize enough how awesome Amazon's cost cuts are. It is really nice to wake up in the morning and see that 40% of your costs are now going to drop 20% next month going forwar…

> We're scared to death of AWS SNS - we currently use SendGrid and a long trusted existing server for email delivery. Twillo will is our first choice for an upcoming SMS alerting project. Can you elaborate on this a bit? Why are you scared of SNS? Data loss / latency etc?

Yes, please. Let me know and I'll make sure that the team sees it.

Re: AWS: the good, the bad and the ugly

#43

Post by jaytaylor »

pearkes wrote: post #27
blantonl wrote: post #24

This is a great writeup and is completely on target for realistic deployments on AWS. We're a big user of AWS (well, relative, but we run about $10K/month in costs through AWS), so I'd like to supplement this outstanding blog post: * I cannot emphasize enough how awesome Amazon's cost cuts are. It is really nice to wake up in the morning and see that 40% of your costs are now going to drop 20% next month going forwar…

> We're scared to death of AWS SNS - we currently use SendGrid and a long trusted existing server for email delivery. Twillo will is our first choice for an upcoming SMS alerting project. Can you elaborate on this a bit? Why are you scared of SNS? Data loss / latency etc?

SNS is frequently a huge PITA to get working, often requiring SSH tunnels and the like.

Re: AWS: the good, the bad and the ugly

#44

Post by ghshephard »

blantonl wrote: post #24

This is a great writeup and is completely on target for realistic deployments on AWS. We're a big user of AWS (well, relative, but we run about $10K/month in costs through AWS), so I'd like to supplement this outstanding blog post: * I cannot emphasize enough how awesome Amazon's cost cuts are. It is really nice to wake up in the morning and see that 40% of your costs are now going to drop 20% next month going forwar…

I don't get the 100tb.com model. Checking out their website, I see:

Intel E3-12303.2 GHz8GB2 x 1TB100 TB$201.15 1Gbit Dedicated Port

So, for $200/month, they'll give me 100 Terabytes/bandwidth on this server.

250 megabit/second at 30 days in terabytes = 81 Terabytes. A decently peered/connected Pipe costs, at this volume, around $5-$7/megabit @95th, or $1250.month.

So either:

  A) Their connectivity isn't hot.
  B) If you actually use that 100 Terabytes per server, 
     they start to curtail/rate limit/traffic shape you.
  C) Some other option I haven't considered?  Maybe they 
     just rely on the vast majority of their customers not 
     using that bandwidth, and subsidizing (significantly) 
     those that do?
blantonl, appreciate any insight you can provide - sounds like you've got great control over your environment. From the sounds of it, 100tb.com provides bandwidth @$0.33/megabit.

Re: AWS: the good, the bad and the ugly

#45

Post by moe »

trotsky wrote: post #31

The elasticity, no capex and api management are great. But bending over backwards to deal with their terrible SAN, saturated layer 2 and low reliability easily wastes at least as much engineer time as it saves in ops. If the OP's 100 boxes are similar to most of the other AWS deployments I'm familiar with it's likely that'd be 10 or less actual machines to manage. Don't get me wrong - the idea is great and it's great…

I second this. If you are in the position to commit either way I'd suggest to first run a simple benchmark with your app on EC2 versus some cheap dedicated server.

As parent says: EC2 does have its place, but for deployments in the 10-20 hosts range (or an app with "special needs") you tend to pay through the nose. Keep in mind that the amount that you pay for a fraction of a server on EC2 will rent you the entire box elsewhere.

Re: AWS: the good, the bad and the ugly

#46

Post by jsatok »

ghshephard wrote: post #44
blantonl wrote: post #24

This is a great writeup and is completely on target for realistic deployments on AWS. We're a big user of AWS (well, relative, but we run about $10K/month in costs through AWS), so I'd like to supplement this outstanding blog post: * I cannot emphasize enough how awesome Amazon's cost cuts are. It is really nice to wake up in the morning and see that 40% of your costs are now going to drop 20% next month going forwar…

I don't get the 100tb.com model. Checking out their website, I see: Intel E3-12303.2 GHz8GB2 x 1TB100 TB$201.15 1Gbit Dedicated Port So, for $200/month, they'll give me 100 Terabytes/bandwidth on this server. 250 megabit/second at 30 days in terabytes = 81 Terabytes. A decently peered/connected Pipe costs, at this volume, around $5-$7/megabit @95th, or $1250.month. So either: A) Their connectivity isn't hot. B) If yo…

I haven't done a ton of work with 100tb.com, just a couple servers with them a few years back. It's great bandwidth. They're a SoftLayer reseller, so the nextwork blend is pretty good. I never got close to the 100tb cap, so am not sure if they'd impose some metering if you're doing it on a recurring basis. I feel like most of the people I've talked to about 100tb.com have gone in with the mentality that it's nearly unlimited, but end up using less than 1tb. If you aggregate across a ton of resold servers, I bet it's possible to make the model work pretty well.

Re: AWS: the good, the bad and the ugly

#47

Post by moe »

stevencorona wrote: post #13
bps4484 wrote: post #11

Earlier quoted context omitted.

How do you manage this? In my experience ephemeral storage is about 8GB. Are you able to just parition all data so that you never reach this limit, or is there a way to increase ephemeral space that I don't know about? PS great article

Even the smallest instances have 160GB of storage, all the way up to 3TB on the cc2.8xlarge. New high I/O instances have 2TB of "holy shit fast, destroys my $1000 enterprise SSD" storage. (just tested it last week)

New high I/O instances have 2TB of "holy shit fast, destroys my $1000 enterprise SSD" storage.

Just a tongue-in-cheek comment: Those instances also cost over $2000 USD per month. For the same money you could buy a new Dell Server with 2-4 SSDs, every month. ;)

Re: AWS: the good, the bad and the ugly

#48

Post by leoc »

> The failure mode of EBS on Ubuntu is extremely severe: because EBS volumes are network drives masquerading as block devices http://joyent.com/blog/magical-block-store-when-abstractions... , they break abstractions in the Linux operating system. This has led to really terrible failure scenarios for us, where a failing EBS volume causes an entire box to lock up, leaving it inaccessible and affecting even operations that don’t have any direct requirement of disk activity.

Assuming that I/O is reliable and fast-ish was a bad OS design decision in the 1970s, as the Unix guys themelves soon realised, though it was an understandable mistake at the time. Continuing to develop and use OSes with an I/O interface that assumes I/O is reliable and fast-ish, in 2012 - it's pretty bad, isn't it?

Re: AWS: the good, the bad and the ugly

#49

Post by ghshephard »

patrickgzill wrote: post #26
seldo wrote: post #16

Earlier quoted context omitted.

If I knew how to setup OpenVZ and create Our ops guy is much better than me, but his time is better spent working on higher-stack stuff like deployment automation, monitoring and efficiency tuning than on re-inventing a virtualization stack to save a few thousand dollars every month. If we were bigger, it would be more worth the time and money spent. But without doing the math, we would have to be quite a lot bigger,…

I am not trying to be sarcastic, I am just tired of some of the AWS fanboi's (not you) who act as if AWS solves all of your problems immediately for $50 a month. There are real costs no matter which way you go. PS, would be very surprised if you had even 45ms latency between AWS-east in Virginia and any of their facilities on the west coast...

Much of the attraction that I see from people comes from the flexibility. Once you get to any significant size in an organization, it's not unusual for people to have to wait for _months_ to get servers rolled out.

The ability to whip out your credit card, and fire up new servers at AWS in minutes, becomes very attractive in that scenario.

Re: AWS: the good, the bad and the ugly

#50

Post by stevencorona »

moe wrote: post #47
stevencorona wrote: post #13

Earlier quoted context omitted.

Even the smallest instances have 160GB of storage, all the way up to 3TB on the cc2.8xlarge. New high I/O instances have 2TB of "holy shit fast, destroys my $1000 enterprise SSD" storage. (just tested it last week)

New high I/O instances have 2TB of "holy shit fast, destroys my $1000 enterprise SSD" storage. Just a tongue-in-cheek comment: Those instances also cost over $2000 USD per month. For the same money you could buy a new Dell Server with 2-4 SSDs, every month. ;)

Lol, very true, but for 3-4 hour workloads they are perfect- which I think is one of the "makes the most sense" kind of EC2 workloads.

In this case, I had about 8 million output files from a Hadoop job that I needed to process with MySQL- it was perfect!

Post reply on HN