3 ms·

The only problem I have with this, is that for a really simple system consisting of 3 components (web+app+db) now I need to deploy (and pay for!!) 24 components

by rytis 14y ago

The only problem I have with this, is that for a really simple system consisting of 3 components (web+app+db) now I need to deploy (and pay for!!) 24 components. Yes I know, business continuity and stuff. Still, just doesn't feel right somehow.

jasonkester 14y ago
Most businesses can make the conscious decision to go with the simple 3-component option and accept that they might only get three or four nines of uptime, depending on how flaky AWS decides to be that year. If you run a service where the worst case scenario for your site being down for an hour on a Thursday afternoon is "millions of dollars are lost" or "our high profile customers go out of business in a way that's directly traceable back to us" then yes, you need all 24 of those things. If, on the other hand, the worst case scenario for your site being down for an hour on a Thursday afternoon is "some of our customers have to manually post to Facebook so that their friends know that they've been for a run", you can probably shave about 21 nodes off that diagram.
- danoprey 14y ago
  Well said! Often the right thing to do in an outage is "wait it out".
snorkel 14y ago
Exactly. You have to weigh cost of the worst case downtime vs cost of redundancy (and not to mention the added complexity of keeping all redundant systems in sync)
peterwwillis 14y ago
You have options. You can pay for and run just three components on AWS, and still have the power of dynamically scaling your application when you need to. You can then pay for three really cheap VPS's and load balancers around the world using something like Linode (or a much less reliable VPS, doesn't really matter) and replicate your data occasionally to the VPS. When your AWS instance goes down (because you foolishly rely on the same Virginia datacenter that has more breakdowns than Lindsay Lohan) you cut over to the hot spare VPS and rate-limit your incoming requests until AWS comes back. You end up paying for 6(ish) services, still relying mostly upon AWS but with a tiny DR site you can use during emergencies.
inopinatus 14y ago
You can get away with just a db replica to another region. In the event of a major outage in the primary region, promote the replica and boot the other stuff you need in the secondary region. Don't bother with AZs, they've proven not to be an independent unit of availability.
thematt 14y ago
Not to mention it will cost a lot of money.

by rytis 14y ago

jasonkester 14y ago

Most businesses can make the conscious decision to go with the simple 3-component option and accept that they might only get three or four nines of uptime, depending on how flaky AWS decides to be that year. If you run a service where the worst case scenario for your site being down for an hour on a Thursday afternoon is "millions of dollars are lost" or "our high profile customers go out of business in a way that's directly traceable back to us" then yes, you need all 24 of those things. If, on the other hand, the worst case scenario for your site being down for an hour on a Thursday afternoon is "some of our customers have to manually post to Facebook so that their friends know that they've been for a run", you can probably shave about 21 nodes off that diagram.

danoprey 14y ago
Well said! Often the right thing to do in an outage is "wait it out".

snorkel 14y ago

Exactly. You have to weigh cost of the worst case downtime vs cost of redundancy (and not to mention the added complexity of keeping all redundant systems in sync)

peterwwillis 14y ago

You have options. You can pay for and run just three components on AWS, and still have the power of dynamically scaling your application when you need to. You can then pay for three really cheap VPS's and load balancers around the world using something like Linode (or a much less reliable VPS, doesn't really matter) and replicate your data occasionally to the VPS. When your AWS instance goes down (because you foolishly rely on the same Virginia datacenter that has more breakdowns than Lindsay Lohan) you cut over to the hot spare VPS and rate-limit your incoming requests until AWS comes back. You end up paying for 6(ish) services, still relying mostly upon AWS but with a tiny DR site you can use during emergencies.

inopinatus 14y ago

You can get away with just a db replica to another region. In the event of a major outage in the primary region, promote the replica and boot the other stuff you need in the secondary region. Don't bother with AZs, they've proven not to be an independent unit of availability.

thematt 14y ago

Not to mention it will cost a lot of money.