Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Incident at Slack

status.slack.com

Post reply on HN
Print view View original

81–90 of 96 posts

Re: Incident at Slack

#81

Post by jzer0cool »

aaronblohowiak wrote: post #75
jzer0cool wrote: post #5

This is more a service degradation / outage than an incident.

How do you differentiate outage from incident?

The title here might as well be called — "Something happened at Slack".

Could you be more specific? — "An incident at Slack"

Could you be more specific? — "An outage at Slack"

Could you be more specific? — "..."

Would rather see something more specific:

"File Upload & Emoji Service Degradation at Slack" ( — insert emoji memes ).

Arguably, title is a bit misleading whether it warrants front page news for this community.

Re: Incident at Slack

#82

Post by Nextgrid »

TranquilMarmot wrote: post #80
ActionHank wrote: post #70

Earlier quoted context omitted.

Don't underestimate just how much devs can dig their heels in because they want to work in JS.

Is there a problem with this? Other than "JS Bad" chest-thumping? If so many devs want to work in it, there's probably a reason.

If you're a JS developer and don't know (or enjoy) other languages, the most lucrative choice is to keep using JS and advocating for it whenever possible.

If they've already got many JS developers onboard, it's normal that their opinion will be biased and they wouldn't want to switch to another language and essentially make their own job obsolete (except for the minority that also happens to be equally-proficient in whatever desktop programming language is chosen).

Re: Incident at Slack

#83

Post by theandrewbailey »

makeavish wrote: post #52
5350-uiop-1130 wrote: post #31

I find slack so bloated and slow it would probably take me about 15 minutes to realise it was actually down.

Slack should develop native apps now as they are no longer a lean startup and can afford to build native apps.

Salesforce bought Slack last year. They can afford to build native apps, but that might go against the whole cloud computing thing they've got going.

https://www.salesforce.com/news/press-releases/2021/07/21/sa...

Re: Incident at Slack

#84

Post by Nextgrid »

einpoklum wrote: post #63
braymundo wrote: post #32

Time for self-hosted https://rocket.chat :)

Not FOSS, not a public protocol (IIANM), so - that's not it either.

It's still a good solution for downtime issues, since at the very least you can schedule your own server's maintenance at a time when nobody will be impacted if it goes wrong.

Re: Incident at Slack

#85

Post by TranquilMarmot »

Nextgrid wrote: post #82
TranquilMarmot wrote: post #80

Earlier quoted context omitted.

Is there a problem with this? Other than "JS Bad" chest-thumping? If so many devs want to work in it, there's probably a reason.

If you're a JS developer and don't know (or enjoy) other languages, the most lucrative choice is to keep using JS and advocating for it whenever possible. If they've already got many JS developers onboard, it's normal that their opinion will be biased and they wouldn't want to switch to another language and essentially make their own job obsolete (except for the minority that also happens to be equally-proficient in…

I've been working at web-based startups for over 10 years now, and I know VERY few devs who only know JS. Most are also proficient (or at least have working knowledge of) whatever other languages we're using. Usually JVM-based like Java, Kotlin, Scala or something else like Ruby or Elixir.

Everywhere I've been, we always "choose the right tool for the job". Recently, making apps that can run across every OS and in the browser, the right tool for the job has been JS (well, TypeScript these days, but same thing).

Re: Incident at Slack

#86

Post by jacobr1 »

smazga wrote: post #61
brimble wrote: post #55

Earlier quoted context omitted.

Slack should at least bridge to an open protocol, if not use one outright, so I can use any client I want. Like they used to.

The gloss of Slack was lost to me when they took down the irc and xmpp bridges. I really liked the freedom to do it my way. Then it became just another crappy messaging app.

If all you want is messaging, use irc, matrix or an xmpp system. The real value of slack is all the integrations and ecosystem built on top of it. That is much harder to integrate with an arbitrary client. It could be done, they could publish "enriched messaging" standards or similar and breakout capabilities that clients could support, but just supporting vanilla messaging at this point would be a severe degradation of slack's capabilities.

Re: Incident at Slack

#87

Post by can16358p »

zht wrote: post #39
can16358p wrote: post #37

Earlier quoted context omitted.

If it's on a different domain and servers, I don't think it will be an issue. If they have it on an API call to (making it up) api.slack.com/status it might very well go down when things go wrong, making it useless. However if they physically host it elsewhere ideally on a different cloud provider, with a different domain, say, slackstatus.com/api-status that is completely separate from the actual services, which can…

this sounds very complicated lol

Initial setup is not much different than creating a new website, rest is trivial in practice. Easier than said.

Re: Incident at Slack

#88

Post by yurishimo »

bananabiscuit wrote: post #65
72deluxe wrote: post #60

Earlier quoted context omitted.

I can't work out why you wouldn't develop a native app anyway - all this scaffolding in a Web UI to imitate native controls (like menus) seems completely backwards to me. Seems just lazy, but in an odd way because writing native apps isn't rocket science or difficult. It's not like they're implementing thousands of native controls or user interface components - a listview with an edit box at the bottom...

I am a fan of native apps but I do have to admit it is nice that slack is -exactly- the same on any platform you access it from and that will continue to be the case without any effort from their developers. Different ports of native apps invariably start drifting unless lots of care is taken to make sure they don’t, and that does not happen to always be a priority for companies.

This is true and a valid use case I think. Slack has abstracted enough of their UI to be re-usable cross platform that any re-write would likely be a regression.

Look at 1Password and the amount of shit they get on HN with the beta version. Rewrites are hard and they take a tooooooon of time to do correctly and require a lot of engineering work to keep the product consistent across platforms.

Do I wish that electron apps were better optimized? Yes, however, I also can accept the tradeoff for apps that need to work "everywhere".

For the most part, Slack works just fine. Their problems are less the UI/UX and more to do with infrastructure. Slack rewriting to a native app would have a tiny (if any) effect on these outages.

Re: Incident at Slack

#89

Post by molotovbliss »

uoaei wrote: post #73
einpoklum wrote: post #72

Earlier quoted context omitted.

I like the idea of Matrix, but - can you get simple, thin, GUI clients for it like you have for IRC? IIRC, most GUI clients for it feel like something running inside my web browser...

Many options here: https://matrix.org/clients/ Seems to be more on the "glossy" and "web client" end of the spectrum in general but probably there is some reasonable compromise to be reached from the proliferation of different clients.

Element is a pretty nice client for matrix. Only been using it for a week but it's not too shabby on Windows/Android.

https://element.io/

Re: Incident at Slack

#90

Post by bayindirh »

macinjosh wrote: post #50
hoffs wrote: post #21

Earlier quoted context omitted.

Downtime is not the same as service disruption

huh?

You can announce downtime for a certain capacity of a service ahead of time. Which is essentially planned maintenance with some capacity hit, but when it's unplanned it's called disruption. Also, generally disruptions come with a bigger capacity loss, even if you don't lose the service outright.

These terms are not limited to cloud infrastructures and not new either. Computation clusters use these terms for at least 12-13 years (from my experience) or for even longer.

Post reply on HN