4 ms·

Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though.

by adra 5y ago

Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers. Scale horizontally and you're often constraining and or complicating your design/architecture, but you can handle outages far better, if not seamlessly. It's much harder to get right, so it's usually best for more senior teams that have specific need for it.

Nextgrid 5y ago
I've seen more outages (or worse - silent data corruption, inconsistency, or deviations from the intended business rules) due to home-brewed, horizontally-scalable engineering playgrounds having a flaw than a good old Postgres on bare-metal hardware suddenly going dark.
latch 5y ago
It's wrong to mix horizontal scaling with availability. They are two different things that solve two different problems and solving one doesn't necessarily mean you've solved the other. You can scale horizontally in a way that decreases your total availability, e.g. by sharding.
- urthor 5y ago
  Essentially. Limited horizontal replication is not the same as PAXOS.
robryan 5y ago
This really depends. The majority of services out there that can get away with a single box for a scale perspective can probably afford just to take the downtime.
lelanthran 5y ago
> Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers. How fatal[1]? Not all outages are fatal. Scale vertically and you'll have some downtime if any node between (and in) your user and your system goes down. For 999 out of a thousand businesses, it won't be fatal. If your business is so fragile that the first 24 hour outage kills it, then it would have been killed anyway in the near future. [1] I know, this is liking asking "how pregnant?"...
gunnarmorling 5y ago
> Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. When folks talk about scaling up for stateful resources (database), this typically includes having stand-by replicas to which one can fail over within seconds. Scaling up the DB and scaling out stateless compute nodes is more than enough for many, many use cases. Having a DB machine with one 1TB RAM isn't anything special these days.
ryanbrunner 5y ago
> Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers. Setting up something like a read replica on RDS (or frankly even a DB you manage yourself is pretty trivial, especially if you're using it solely for availability and not actually reading from it.

by adra 5y ago

Nextgrid 5y ago

I've seen more outages (or worse - silent data corruption, inconsistency, or deviations from the intended business rules) due to home-brewed, horizontally-scalable engineering playgrounds having a flaw than a good old Postgres on bare-metal hardware suddenly going dark.

latch 5y ago

It's wrong to mix horizontal scaling with availability. They are two different things that solve two different problems and solving one doesn't necessarily mean you've solved the other. You can scale horizontally in a way that decreases your total availability, e.g. by sharding.

urthor 5y ago
Essentially. Limited horizontal replication is not the same as PAXOS.

robryan 5y ago

This really depends. The majority of services out there that can get away with a single box for a scale perspective can probably afford just to take the downtime.

lelanthran 5y ago

> Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers. How fatal[1]? Not all outages are fatal. Scale vertically and you'll have some downtime if any node between (and in) your user and your system goes down. For 999 out of a thousand businesses, it won't be fatal. If your business is so fragile that the first 24 hour outage kills it, then it would have been killed anyway in the near future. [1] I know, this is liking asking "how pregnant?"...

gunnarmorling 5y ago

> Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. When folks talk about scaling up for stateful resources (database), this typically includes having stand-by replicas to which one can fail over within seconds. Scaling up the DB and scaling out stateless compute nodes is more than enough for many, many use cases. Having a DB machine with one 1TB RAM isn't anything special these days.

ryanbrunner 5y ago

> Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers. Setting up something like a read replica on RDS (or frankly even a DB you manage yourself is pretty trivial, especially if you're using it solely for availability and not actually reading from it.