Cellular architecture? They've just rediscovered the art of redundancy systems
[deleted]
Slack’s migration to a cellular architecture
71–80 of 265 posts
Re: Slack’s migration to a cellular architecture
#72So 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.
Huh, I’m surprised they’re not all in on Chime.
Re: Slack’s migration to a cellular architecture
#73Earlier 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.
Half the complaints on here on architecture posts are 'you don't need this kind of stuff unless you're at FAANG scale'. Now we have a write up of something that's accessible to businesses at non-FAAANG scale, and we have the new complaint, that this kind of stuff isn't worthy of FAANG-scale architecture.
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.
Re: Slack’s migration to a cellular architecture
#74Earlier 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.
> Why would I choose Slack for my employees when Teams integrates so nicely with everything else in the "stack".
Does it really though? In my experience teams has a buggy integration with other things in the stack.
And Teams itself ia massively buggy and a resource hog for the whole time I've used it.
Re: Slack’s migration to a cellular architecture
#75Earlier 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.
I don't think I have ever heard someone favorably compare teams chat with slack before. Even when I worked at a company that used teams for video calls and MS for email and calendar and documents and what not, everyone used slack for chat.
I don't think anyone was sad that slack didn't integrate with the other MS services "stack".
Re: Slack’s migration to a cellular architecture
#76"A single Slack API request from a user (for example, loading messages in a channel) may fan out into hundreds of RPCs to service backends, each of which must complete to return a correct response to the user." Not being a dick here but is this not a fairly obvious flaw? I mean why not keep a structured "message log" of all channels of all time ? For every write the system updates the message log. I am guessing and m…
XMMP was extensible to support all this in the early 2000s. Slack reinvented simple services in the most obtuse way. I have to use Slack and I sideline quarterback all the ways things could have been better every day.
Re: Slack’s migration to a cellular architecture
#77Earlier 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.
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.
Re: Slack’s migration to a cellular architecture
#78So 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.
the "whole" of USE1 very rarely goes down [0], because unlike other cloud providers, Amazon's availability zones are actually independent and decoupled, and if you're running on EC2 in a zonal way it's highly unlikely an outage will affect multiple zones. [0] There are of course exceptions that come once every few years, but most instances people can think of in terms of widespread outages is one specific service goi…
Am I missing something about us-east-1 reliability ?
https://www.google.com/search?q=us-east-1+reliability https://www.google.com/search?q=us-east-1+outage
Re: Slack’s migration to a cellular architecture
#79Can 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)
Re: Slack’s migration to a cellular architecture
#80Earlier quoted context omitted.
> 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.
[deleted]