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

21–30 of 265 posts

Re: Slack’s migration to a cellular architecture

#21

Post by koolba »

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 really like the writing style in that article:

> PHP makes it really easy to make a dynamically-rendered website. PHP also makes it really easy to create an utterly insecure dynamically-rendered website.

Re: Slack’s migration to a cellular architecture

#22

Post by skullone »

colmmacc wrote: post #8
skullone wrote: post #2

So they used a feature built into a load balancer to gracefully drain traffic from specific availability zones? Odd that a feature found in load balancers from the last 25 years is a blog post worthy thing.

Close but I don't think it's quite 25 years! I added graceful draining to Apache httpd's mod_proxy and mod_proxy_balancer either in 2003 or 2004, and at the time I'm nearly certain it was the first software load balancer to have the feature, and it wasn't available on the hardware load balancers of the time that I had access to ... though I later learned that at least BigIP load balancers had the feature. At the time…

I migrated some old BigIP load balancers over to Apache in 2004ish, and extended some of mod_proxy to do some "unholy" things at the time. We also did a lot of direct server return stuff when no load balancer you could buy could handle the amount of traffic statefully. Man, how times have changed, and lesson forgotten.

Re: Slack’s migration to a cellular architecture

#23

Post by robertlagrant »

heywhatupboys wrote: post #10

Is Slack dead? unironically. Does it have a future? With Teams, etc. coming out, it seems most companies do not want to go the Slack route

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

Re: Slack’s migration to a cellular architecture

#24

Post by rs_rs_rs_rs_rs »

skullone wrote: post #14
aftbit wrote: post #9

Earlier quoted context omitted.

from the article: >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++.

Man what a mess. Meanwhile, everyone else can extend a library used by their common services in a common language trivially.

Let me guess, they should rewrite everything in Javascript?

Re: Slack’s migration to a cellular architecture

#25

Post by wilg »

robertlagrant wrote: post #20
skullone wrote: post #18

Earlier quoted context omitted.

It may be shallow, but architecting for this is not really "advanced, FAANG-only accessible methodology". I'm surprised their services have been as "reliable" as they have been considering such trivial stuff is just now being employed in their architecture.

> architecting for this is not really "advanced, FAANG-only accessible methodology" Sorry - where are you quoting this claim from?

The S in FAANG is for Slack.

Re: Slack’s migration to a cellular architecture

#26

Post by dexwiz »

aftbit wrote: post #11

How can such an architecture function with respect to user data? If the DB instance primary handling your shard is in AZ-1 and AZ-1 gets drained, how can your writes continue to be serviced?

Multiple tiers of redundancy. There is usually redundancy within the AZ and then a following copy in another AZ. Usually at least four copies exist for a tenant.

Re: Slack’s migration to a cellular architecture

#27

Post by skullone »

robertlagrant wrote: post #20
skullone wrote: post #18

Earlier quoted context omitted.

It may be shallow, but architecting for this is not really "advanced, FAANG-only accessible methodology". I'm surprised their services have been as "reliable" as they have been considering such trivial stuff is just now being employed in their architecture.

> architecting for this is not really "advanced, FAANG-only accessible methodology" Sorry - where are you quoting this claim from?

My own words, but this is fairly trivial in the context of these massive companies with presumably PHDs working on their architecture.

Re: Slack’s migration to a cellular architecture

#28

Post by devmor »

heywhatupboys wrote: post #10

Is Slack dead? unironically. Does it have a future? With Teams, etc. coming out, it seems most companies do not want to go the Slack route

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 do, rather than assisting in or even enabling it. It’s like it doesn’t want me to communicate - it wants me to react and offer as little useful information as possible.

Re: Slack’s migration to a cellular architecture

#29

Post by wasmitnetzen »

heywhatupboys wrote: post #10

Is Slack dead? unironically. Does it have a future? With Teams, etc. coming out, it seems most companies do not want to go the Slack route

My employer buys no Microsoft SaaS service, since we're mostly on Google services, so a stand-alone like Slack works quite well. And nobody uses Google Chat.

And besides that, the UX of Teams is miles behind Slack.

Re: Slack’s migration to a cellular architecture

#30

Post by djbusby »

colmmacc wrote: post #8
skullone wrote: post #2

So they used a feature built into a load balancer to gracefully drain traffic from specific availability zones? Odd that a feature found in load balancers from the last 25 years is a blog post worthy thing.

Close but I don't think it's quite 25 years! I added graceful draining to Apache httpd's mod_proxy and mod_proxy_balancer either in 2003 or 2004, and at the time I'm nearly certain it was the first software load balancer to have the feature, and it wasn't available on the hardware load balancers of the time that I had access to ... though I later learned that at least BigIP load balancers had the feature. At the time…

Microsoft bought Convoy in 1998[0]. Then incorporated it into NT4sp6a and Win2k as NLB/WLBS. One of its features was to gracefully remove a server from the cluster after all connections were closed - draining. But, cluster not the same as an LB.

[0] https://news.microsoft.com/1998/08/24/microsoft-corp-acquire...

Post reply on HN