Surviving AWS Failures with a Node.js and MongoDB Stack
1–10 of 33 posts
Re: Surviving AWS Failures with a Node.js and MongoDB Stack
#2You 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.
Re: Surviving AWS Failures with a Node.js and MongoDB Stack
#3Here'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
The only difference with OP's setup is that the Mongo ports are publicly accessible. This means authentication is the only thing standing between you and an attacker (and maybe the need to find your particular tcp port among a couple million others in dotCloud's pool).
(disclaimer, I work at dotCloud)
Re: Surviving AWS Failures with a Node.js and MongoDB Stack
#4Here'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…
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 for other services (with the possible exception of CloudFoundry, which was a sunk cost for us at that point anyway...). Maybe the on-boarding is a bit tough for new users? Where do you see the most significant drop-off in your funnel? If you don't mind sharing, of course.
Re: Surviving AWS Failures with a Node.js and MongoDB Stack
#5Here'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?
Re: Surviving AWS Failures with a Node.js and MongoDB Stack
#6You 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.
> 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.
Re: Surviving AWS Failures with a Node.js and MongoDB Stack
#7Here'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…
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, like any other feature of the product. There are people who specialize in crafting and projecting an image of success in a way that appears authentic. It is a difficult and highly specialized, not to mention it involves a fair amount of "fact distorsion" that doesn't appeal to us.
The second reason is that we're successful without it. When you and I say "developer buzz" we usually mean "HN-reading bleeding edge developer buzz", but 99.999% of our addressable market doesn't read HN. We crave our peer's appreciation and respect as much as everyone else - but at the end of the day, that's not what pays the bills. In our case, mid-aged developers and IT managers looking to remain competitive while circumventing office politics to get their development server in 6 weeks instead of 8 - that's what pays the bills.
Re: Surviving AWS Failures with a Node.js and MongoDB Stack
#8You 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.
> 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 multi-AZ problems in the past were compounded because as one AZ went down everyone hammered the other AZs, taking out the APIs at least. That's when everyone believed that AZs were isolated. Now that people know that's not the case, those same systems are going to be hammering across multiple regions.
Re: Surviving AWS Failures with a Node.js and MongoDB Stack
#9Considering 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.
Re: Surviving AWS Failures with a Node.js and MongoDB Stack
#10Considering 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.