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

171–180 of 265 posts

Re: Slack’s migration to a cellular architecture

#171

Post by hotnfresh »

Racing0461 wrote: post #125
hotnfresh wrote: post #92

Earlier quoted context omitted.

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

/s ?

No, that’s really how it is. They leave opportunities to save or make five-figure (and larger) amounts all the time, because it’s not worth the distraction from other activities. And also from straight-up mis-management, but a lot of the time they know exactly what they’re doing, and it’s on purpose, and it’s probably not a mistake.

Re: Slack’s migration to a cellular architecture

#172

Post by sitkack »

vinnymac wrote: post #122
jonathankoren wrote: post #109

Earlier quoted context omitted.

Somewhere, an engineering “leader” is going to point to this blog post and then say, “Well, that’s how Slack did it!” and promptly copy this overwrought system

I’m not sure if you’re being serious, but in any case; This will happen, as it always does, inevitably.

Warning statement becomes the howto guide.

Re: Slack’s migration to a cellular architecture

#173

Post by [deleted] »

endymi0n wrote: post #167
athoscouto wrote: post #35

Their siloing strategy, which I'll roughly refer as resolving a request from a single AZ, is a good way to keep operations and monitoring simple. A past team of mine managed services in a similar fashion. We had a couple (usually 2-4) single AZ clusters with a thin (Envoy) layer to balance traffic between clusters. We could detect incidents in a single cluster by comparing metrics across clusters. Mitigation was easy…

It took me some time to realize that Cloud Solution Architects are also just slightly more technical sales people in disguise whose only mission is upselling you onto more dependency. Same thing about their PR, every CxO these days says they need "multi-cloud", whatever that means and the costs are usually enormous, while complexity rises — with questionable benefit. I did the math for our own stack and after a setba…

[deleted]

Re: Slack’s migration to a cellular architecture

#174

Post by jmull »

memefrog wrote: post #157
fulladder wrote: post #142

Earlier quoted context omitted.

I haven't used Slack in a long time, but isn't this just the normal enshittification cycle that occurs with all Internet products? The founders got a nice exit several years back, I doubt they stuck around at Salesforce for long, so it's natural that the product would deteriorate over time. Slack IRC bridging in the 2014/2015 era was great. We had a lot of people who spent their whole workday in a terminal window and…

>isn't this just the normal enshittification cycle that occurs with all Internet products? No! Stop diluting this word.

This is the Cory Doctorow sense of the word, is it not?

(Or, now that I notice your username, maybe you’re making an ironic joke, since complaining about the misuse of the word enshitification is a meme now?)

Re: Slack’s migration to a cellular architecture

#175

Post by alberth »

dcgudeman wrote: post #136
muglug wrote: post #17

Earlier quoted context omitted.

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?

I too am super curious about this.

Plus, it seems telling that Threads was developed in Python - not Hack.

(I’m aware IG is Python & it’s the same team)

Re: Slack’s migration to a cellular architecture

#176

Post by [deleted] »

messe wrote: post #49
ThePhysicist wrote: post #41

So they run everything in AWS USE1? That doesn't seem very redundant, but then I guess if the whole of USE1 goes down Slack won't be the only service that will be affected.

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.

[deleted]

Re: Slack’s migration to a cellular architecture

#177

Post by AugustoCAS »

athoscouto wrote: post #35

Their siloing strategy, which I'll roughly refer as resolving a request from a single AZ, is a good way to keep operations and monitoring simple. A past team of mine managed services in a similar fashion. We had a couple (usually 2-4) single AZ clusters with a thin (Envoy) layer to balance traffic between clusters. We could detect incidents in a single cluster by comparing metrics across clusters. Mitigation was easy…

I assume you were using AWS? I know some of the AZ of other cloud providers (Azure? Oracle? Google?) are not fully siloed. They might have independent power and networking, but be in the same physical location.

I'm mentioning this for other people to be aware as one can easily make the assumption that an AZ is the same concept on all clouds, which is not true and painful to realise.

Re: Slack’s migration to a cellular architecture

#178

Post by ignoramous »

gumballindie wrote: post #165
ignoramous wrote: post #98

Earlier quoted context omitted.

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 sen…

Yeah that's what microservices were meant to achieve. Suppose the market is staturated with "microservices", so a new term was needed.

Microservices is one reason you need cells. If you haven't, the second talk I linked to might interest you.

Re: Slack’s migration to a cellular architecture

#179

Post by catchnear4321 »

lordofnorn wrote: post #124
athoscouto wrote: post #54

Earlier quoted context omitted.

We did. But the persisted data didn't live inside those ephemeral compute clusters though.

Yeah, keep stateful stuff and stateless stuff separate; separate clusters, network spaces, cloud accounts, likely a mix of all that. Clearly define boundaries and acceptable behavior within boundaries. Setup up telemetry and observability to monitor for threshold violations. Simple. Right?

i mean you could also just spin up a reeeeeally big compute node and just do it all there.

fewer things to monitor. fewer things that can fail.

just log in from time to time to update packages.

see, cloud doesn’t have to be complex.

Re: Slack’s migration to a cellular architecture

#180

Post by rubyss »

alberth wrote: post #175
dcgudeman wrote: post #136

Earlier quoted context omitted.

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?

I too am super curious about this. Plus, it seems telling that Threads was developed in Python - not Hack. (I’m aware IG is Python & it’s the same team)

You answered yourself there, Hack is still very widely used inside meta, just less so in IG.
Post reply on HN