6 ms·

Or how about "I'm fully aware, I've done the math taking into account both cost and complexity of implementation and cost of downtime, and I'm probably making f

Or how about "I'm fully aware, I've done the math taking into account both cost and complexity of implementation and cost of downtime, and I'm probably making fantastic calls based on my actual needs."

happymellon 4y ago
If you had "done the math" then you would have gone serverless and gained multi-az for free, as it is almost always the cheapest option.
- the_fury 4y ago
  This has quickly grown to more than adding in a couple of lines! Now I need to architect my legacy app so that I can deploy into lambdas, then I can get resiliency I don't really need! Not all systems require high availability. Some systems are A-OK with downtime. Sometimes, I'm perfectly fine with eventual consistency. You really do have to look at the use-cases and requirements before making sweeping staements.
  - happymellon 4y ago
    I thought we were talking about cloud architects making poor decisions when designing solutions. Where did legacy apps come from? > Some systems are A-OK with downtime. And those ones would not have cared about this outage. Your point isn't that clear.
    - the_fury 4y ago
      No, we were talking about architechts making decisions that you characterised as poor. I was pointing out that your statement was over-general and that there are many instances where making the informed decision to ignore HA is a completely reasonable thing to do. By your last sentence, it appears you agree with me. If you meant to say that your statement only applies to cloud architects who are attempting to maintain an uptime SLA with multi-az/region redundancy, then sure, AWS has lots of levers you can pull and those complaining really should spend some time studying them. As for legacy applications, I would not have brought up them up at all if you hadn't suggested pushing things into lambdas as a solution to multi-az. Once again, there are many many situations where this is not appropriate. Not everything is greenfield, and re-architecting existing applications in an attempt to shoehorn it into a different deployment model seems a bit much. Unless I'm misunderstanding what you meant.
- yibg 4y ago
  Right, because magically serverless is the right answer for every application.

happymellon 4y ago

If you had "done the math" then you would have gone serverless and gained multi-az for free, as it is almost always the cheapest option.

the_fury 4y ago
This has quickly grown to more than adding in a couple of lines! Now I need to architect my legacy app so that I can deploy into lambdas, then I can get resiliency I don't really need! Not all systems require high availability. Some systems are A-OK with downtime. Sometimes, I'm perfectly fine with eventual consistency. You really do have to look at the use-cases and requirements before making sweeping staements.
- happymellon 4y ago
  I thought we were talking about cloud architects making poor decisions when designing solutions. Where did legacy apps come from? > Some systems are A-OK with downtime. And those ones would not have cared about this outage. Your point isn't that clear.
  - the_fury 4y ago
    No, we were talking about architechts making decisions that you characterised as poor. I was pointing out that your statement was over-general and that there are many instances where making the informed decision to ignore HA is a completely reasonable thing to do. By your last sentence, it appears you agree with me. If you meant to say that your statement only applies to cloud architects who are attempting to maintain an uptime SLA with multi-az/region redundancy, then sure, AWS has lots of levers you can pull and those complaining really should spend some time studying them. As for legacy applications, I would not have brought up them up at all if you hadn't suggested pushing things into lambdas as a solution to multi-az. Once again, there are many many situations where this is not appropriate. Not everything is greenfield, and re-architecting existing applications in an attempt to shoehorn it into a different deployment model seems a bit much. Unless I'm misunderstanding what you meant.
yibg 4y ago
Right, because magically serverless is the right answer for every application.