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

91–100 of 265 posts

Re: Slack’s migration to a cellular architecture

#91

Post by tbrownaw »

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.

Re: Slack’s migration to a cellular architecture

#92

Post by hotnfresh »

Racing0461 wrote: post #77
packetlost wrote: post #66

Earlier quoted context omitted.

The company I work for has a "Hours wasted because Teams sucks" page that gets updated at least weekly. Eventually the list will grow so large that we could probably attach a 5-figure dollar amount to it, if it hasn't already.

Depending on the size of the company, that value is absolutely insignificant.

Bigcos with robust sales truly can’t afford the organizational-attentional cost of walking across the street to pick up a $10,000 coin.

Re: Slack’s migration to a cellular architecture

#93

Post by skullone »

mynameisvlad wrote: post #70
messe wrote: post #49

Earlier quoted context omitted.

AWS also uses Slack internally, so add that to the list of shit that can hit the fan if us-east-1/IAD goes down.

Don’t they also use Chime? It wouldn’t be a single point of failure.

Lots of teams use Slack as well. Oddly enough, I didn't mind Chime as an end-user, but 6 years ago their API features were somewhat lacking.

Re: Slack’s migration to a cellular architecture

#94

Post by fooster »

zo1 wrote: post #62
robertlagrant wrote: post #23

Earlier quoted context omitted.

Teams is doing well because it's often an IT department's simplest choice, but I don't find it's great for users.

Why would I choose Slack for my employees when Teams integrates so nicely with everything else in the "stack". Teams is leaps and bounds ahead already, and Slack really lost the boat many years ago. Speaking of which, I'm going now to buy more Microsoft shares.

You are choosing teams. What are your employees choosing? In my experience teams is a terrible mess and a company using it would exclude me from working for the company because they very likely don’t give a crap about the day to day experience of the employee.

Re: Slack’s migration to a cellular architecture

#95

Post by Terretta »

jldugger wrote: post #85
bushbaba wrote: post #48

Earlier quoted context omitted.

The downside of single AZ clusters is capacity. If you have a need to drastically scale up the compute might not be available in a single AZ.

Indeed, this is the main problem I run into. We have to scale up capacity before the traffic can be redirected or you basically double the scope of the outage briefly. Which involves multiple layers of capacity bringup -- ASG brings up new nodes, then HPA brings up the new pods.

If you have enough scale that could be a problem, cookie cutter more smaller AZs so any one outage is less of numerator of capacity over the denominator of scale.

Worth noting that requiring teams to use 3 AZs is a good idea because you get "n" shaped patterns instead of mirror shaped patterns, which have very different characteristics for resilience and continuity.

Re: Slack’s migration to a cellular architecture

#96

Post by shepherdjerred »

fotta wrote: post #72
messe wrote: post #49

Earlier quoted context omitted.

AWS also uses Slack internally, so add that to the list of shit that can hit the fan if us-east-1/IAD goes down.

Huh, I’m surprised they’re not all in on Chime.

It was all on Chime until the Pandemic. Then they moved to Slack.

Re: Slack’s migration to a cellular architecture

#97

Post by Terretta »

purpleturtle22 wrote: post #79

Can someone ELI5 the difference between using AWS availability zone affinity and then simply dropping the downed AZ at the top most routing point? Wouldn't that be the same thing, with the obvious caveat you are t using the routing technology Slack is using (We don't - We use vanilla AWS offerings)

You're doing it right.

Re: Slack’s migration to a cellular architecture

#98

Post by ignoramous »

gumballindie wrote: post #88

"cellular architecture" What? Does amazon need to push for new sales points or are they simply making up architectures now?

ex-AWS here

May be marketing but it is an architecture born out of Amazon's (and AWS's) use of AWS:

- Reliable scalability: How Amazon.com scales in the cloud, https://www.youtube.com/watch?v=QeW9wCB36ck&t=993 (2022)

- How AWS minimizes the blast radius of failures, https://youtu.be/swQbA4zub20 (2018)

For massive enterprise products like Slack that need close to 100% uptime across all their services, cells make sense.

Re: Slack’s migration to a cellular architecture

#99

Post by pavlov »

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 only way you get Hack on that list of languages is that they had a policy of letting lead engineers starting a project to choose the language at will, and they hired enough lead engineers who previously worked at FB/Meta.
Post reply on HN