Live data from Hacker News

Slack is down

status.slack.com

791–800 of 840 posts

Re: Slack is down

#791
post #661

Earlier quoted context omitted.

> self-hosted How often is Slack/Discord down? I mean it's not perfect, but I really honestly don't think I could match their uptime by self-hosting, as well as more on-call rotations for something that's not core product. I very much prefer that for something that isn't core product, if it goes down I need to do exactly nothing for it to come back up, and that the engineers at Slack will be starting to work on it li…

I would be surprised if you couldn't match or exceed slacks uptime running whatever alternative you want (IRC, mattermost, rocketchat, etc.) on a random dedicated server. Hardware is quite reliable these days. And updates can be scheduled to be at a convenient time for the team.

[deleted]

Re: Slack is down

#792
post #768

Earlier quoted context omitted.

Is it really though? If I take a look at a random modern IRC desktop client - how is it more difficult to setup than say your email program? The amount of information needed on setup is about the same: server, username, password (in fact email can get a bit more confusing in big corporate email setups with differing imap and smtp servers, etc.) Also there are plenty of modern web clients for IRC, such as https://thel…

> your email program Reality check: Most people don't use email programs anymore. Also how do you get IRC to sync all conversation data, history, between your several desktops and phones, how do you send files, make calls, and thread conversations?

But clearly no one is saying that email is too hard to use and we should just use $something_else (or are they?).

And you are starting to move goalposts here.. first it was uptime, then it was operations and now it's features...

And what about those web based IRC solutions? They are even easier to use than slack, have combined history, file sharing, etc.

Re: Slack is down

#793

I'd like to take this moment to mention self-hosted, open source, and federated alternatives like XMPP and Matrix. I'd like to, but unfortunately I don't feel like I can in good faith. Matrix is woefully immature, and suffers from a lot of issues, but I think is closer to being a functional Slack/Discord alternative. XMPP is much more mature, and works very well for chat, but doesn't have a nice package that does all…

There is also Mattermost which is literally like Slack, but self-hosted.

Re: Slack is down

#794

Earlier quoted context omitted.

> And it doesn't work at all with low power mobile delivery. What makes you think so? If Conversations was draining my battery, I would have noticed by now, I'm pretty sure that Facebook Messenger is worse in this aspect...

Maybe things have changed - certainly when I looked at it a few years ago (around the time that google stopped supporting it) my understanding was that xmpp had no push notification support. The app in the phone had to either poll or explicitly hold open a TCP connection. (Which is problematic when the app is backgrounded.) Has this been fixed in XMPP?

Yes, XMPP has had push notification support for years. It's the only way can work on mobile these days.

Re: Slack is down

#795
post #397

And there we have it: Relying on big companies sucks. It's great as long as it works. Once a system breaks thousands, or even millions, of businesses suffer. (Of course they are also beneficial and a private server can also crash at any time + I don't wanna blame Slack, but we always have to keep this in mind).

If a big company has million customers and the big company experiences an outage per quater, then a million businesses suffer every quater. If a thousand small companies have thousand customers each. And these small companies experience an outage per quater, then a million businesses suffer every quater. As the end-user-business, is it better to suffer the outage at the same time as other businesses? Is it worse? Sur…

> If a thousand small companies have thousand customers each. And these small companies experience an outage per quater, then a million businesses suffer every quater.

Not all companies are created the same. Microsoft, Google and Facebook have had their outages, but IME much fewer than Slack.

If there are a thousand small companies, none of them have a network effect, and those that experience more outages per quarter will lose customers to those that have less outages per quarter. So they have much more incentive to improve.

Whereas network-effect beneficiaries like Facebook (and to a lesser extent, Google, Microsoft and Slack) have much less of an incentive to improve. Who else would the customers go to?

Re: Slack is down

#796

I'd like to take this moment to mention self-hosted, open source, and federated alternatives like XMPP and Matrix. I'd like to, but unfortunately I don't feel like I can in good faith. Matrix is woefully immature, and suffers from a lot of issues, but I think is closer to being a functional Slack/Discord alternative. XMPP is much more mature, and works very well for chat, but doesn't have a nice package that does all…

Facebook and other vendors killed XMPP, we lived in a non federated world in Enterprise and consumer. No interest of companies to change this

XMPP is hardly killed. There are tens of thousands of XMPP servers out there with over a hundred public servers. There are lots of client implementations. Even the really bad implementations manage basic messaging.

Re: Slack is down

#797

Earlier quoted context omitted.

This is one of the original concepts why to go capital-A Agile. Make smaller releases more often, so at least if something breaks, it's (hopefully) something small, and least it's easier to trace. (I'm not making a statement if that's good or bad or if it works or whatever. Please don't read an opinion into it.)

This. If you roll many changes into a single deployment, you don’t know which change broke what. But if you have two or three weeks of commits waiting, it’s hard to do otherwise.

That's why good regression tests and CI are so important; in an ideal world (which we were close to in one of my projects), every change is pending in a pull request; the CI rebases the change on top of its upstream (e.g. master/main), simulating the state the codebase will be in once merged, and runs the full suite of tests. The build is invalidated and has to be re-run if either the branch or upstream is changed.

Now, caveats etc, this was a collection of single applications in a big microservices architecture, and as the project grows it becomes more and more difficult to manage something like this, especially if you get more pull requests in the time it takes to do a build. But it is the way to go, I think.

Anyway, since tests and CI are not definitive, you also need a gradual rollout - 1%, 5%, etc - AND you need a similar process for any infrastructure change, which gets more and more tricky as you go down to the hardware level.

Re: Slack is down

#798

I'd like to take this moment to mention self-hosted, open source, and federated alternatives like XMPP and Matrix. I'd like to, but unfortunately I don't feel like I can in good faith. Matrix is woefully immature, and suffers from a lot of issues, but I think is closer to being a functional Slack/Discord alternative. XMPP is much more mature, and works very well for chat, but doesn't have a nice package that does all…

That takes care of the software and protocol side of things, true, but does it give more reliable and predictable uptime? That's the main thing here; while there are plenty of software alternatives to Slack, their product is not just the software but also the hardware, servers, and scaling. You can get a Slack instance from 10 to >10K members without ever having to worry about your hardware, or how much hours your staff needs to spend on maintaining said hardware. And when there is inevitably downtime, you and your staff don't have to scramble to get it back up - with this outage, it's a shrug, it's down, it'll be back soon probably, I'm going to do some work or do something else. Extended toilet / lunch break.

Re: Slack is down

#799

Earlier quoted context omitted.

Rather than storing state from the server in the JS heap, new state gets stored immediately in indexeddb transactionally and is pulled out strictly on demand. So, my account (which is admittedly large, with around 3000 rooms and 350K users visible) uses 1.4GB of JS heap on Element/Web, and 14MB on Hydrogen. It's also lightning fast, as you might expect given it's not having to wade around shuffling gigabytes of javas…

I've wanted to try something like this (on a smaller scale), but haven't had time. It's good to hear of an implementation that reflects my expectations. How long did it take you to migrate over?

it’s a entirely new codebase; probably best way to visualise progress is to look at the contributor graphs at https://github.com/vector-im/hydrogen-web

Re: Slack is down

#800
post #156
post #136

Earlier quoted context omitted.

I haven't worked at Slack, so I can't speak with high confidence. A traffic spike is a possible reason, but I'm willing to bet that it's not the reason: > Doubt anyone releasing big changes Monday morning. This is definitely an engineering best practice, and by best practice, I mean something that Uber's, I mean Slack's SRE team strongly pushed for, and got politely overruled on. After a code freeze is lifted, it's q…

You just don't deploy something major the first day after a 2 weeks vacation, it does not makes any sense.

8am in the first day is too early... But by 10am, after catching up on emails, it's totally time to start releasing stuff.
Post reply on HN