5 ms·

Yes it's a single point of failure, but so what? I don't particularly care whether other organizations fail at the same time as I do, I just care whether I fail

Yes it's a single point of failure, but so what? I don't particularly care whether other organizations fail at the same time as I do, I just care whether I fail. Hosting my own chat system does not solve that problem. In fact, it may make it worse because then I have to worry about system administration, and Slack probably has more expertise on that. It's likely that they can fix this problem for all customers faster than I can fix my problem for myself. And it's not like I'm crippled when Slack is down. If it's urgent I can use the phone, and my todo list is stored outside Slack.

ljm 8y ago
In a way there's a second single point of failure though, right? So many people use Slack to integrate all kinds of things, and rely on their interaction with those platforms through Slack, that if Slack goes down then productivity halts and it's totally out of your hands while Slack themselves try to resolve the issue. - You don't get GitHub notifications on pull requests and comments, so things don't get reviewed and merged if developers aren't in the habit of checking the PR tab on GitHub itself. - You don't get CI notifications so you won't know how your latest test run or deploy is going without going straight into the CI service itself. Even worse when there's a failure and you're too used to having Slack warn you about that. - Your team might depend on Slack so much that they don't know how else to efficiently communicate, and the most efficient channel to communicate a fallback is not available or rarely checked (e.g. email, face to face). So you get a lot of chaos as people come up with dozens of alternatives. This is just poor discipline more than anything, putting too many structural eggs into one basket, but it doesn't change the fact that Slack has created that dependency.
- nettdata 8y ago
  If your team can't check on that stuff manually for a few hours while Slack is down, then I think you may have bigger problems. If anyone on my team came to me and cited Slack being down as a reason for their inability to do their job, then they wouldn't be on my team. Is it less than ideal? Yes. Is it a little bit less efficient to pull info instead of having it pushed to you? Yes. Is the sky falling? No.
sarreph 8y ago
> And it's not like I'm crippled when Slack is down. That's good for you (not being facetious), and good that you've built your workflow to not be reliant on it. My original point was that who knows how many people are too reliant on Slack though, e.g. for production-dependent notification / bot chains... Maybe that says something about their workflow and how there are underlying problems anyway for them. I too am happy to revert to analogue / other forms of communication. However, I don't want to start a 'look how sturdy our workflows are / how bad people are that rely on Slack too much' circle-jerk. I'm just arguing that it's clearly too much of a single point of failure for too many people at this point. It's essentially Too Big To Fail for too many people now.
philwelch 8y ago
> In fact, it may make it worse because then I have to worry about system administration, and Slack probably has more expertise on that. Although with outages like these, I doubt it!
mikec3010 8y ago
I think it's inexcusable for a chat program to go down in 2018. * your hdd failed? Use a raid * your power went out? Use a UPS * your DNS went down? Use a fallback (slack2) * your whole datacenter flooded? Good thing you have multiple replicated cloud instances that seamlessly take over See, these are the issues that "the cloud" was supposed to solve. Not give us the same problems as before, just with a recurring bill for "chat as a service". And inb4 "chill Mike it's just a chat server not life support firmware" yeah but slack is the most trivial software you can think of: send text from one computer to another. I see no reason this service can't be nearly as reliable as life support firmware in 2018. We've had over 30 years to get this right. Raise the fricking bar.
- subway 8y ago
  The dark truth is I suspect we're moving in the opposite direction. Abstraction layers designed with that "chill, it's just a %s app" mindset are making their way into safety critical applications. Eventually somebody is going to die because their pacemaker decided to throw cycles at mining monero.
- dota_fanatic 8y ago
  Slack is text, channels, images, video, sound, search, audio calls, video calls, screen share (and interface share), bots, myriad integrations, and more. Calling it just "send text from one computer to another" is wrong.
  - anderspitman 8y ago
    I think maybe their point is that even if other pieces break, why shouldn't it be possible for the text communication to keep working?
  - dustinmoorenet 8y ago
    If trying to provide all the other things besides text causes the system to be unstable, then maybe those things shouldn't have been added. We need text. We just want the other things.
- 8y ago
drb91 8y ago
> It's likely that they can fix this problem for all customers faster than I can fix my problem for myself. And it's not like I'm crippled when Slack is down. Well, you can probably infer the former from the dependency on the latter. You use these tools because they can reduce the scrambling when shit does hit the fan, not because they are necessary.
vasilipupkin 8y ago
if the software is architected this poorly so that it can literally go down simultaneously for all clients, then why would I trust that it's secure?

ljm 8y ago

In a way there's a second single point of failure though, right? So many people use Slack to integrate all kinds of things, and rely on their interaction with those platforms through Slack, that if Slack goes down then productivity halts and it's totally out of your hands while Slack themselves try to resolve the issue. - You don't get GitHub notifications on pull requests and comments, so things don't get reviewed and merged if developers aren't in the habit of checking the PR tab on GitHub itself. - You don't get CI notifications so you won't know how your latest test run or deploy is going without going straight into the CI service itself. Even worse when there's a failure and you're too used to having Slack warn you about that. - Your team might depend on Slack so much that they don't know how else to efficiently communicate, and the most efficient channel to communicate a fallback is not available or rarely checked (e.g. email, face to face). So you get a lot of chaos as people come up with dozens of alternatives. This is just poor discipline more than anything, putting too many structural eggs into one basket, but it doesn't change the fact that Slack has created that dependency.

nettdata 8y ago
If your team can't check on that stuff manually for a few hours while Slack is down, then I think you may have bigger problems. If anyone on my team came to me and cited Slack being down as a reason for their inability to do their job, then they wouldn't be on my team. Is it less than ideal? Yes. Is it a little bit less efficient to pull info instead of having it pushed to you? Yes. Is the sky falling? No.

sarreph 8y ago

> And it's not like I'm crippled when Slack is down. That's good for you (not being facetious), and good that you've built your workflow to not be reliant on it. My original point was that who knows how many people are too reliant on Slack though, e.g. for production-dependent notification / bot chains... Maybe that says something about their workflow and how there are underlying problems anyway for them. I too am happy to revert to analogue / other forms of communication. However, I don't want to start a 'look how sturdy our workflows are / how bad people are that rely on Slack too much' circle-jerk. I'm just arguing that it's clearly too much of a single point of failure for too many people at this point. It's essentially Too Big To Fail for too many people now.

philwelch 8y ago

> In fact, it may make it worse because then I have to worry about system administration, and Slack probably has more expertise on that. Although with outages like these, I doubt it!

mikec3010 8y ago

I think it's inexcusable for a chat program to go down in 2018. * your hdd failed? Use a raid * your power went out? Use a UPS * your DNS went down? Use a fallback (slack2) * your whole datacenter flooded? Good thing you have multiple replicated cloud instances that seamlessly take over See, these are the issues that "the cloud" was supposed to solve. Not give us the same problems as before, just with a recurring bill for "chat as a service". And inb4 "chill Mike it's just a chat server not life support firmware" yeah but slack is the most trivial software you can think of: send text from one computer to another. I see no reason this service can't be nearly as reliable as life support firmware in 2018. We've had over 30 years to get this right. Raise the fricking bar.

subway 8y ago
The dark truth is I suspect we're moving in the opposite direction. Abstraction layers designed with that "chill, it's just a %s app" mindset are making their way into safety critical applications. Eventually somebody is going to die because their pacemaker decided to throw cycles at mining monero.
dota_fanatic 8y ago
Slack is text, channels, images, video, sound, search, audio calls, video calls, screen share (and interface share), bots, myriad integrations, and more. Calling it just "send text from one computer to another" is wrong.
- anderspitman 8y ago
  I think maybe their point is that even if other pieces break, why shouldn't it be possible for the text communication to keep working?
- dustinmoorenet 8y ago
  If trying to provide all the other things besides text causes the system to be unstable, then maybe those things shouldn't have been added. We need text. We just want the other things.
8y ago

drb91 8y ago

> It's likely that they can fix this problem for all customers faster than I can fix my problem for myself. And it's not like I'm crippled when Slack is down. Well, you can probably infer the former from the dependency on the latter. You use these tools because they can reduce the scrambling when shit does hit the fan, not because they are necessary.

vasilipupkin 8y ago

if the software is architected this poorly so that it can literally go down simultaneously for all clients, then why would I trust that it's secure?