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

Surviving AWS Failures with a Node.js and MongoDB Stack

kinvey.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Surviving AWS Failures with a Node.js and MongoDB Stack

#11

Post by shykes »

veesahni wrote: post #5
shykes wrote: post #3

Here's how I do it: $ pip install dotcloud $ echo 'frontend: {"type": "nodejs"}' >> dotcloud.yml $ echo 'db: {"type": "mongodb"}' >> dotcloud.yml $ dotcloud push $MYAPP $ dotloud scale $MYAPP frontend=3 db=3 This will deploy my nodejs app across 3 AZs and setup load-balancing to them, deploy a Mongo replicaset across 3 AZs, setup authentication, and inject connection strings into the app's environment. It's also way…

"It's also way cheaper than AWS." 3 AWS Small instances cost under $200 / mo and come with 1.7GB of RAM each. The dotCloud pricing calculator is coming up with $700 / mo for 3 mongodb instances with 1.7GB of RAM. Obviously this isn't an apples to apples comparison. But How are dotCloud instances different from AWS instances?

It's cheaper at equivalent level of best practice:

* For a clean architecture you want to isolate each Mongo and node process in its own system. So you need 6 instances, not 3.

* You'll need load-balancers in front of these node instances. That costs extra on AWS, and is included on dotCloud.

* Did you include the cost of bandwidth and disk IO in your estimate? Those are extra on AWS, but included on dotCloud.

* Monitoring is extra on AWS. It's included on dotCloud.

* I love to have a sandbox version of my entire stack, with the exact same setup but separate from production. That's an extra 2 instances on AWS (+io +bandwidth +load-balancing +monitoring). It's free on dotCloud, and I can create unlimited numbers of sandboxes which is killer for team development: 1 sandbox per developer!

* We only charge for ram usable by your application and database. AWS charges for server memory - including the overhead of the system and the various daemons you'll need to run.

* For small apps specifically, you can allocate memory in much smaller increments on dotCloud, which means you can start at a lower price-point: the smallest increment is 32MB.

I didn't even get into the real value-add of dotCloud: all the work you won't have to do, including security upgrades, centralized log collection, waking up at 4am to check on broken EBS volumes, dealing with AWS support (which is truly the most horrible support in the World, and we pay them a lot of money).

+ Our support team is awesome and might even fix a bug in your own code if you're lucky :)

Re: Surviving AWS Failures with a Node.js and MongoDB Stack

#12

Post by giulianob »

justinsb wrote: post #2

You need to be in multiple regions to tolerate EC2 outages, not just multiple AZs. Even then, this is only good until AWS's first multi-region failure; this doesn't seem to be an impossible event given EC2's recent track record. Though I can well understand that designing for EC2 region failure is not worth the cost for most systems.

There were comments during the failure that AWS wasn't properly switching to use the available zones during the outage. That's what I find troubling. You are paying extra for some guaranteed availability and everyone keeps saying thats how you prevent downtime during outages. Then when the times comes it doesnt work?

Re: Surviving AWS Failures with a Node.js and MongoDB Stack

#13

Post by sgrove »

shykes wrote: post #7
sgrove wrote: post #4

Earlier quoted context omitted.

This seems ridiculously nice to me, but I haven't heard much buzz around this in the community. Any thoughts on why there's comparatively less noise about dotCloud's offering? It seems far nicer in many ways than others. From what I remember when trying to get the copy/paste instructions written for Kandan so others could deploy to dotCloud to get started with it, there was a steeper learning curve for dotCloud than…

> This seems ridiculously nice to me, but I haven't heard much buzz around this in the community. Any thoughts on why there's comparatively less noise about dotCloud's offering? It seems far nicer in many ways than others. I think there are 2 reasons. One reason is simply that we're better at building the product than the buzz. As it turns out "developer buzz" is not organic, it is something that must be engineered,…

Sounds reasonable, very cool. I suspected it was something along those lines - a demographic that had money (and real problems) that I wasn't personally connected to.

Re: Surviving AWS Failures with a Node.js and MongoDB Stack

#14

Post by helper »

zorked wrote: post #10
helper wrote: post #9

Considering how often EC2 outages are EBS related, we've moved all our servers off of EBS to ephemeral drives. I'm surprised there aren't more people advocating this route.

I think part of the problem is that EBS issues also cause ELB problems, from that I read here on HN. I wouldn't know because we only use us-east for Hadoop. On the other hand, our Cassandra cluster runs on ephemeral drives and it's way better than EBS even with the guaranteed IOPS thing. Everyone should definitely give this option a try.

Yup. ELB is great except it uses EBS. So part of our migration was to move off of ELBs.

Re: Surviving AWS Failures with a Node.js and MongoDB Stack

#15

Post by justinsb »

giulianob wrote: post #12
justinsb wrote: post #2

You need to be in multiple regions to tolerate EC2 outages, not just multiple AZs. Even then, this is only good until AWS's first multi-region failure; this doesn't seem to be an impossible event given EC2's recent track record. Though I can well understand that designing for EC2 region failure is not worth the cost for most systems.

There were comments during the failure that AWS wasn't properly switching to use the available zones during the outage. That's what I find troubling. You are paying extra for some guaranteed availability and everyone keeps saying thats how you prevent downtime during outages. Then when the times comes it doesnt work?

If you were affected by this, I hope you got a big refund (1+ month).

Re: Surviving AWS Failures with a Node.js and MongoDB Stack

#16

Post by taligent »

zorked wrote: post #10
helper wrote: post #9

Considering how often EC2 outages are EBS related, we've moved all our servers off of EBS to ephemeral drives. I'm surprised there aren't more people advocating this route.

I think part of the problem is that EBS issues also cause ELB problems, from that I read here on HN. I wouldn't know because we only use us-east for Hadoop. On the other hand, our Cassandra cluster runs on ephemeral drives and it's way better than EBS even with the guaranteed IOPS thing. Everyone should definitely give this option a try.

Add inability to access AWS Console as well to the mix.

Re: Surviving AWS Failures with a Node.js and MongoDB Stack

#17

Post by shykes »

helper wrote: post #14
zorked wrote: post #10

Earlier quoted context omitted.

I think part of the problem is that EBS issues also cause ELB problems, from that I read here on HN. I wouldn't know because we only use us-east for Hadoop. On the other hand, our Cassandra cluster runs on ephemeral drives and it's way better than EBS even with the guaranteed IOPS thing. Everyone should definitely give this option a try.

Yup. ELB is great except it uses EBS. So part of our migration was to move off of ELBs.

Same here, dotCloud originally used ELB and we eventually moved off, which brought immediate and huge gains in latency and overall reliability.

Re: Surviving AWS Failures with a Node.js and MongoDB Stack

#18

Post by res0nat0r »

justinsb wrote: post #8
ceejayoz wrote: post #6

Earlier quoted context omitted.

> Even then, this is only good until AWS's first multi-region failure; this doesn't seem to be an impossible event given EC2's recent track record. Doesn't everything in their track record indicate that regions are nicely partitioned from each other? Even the biggest region failures they've had have stayed completely isolated to that region.

AZs were supposed to be that unit of isolation, then when multiple AZs failed that shifted to be Regions; it seemed like a "blame the victim" mentality to me. Given that AWS are running the same software across regions and have the same people & processes in place, and further that there's software that runs across regions (e.g. S3), I'd wager it's not long before we have a multi-region outage. Finally, some of the m…

Regions are 100% independent of one another, both physically and also control plane wise. Also code pushes to regions for new features don't ever happen on the same day.

Re: Surviving AWS Failures with a Node.js and MongoDB Stack

#19

Post by justinsb »

res0nat0r wrote: post #18
justinsb wrote: post #8

Earlier quoted context omitted.

AZs were supposed to be that unit of isolation, then when multiple AZs failed that shifted to be Regions; it seemed like a "blame the victim" mentality to me. Given that AWS are running the same software across regions and have the same people & processes in place, and further that there's software that runs across regions (e.g. S3), I'd wager it's not long before we have a multi-region outage. Finally, some of the m…

Regions are 100% independent of one another, both physically and also control plane wise. Also code pushes to regions for new features don't ever happen on the same day.

Source?

AZs were supposed to be independent; they aren't. Fool me one...

Re: Surviving AWS Failures with a Node.js and MongoDB Stack

#20

Post by traxtech »

shykes wrote: post #3

Here's how I do it: $ pip install dotcloud $ echo 'frontend: {"type": "nodejs"}' >> dotcloud.yml $ echo 'db: {"type": "mongodb"}' >> dotcloud.yml $ dotcloud push $MYAPP $ dotloud scale $MYAPP frontend=3 db=3 This will deploy my nodejs app across 3 AZs and setup load-balancing to them, deploy a Mongo replicaset across 3 AZs, setup authentication, and inject connection strings into the app's environment. It's also way…

I was interested, I digged into your docs : no postgresql scaling :(
Post reply on HN