3 ms·

"But what if _the_ machine goes down ? What if it goes down _during quarter earnings legally requested reporting consolidation period_ ? We need _redundancy_ !!

"But what if _the_ machine goes down ? What if it goes down _during quarter earnings legally requested reporting consolidation period_ ? We need _redundancy_ !!" Also, philosophically, I guess, a "distributed" systems starts at "two machines". (And you actually get most of the "fun" of distributed systems with "two processes on the same machine".) We're taught how to deal with "N=1" in school, and "N=all fans of Taylor Swift in the same seconds" in FAANGS. Yet I suspect most people will be working on "N=12, 5 hours a day during office hours, except twice a year." And I'm not sure what's the reference techniques for that.

arinlen 4y ago
> Also, philosophically, I guess, a "distributed" systems starts at "two machines". People opening a page in a browser that sends requests to a server is already a distributed system. A monolith sending requests to a database instance is already a distributed system. Having a metrics sidecar running along your monolith is already a distributed system.
- phtrivier 4y ago
  > A monolith sending requests to a database instance is already a distributed system. True, of course. And even a simple set like this brings in "distribution" issues for the app developper: When do you connect ? When do you reconnect ? Where do you get your connection credentials from ? What should happen when those credentials have to change ? Do you ever decide to connect to a backup db ? Do you ever switch your application logic to a mode where you know the DB is down, but you still try to work without it anyway ? Etc.. Those examples are specific to DBS, but in a distributed system any other services brings in the same questions. With experience you get opinions and intuitions about how to attack each issues ; my question is still : "should you need to point a newcomer to some reference / book about those questions, where would you point to ?"
User23 4y ago
> Yet I suspect most people will be working on "N=12, 5 hours a day during office hours, except twice a year." And I'm not sure what's the reference techniques for that. Here you go: http://bofh.bjash.com/ http://bofh.bjash.com/

arinlen 4y ago

> Also, philosophically, I guess, a "distributed" systems starts at "two machines". People opening a page in a browser that sends requests to a server is already a distributed system. A monolith sending requests to a database instance is already a distributed system. Having a metrics sidecar running along your monolith is already a distributed system.

phtrivier 4y ago
> A monolith sending requests to a database instance is already a distributed system. True, of course. And even a simple set like this brings in "distribution" issues for the app developper: When do you connect ? When do you reconnect ? Where do you get your connection credentials from ? What should happen when those credentials have to change ? Do you ever decide to connect to a backup db ? Do you ever switch your application logic to a mode where you know the DB is down, but you still try to work without it anyway ? Etc.. Those examples are specific to DBS, but in a distributed system any other services brings in the same questions. With experience you get opinions and intuitions about how to attack each issues ; my question is still : "should you need to point a newcomer to some reference / book about those questions, where would you point to ?"

User23 4y ago

> Yet I suspect most people will be working on "N=12, 5 hours a day during office hours, except twice a year." And I'm not sure what's the reference techniques for that. Here you go: http://bofh.bjash.com/ http://bofh.bjash.com/