3 ms·

> The thing most appealing about single server configs is the simplicity. The more simple a system easy, likely the more reliable and easy to understand. What

> The thing most appealing about single server configs is the simplicity. The more simple a system easy, likely the more reliable and easy to understand. What if your unique machine crash?

readonlybarbie 4y ago
[dead]
andrewstuart 4y ago
Well you gotta have a backup strategy. I'm talking about the primary machine here, I assumed that would be obvious but maybe not. You build your failover strategy into your architecture - there's lots of ways to do it - I use Postgres so I would favor something based around log shipping.
- ffssffss 4y ago
  And uptime is important, so you want to have that secondary running and ready, with a proxy in front of everything so you can switch as soon as you detect a failure. That's three hosts, plus your alerting has to be separate too, so that's four. Now, to orchestrate all this, we'll first get out Puppet...
  - toast0 4y ago
    If you're going from one machine to two, and you add an automatically failover mechansim, chances are your load switching mechanism is going to cause more downtime than just running from your single machine, and manually switching on failure (after being paged).
pclmulqdq 4y ago
You spin up a backup as the new "unique machine."
fbdab103 4y ago
I think you should always plan for failures, but modern enterprise hardware is quite reliable. I would even posit that if you stood up a brand new physical server today, it has a good chance of beating AWS uptime (well, not the AWS dashboard numbers) over a one year period.
- jupp0r 4y ago
  "hardware is quite reliable" is not a valid strategy. Hardware fails with some non-zero probability. You need to have a plan in place what to do if that happens, taking into account service disruption, backups etc. Having a system in place that handles most of this gracefully (like kubernetes) is one way of having such a plan, there are others. Which one works best is dependent on your app, cost of downtime, your team that's tasked with bringing everything back up in the middle if the night, etc. People who leave details like this out when they say "kubernetes is complicated" just haven't seen the complexities of operating a service well.
  - fbdab103 4y ago
    My first sentence was to always plan for failures.
    - jupp0r 4y ago
      Yeah sorry it wasn't meant to dispute your argument, just as an addition.
  - Nextgrid 4y ago
    Keep in mind that the complexity of your distributed system is a liability itself. Most cloud or large company downtimes aren't due to hardware failure per-se but either operator error or unexpected interactions between components of their distributed system. You might just be trading one source of downtime for another. > the complexities of operating a service well. Keep in mind that in a lot of business applications, downtime isn't the end of the world and might be an accepted and priced-in "cost" of doing business. Operating it as you consider "well" would just cost them more with no benefit.

> The thing most appealing about single server configs is the simplicity. The more simple a system easy, likely the more reliable and easy to understand. What if your unique machine crash?

readonlybarbie 4y ago

[dead]

andrewstuart 4y ago

Well you gotta have a backup strategy. I'm talking about the primary machine here, I assumed that would be obvious but maybe not. You build your failover strategy into your architecture - there's lots of ways to do it - I use Postgres so I would favor something based around log shipping.

ffssffss 4y ago
And uptime is important, so you want to have that secondary running and ready, with a proxy in front of everything so you can switch as soon as you detect a failure. That's three hosts, plus your alerting has to be separate too, so that's four. Now, to orchestrate all this, we'll first get out Puppet...
- toast0 4y ago
  If you're going from one machine to two, and you add an automatically failover mechansim, chances are your load switching mechanism is going to cause more downtime than just running from your single machine, and manually switching on failure (after being paged).

pclmulqdq 4y ago

You spin up a backup as the new "unique machine."

fbdab103 4y ago

I think you should always plan for failures, but modern enterprise hardware is quite reliable. I would even posit that if you stood up a brand new physical server today, it has a good chance of beating AWS uptime (well, not the AWS dashboard numbers) over a one year period.

jupp0r 4y ago
"hardware is quite reliable" is not a valid strategy. Hardware fails with some non-zero probability. You need to have a plan in place what to do if that happens, taking into account service disruption, backups etc. Having a system in place that handles most of this gracefully (like kubernetes) is one way of having such a plan, there are others. Which one works best is dependent on your app, cost of downtime, your team that's tasked with bringing everything back up in the middle if the night, etc. People who leave details like this out when they say "kubernetes is complicated" just haven't seen the complexities of operating a service well.
- fbdab103 4y ago
  My first sentence was to always plan for failures.
  - jupp0r 4y ago
    Yeah sorry it wasn't meant to dispute your argument, just as an addition.
- Nextgrid 4y ago
  Keep in mind that the complexity of your distributed system is a liability itself. Most cloud or large company downtimes aren't due to hardware failure per-se but either operator error or unexpected interactions between components of their distributed system. You might just be trading one source of downtime for another. > the complexities of operating a service well. Keep in mind that in a lot of business applications, downtime isn't the end of the world and might be an accepted and priced-in "cost" of doing business. Operating it as you consider "well" would just cost them more with no benefit.