101–110 of 265 posts
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…
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.
"cellular architecture" What? Does amazon need to push for new sales points or are they simply making up architectures now?
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.
Hi Matt Thanks for Psalm! Curious, if Slack was built today from ground up - what tech stack do you think should/would be used?
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 question (compile times for hundreds of devs would instantly sap productivity). PHP, Ruby, Node and Python are too slow — for the moment at least.
So it would be either Hack or Go. I don’t know enough about JVM languages to know whether they would be a good fit.
Cellular architecture? They've just rediscovered the art of redundancy systems
Here's AWS's 2019 guide for financial services in AWS, where the isolated stack concept is referenced under parallel resiliency section and called "shared nothing":
https://d1.awsstatic.com/Financial%20Services/Resilient%20Ap...
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…
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.
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)
They decided to use every routing tool available at least once in their setup, so they can't do this. But there is no explanation in the blog about why they use so many platforms and so many routing tools. Sounds to me like they got themselves into a mess and decided to continue on that path.
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.
Even though each cluster was single AZ the whole system wasn't, so we weren't bound by the capacity of a single AZ. Most of the situations where we needed to drastically scale up were known ahead of time as well (e.g. campaign from customer), and we would preallocate instances or even more clusters. I may be forcing my memory, but if I'm not mistaken, our auto scaling was setup in a way that the system could handle s…
That said, it's a trade off between efficiency and load spike tolerance. I trust that the trade off is made with informed decision.