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

151–160 of 265 posts

Re: Slack’s migration to a cellular architecture

#151

Post by ec109685 »

jldugger wrote: post #85
bushbaba wrote: post #48

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.

Indeed, this is the main problem I run into. We have to scale up capacity before the traffic can be redirected or you basically double the scope of the outage briefly. Which involves multiple layers of capacity bringup -- ASG brings up new nodes, then HPA brings up the new pods.

If there’s uncorrelated load you can also run on your hosts, then you can share their spare capacity, with the hope they don’t spike at same time.

AWS does that with their lambda arch to reduce waste.

Re: Slack’s migration to a cellular architecture

#152

Post by ec109685 »

purpleturtle22 wrote: post #79

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)

Isn’t that exactly what they are doing? Keeping requests within an AZ and using global DNS at the first hop into AZ.

Re: Slack’s migration to a cellular architecture

#153

Post by grokys »

zo1 wrote: post #62
robertlagrant wrote: post #23

Earlier 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.

Maybe because you value your employees being able to copy an image from your chat platform?

(Teams still can't copy images, instead you get a massive base64 block of text iirc)

Re: Slack’s migration to a cellular architecture

#154

Post by ec109685 »

purpleturtle22 wrote: post #79

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)

Isn’t that exactly what they are doing? Keeping requests within an AZ and instead of using DNS at the first hop into AZ, they use envoy to control traffic shaping and making that initial decision if traffic needs to be routed away.

Re: Slack’s migration to a cellular architecture

#155

Post by ec109685 »

fiddlerwoaroof wrote: post #127

The thing I don't understand about Slack is how the core functionality seems to have continuously degraded since I started using it in ~2015. When I started using it, its core message sending features basically didn't have the issues with delayed messages or failure to send that I had experienced with competitors. Now, I routinely have to reset the app/clear the cache and go through various dances to get files to upl…

They support much much larger workspaces now, and support team to team shared channels, so the problem space is much more complex than 2015.

Not saying they shouldn’t fix their reliability. Every other week it seems like they have an outage with this or that.

The Flickr style commit to production multiple times per day seems to have its limits. Perhaps longer canary and slower rollouts would help.

Re: Slack’s migration to a cellular architecture

#156

Post by random3 »

This brings back memories - we speced an open distributed operating system called Metal Cell and built an implementation called Cell-OS. It was inspired by the "Datacenter as a computer" paper, but built with open-source tech.

We had it running accross bare metal, AWS and Azure and it one of the key aspects was that it handled persistent workloads for big data, including distributed databases.

Kubernetes was just getting built when we started and was supposed to be a Mesos scheduler initially.

I assumed Kubernetes would get all the pieces in and make things easier, but I still miss the whole paradigm we had almost 10 years ago.

This is retro now :)

https://github.com/cell-os/metal-cell

https://github.com/cell-os/cell-os

Re: Slack’s migration to a cellular architecture

#157

Post by memefrog »

fulladder wrote: post #142
fiddlerwoaroof wrote: post #127

The thing I don't understand about Slack is how the core functionality seems to have continuously degraded since I started using it in ~2015. When I started using it, its core message sending features basically didn't have the issues with delayed messages or failure to send that I had experienced with competitors. Now, I routinely have to reset the app/clear the cache and go through various dances to get files to upl…

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.

Re: Slack’s migration to a cellular architecture

#158

Post by memefrog »

"For example slack is an incredibly successful product. But it seems like every week I encounter a new bug that makes it completely unusable for me, from taking seconds per character when typing to being completely unable to render messages. (Discord on the other hand has always been reliable and snappy despite, judging by my highly scientific googling, having 1/3rd as many employees. So it's not like chat apps are just intrinsically hard.) And yet slack's technical advice is popular and if I ran across it without having experienced the results myself it would probably seem compelling."

https://www.scattered-thoughts.net/writing/on-bad-advice/

Re: Slack’s migration to a cellular architecture

#159

Post by lopkeny12ko »

nostrebored wrote: post #119
skullone wrote: post #89

Earlier quoted context omitted.

It even pains me to see they're suffering from so many own goals. And it's unfortunately reflected in the poor experience using the Slack client. Not to mention the multiple deprecated bot/integration APIs with such bad feature parity between all the different ways to integrate your own tooling into Slack.

What do you mean? Slack is one of the most responsive and reliable tools I touch every day.

I hope this is satire. Slack is one of the slowest work tools I've ever used. Every interaction and click visibly lags.

It's a sad state of the world that almost every application now is written in Javascript and deployed with Electron, and massive memory usage and slow UIs have become accepted as the norm.

Try any IRC client and tell me, with a straight face, that Slack is just as responsive.

Post reply on HN