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

Slack’s migration to a cellular architecture

slack.engineering

Post reply on HN
Print view View original

131–140 of 265 posts

Re: Slack’s migration to a cellular architecture

#131

Post by snoman »

skullone wrote: post #89
t0mas88 wrote: post #84

They got themselves into a mess here: > This turns out to have a lot of complexity lurking within. Slack does not share a common codebase or even runtime; services in the user-facing request path are written in Hack, Go, Java, and C++. This would necessitate a separate implementation in each language. This sounds crazy. I've seen several products where there is a core stack (e.g. Java) and then surrounding tools, ana…

It even pains me to see they're suffering from so many own goals. And it's unfortunately reflected in the poor experience using the Slack client. Not to mention the multiple deprecated bot/integration APIs with such bad feature parity between all the different ways to integrate your own tooling into Slack.

There was a time when this was the case (and electron was the punching bag for critics at the time, iirc) but I don’t think this criticism is fair anymore. Slack is quite responsive and performant these days.

Re: Slack’s migration to a cellular architecture

#132

Post by davedx »

muglug wrote: post #105
alberth wrote: post #61

Earlier quoted context omitted.

Hi Matt Thanks for Psalm! Curious, if Slack was built today from ground up - what tech stack do you think should/would be used?

That’s a simple question that’s hard to answer. A slightly different question that’s a bit easier to answer: “if I could wave a magic wand and X million lines of code were instantly rewritten and all developers were instantly trained on that language”. There the choice would be limited to languages that have similar or faster perf characteristics to Hack, without sacrificing developer productivity. Rust is out of the…

Not erlang?

Re: Slack’s migration to a cellular architecture

#133

Post by skullone »

antoniojtorres wrote: post #126
skullone wrote: post #7

Earlier quoted context omitted.

Just odd a company worth billions and billions of dollars is just now discovering HA models standard since the 90s. Can expand the Clos network architecture to these distributed service applications too. But judging by Slack's client quality, mature concepts such as those must be new to them.

The linked AWS article specifically explains that it’s not just the typical single load balancer for cross AZ routing. I frankly don’t know where you’re getting that this means that HA is new to them.

Of course this isn't a typical single load balancer for cross AZ - but the general gist of their "new" architecture is first principles level of design. But sure, we can celebrate their minor achievement I guess

Re: Slack’s migration to a cellular architecture

#134

Post by tmpX7dMeXU »

fiddlerwoaroof wrote: post #127

The thing I don't understand about Slack is how the core functionality seems to have continuously degraded since I started using it in ~2015. When I started using it, its core message sending features basically didn't have the issues with delayed messages or failure to send that I had experienced with competitors. Now, I routinely have to reset the app/clear the cache and go through various dances to get files to upl…

Not to “works on my machine” you, but I…genuinely do not have these problems. I’ve never heard it from my team either. So we could at the very least say it’s not a widespread global issue.

Even the percentage of nerds that would want IRC or XMPP bridges back would have to be vanishingly small. I’d be annoyed if Slack reimplemented such functionality because it no doubt slows down future development. Slack has a number of mechanics that do not carry across to IRC or XMPP, and they did when they killed the bridges. I’d be annoyed if new features were compromised to increase compatibility with this blatant nerd vanity project.

Re: Slack’s migration to a cellular architecture

#135

Post by skullone »

nostrebored wrote: post #119
skullone wrote: post #89

Earlier quoted context omitted.

It even pains me to see they're suffering from so many own goals. And it's unfortunately reflected in the poor experience using the Slack client. Not to mention the multiple deprecated bot/integration APIs with such bad feature parity between all the different ways to integrate your own tooling into Slack.

What do you mean? Slack is one of the most responsive and reliable tools I touch every day.

How slow are the rest of your tools? The Slack client probably performs worse today than it did a few years ago. It has the laggiest interface of any of my tools, you can watch your CPU spike to 60-80% just switching channels. Just do it right now, open up htop/top/atop/Activity Monitor - whatever you want, and just switch channels. Laugh as the Slack client wastes a universe's worth of time just... rendering a DOM with plain text. It is genuinely pathetic how bad the client is.

Re: Slack’s migration to a cellular architecture

#136

Post by dcgudeman »

muglug wrote: post #17
alberth wrote: post #3

Is Slack still written in Hack/PHP?

Yes — see my recent article https://slack.engineering/hakana-taking-hack-seriously/ We use a few languages to serve client requests, but by far the biggest codebase is written in Hack, which runs inside an interpreter called HHVM that’s also used at Facebook.

I noticed that the hack blog (https://hhvm.com/blog/) basically stopped posting updates since the end of 2022. As downstream users of hacklang development have you folks noticed a change in development pace or ambition within the hack development team?

Re: Slack’s migration to a cellular architecture

#137

Post by BoorishBears »

tbrownaw wrote: post #91
t0mas88 wrote: post #84

They got themselves into a mess here: > This turns out to have a lot of complexity lurking within. Slack does not share a common codebase or even runtime; services in the user-facing request path are written in Hack, Go, Java, and C++. This would necessitate a separate implementation in each language. This sounds crazy. I've seen several products where there is a core stack (e.g. Java) and then surrounding tools, ana…

"The right language for each job" was one of the heavy advertising points for microservices. Might still be too some extent, even.

The problem is most engineers don't understand the "job".

They see the job as a strictly technical problem looking for the best technical solution. They don't look up and see how that problem fits into the larger organization.

They think things like "I can make a microservice that encodes PDFs 10x faster by using Rust" and give an estimate based on that, never thinking about how we're going to need to hire 2 more Rust devs to keep that running, and we could have delivered twice as quickly if I had used our default Python stack and now our "10x faster" doesn't matter because that feature is old news.

Microservices are such an unfortunate concept because they attract the people least suited to use them: If your team can't handle a monolith, you shouldn't even be looking up what a microservice is.

Re: Slack’s migration to a cellular architecture

#138

Post by mlhpdx »

nostrebored wrote: post #123
skullone wrote: post #73

Earlier quoted context omitted.

Geo traffic distribution, multi regions/AZs with functionality to weight and drain traffic should be used in most SaaS services where a simple failure somewhere could cost users time and lose company money/goodwill. It's not terribly hard nor expensive.

Those are all much looser restrictions than routing traffic consistently to a cell

Route 53 latency based routing -> APIGW or ALB -> Lambda or Step Functions -> DDB Global Table.

No reserved capacity (pay for usage), so it works for boot strapping startups and provides superior resilience while being extremely simple to setup and involves almost zero maintenance or patching (even under the hug of death). I don’t understand settling for less (and taking longer and paying more for it).

Re: Slack’s migration to a cellular architecture

#139

Post by [deleted] »

ecshafer wrote: post #60
devmor wrote: post #28

Earlier quoted context omitted.

If your goal is to monitor your staff and gather metrics on their communication - Teams outdoes Slack and is incomparable. If your goal is to have a platform that enables your employees to communicate with as little friction as possible, I have yet to see anything capable of replacing Slack. Teams especially, is something I loathe using every day. Everything about the UI and UX gets in the way of what I’m trying to d…

I went from a company using teams to slack a few years ago. Truly night and day. I have such a visceral hatred for Teams, it actually surprises me how much I can dislike some software that is for messaging. From how it can't copy and paste in and out of chat, to the way it sets laptops on fire, or its horrible ui. I really truly hate that software. Please just use slack or god forbid set up an irc node or something.

[deleted]

Re: Slack’s migration to a cellular architecture

#140

Post by [deleted] »

fiddlerwoaroof wrote: post #127

The thing I don't understand about Slack is how the core functionality seems to have continuously degraded since I started using it in ~2015. When I started using it, its core message sending features basically didn't have the issues with delayed messages or failure to send that I had experienced with competitors. Now, I routinely have to reset the app/clear the cache and go through various dances to get files to upl…

[deleted]
Post reply on HN