Cellular architecture? They've just rediscovered the art of redundancy systems
But if they call it cellular architecture, it sounds much more exotic than a shared-nothing active/active service!
Slack’s migration to a cellular architecture
31–40 of 265 posts
Re: Slack’s migration to a cellular architecture
#32Re: Slack’s migration to a cellular architecture
#33Earlier quoted context omitted.
That seems like a shallow dismissal. In a distributed system, making sure that sub requests are handled across distributed nodes within the local AZ, and correctly draining traffic from AZs with partial component service outages, is not as trivial as 'using a feature built in to a load balancer'.
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.
Re: Slack’s migration to a cellular architecture
#34Cellular architecture? They've just rediscovered the art of redundancy systems
It's a common pattern in tech. Everything old will be new again.
Re: Slack’s migration to a cellular architecture
#35Their 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, we could drain a cluster in under a minute, redirecting traffic to the other ones. Most traffic was intra AZ, so it was fast and there was no cross-AZ networking fees.
The downside is that most services were running in several clusters, so there was redundancy in compute, caches, etc.
When we talked to people outside the company, e.g. solution architects from our cloud provider, they would be surprised at our architecture and immediately suggest multi-region clusters. I would joke that our single AZ clusters were a feature, not a bug.
Nice to see other folks having success with a similar architecture!
Re: Slack’s migration to a cellular architecture
#36So 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.
[deleted]
Re: Slack’s migration to a cellular architecture
#37I appreciate the clear explanation of the problem and the solution, which (as is so often the case) seems fairly simple or obvious in retrospect.
Semi-related tangent: sometime around mid-2016, I came across a tool that helped visualize requests in near real-time, and showed what it "looks" like (ie, flow slows to trickle in service A during draining, while it ramps up in service B)... there was a really compelling demo, but I never bookmarked it and can't seem to find it. IIRC its name was a single word. Maybe someone reading this will know what I'm talking about... ?
Re: Slack’s migration to a cellular architecture
#38Is 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.
Not even GitHub? I believe that's the only MSFT service we have at my <40 people fintech dayjob
Re: Slack’s migration to a cellular architecture
#39Cellular architecture? They've just rediscovered the art of redundancy systems
[deleted]
Re: Slack’s migration to a cellular architecture
#40[flagged]
[deleted]