Live data from Hacker News

Slack’s migration to a cellular architecture

slack.engineering

241–250 of 265 posts

Re: Slack’s migration to a cellular architecture

#241
post #189

Earlier quoted context omitted.

until you get "hardware failure" note from cloud provider. Or the person updating packages makes a typo and messes up a system. sure, use "pet" computers for experiments and dev.. but having produluction be a "cattle" makes your life so much less stressful.

I think everyone internalizes pets vs cattle a little differently, but I think people often don't realize that if you have cattle, then you now have a cattle ranch. I.e. you often create a new concept to manage your cattle, and you often run that like it's a pet. E.g. you want to think about your machines/containers like cattle, so you put them into a kubernetes cluster, which has become your new pet. If all your inf…

In cloud environments, it's pretty standard practice to automate cluster provisioning. If your cluster are pets, you're not doing it quite right.

> If all your infra fits on one machine, it's way easier to have that as your pet

What stops you from automating the provisioning of that?

These are two orthogonal issues. Clusters are used to manage many machines. If you need only one machine, you don't need a cluster. Either way, the provisioning of single nodes and clusters should be automated. Whether you have pets or cattle is not related to how many machines you have.

Re: Slack’s migration to a cellular architecture

#243

Earlier quoted context omitted.

Man what a mess. Meanwhile, everyone else can extend a library used by their common services in a common language trivially.

Let me guess, they should rewrite everything in Javascript?

[flagged]

Re: Slack’s migration to a cellular architecture

#244

"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 j…

I really wouldn't judge the quality of some company's technical advice based on one person's experience with their UI. For almost any consumer software that gets mentioned here, you will find some people who love it and lots of others with gripes. And for e.g. Slack might have bad product/UI people but very good infra people. Better to look at TFA and judge it on its merits.

It isn't one person's experience with the UI. It is everyone's. If you don't think Slack is slow then you have forgotten what "slow" means. It is a chat program. It is incredibly simple. It is not doing anything complicated. We have gigabit internet, CPUs with multi-GHz clocks and high IPC rates, NVMe 4 SSDs that load data from disk almost instantly. It should open in milliseconds, not several seconds. That it ever takes a noticeable amount of time to do anything reveals deep flaws in Slack's engineering culture, because it shows they just don't care about performance at all.

If they had "good infra people" then their program wouldn't sit and spin for seconds, ever.

Re: Slack’s migration to a cellular architecture

#245

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…

I think there's this general problem with cloud deployments I'm seeing happen more and more:

People building this huge Multi AZ, Hyper Redundant, Multi-National, infinitly scaling Cloud Solution for something that requires a single VM and a Database.

Most Companies just don't need that level of scale and would be better off building something smaller and when you actually do scale you rewrite it with the profits made from the smaller solutions.

Of course there are many companies that do require something large but you should seriously consider if something smaller will do first.

I think solutions like a 100% cloudflare workers based backend can sidestep this a little but usually, that's not possibly or even the right thing in every situation.

Re: Slack’s migration to a cellular architecture

#247

Delighted to be part of this conversation on cell-based architecture. As the author of the cell-based reference architecture https://github.com/wso2/reference-architecture/blob/master/r... , I'm here to share insights on this exciting approach. Cell-based architecture introduces modular 'cells' into software systems, each with distinct APIs. This design fosters loose coupling and scalability – key for today's dynamic…

This seems written by AI? And as such it comes across as not genuine

No, it is not written by AI :). You can look at the Reference Implementations section of the spec to find who is using the spec https://github.com/wso2/reference-architecture/blob/master/r...

Re: Slack’s migration to a cellular architecture

#248

Delighted to be part of this conversation on cell-based architecture. As the author of the cell-based reference architecture https://github.com/wso2/reference-architecture/blob/master/r... , I'm here to share insights on this exciting approach. Cell-based architecture introduces modular 'cells' into software systems, each with distinct APIs. This design fosters loose coupling and scalability – key for today's dynamic…

I'm familiar with the cell architecture promoted by the WSO2 papers (and other resources). I like it and I've used it in client projects. However, this article uses "cell" in a completely different way. It is not the cell-based architecture that you are promoting here without reading the article.

In the CBA paper, a 'Cell' is an architecture construct you can use in the design stage and take through the development and then to the deployment. So, it addresses both application and deployment architecture. Each cell has a boundary, a cell gateway, and components inside the cell.

Re: Slack’s migration to a cellular architecture

#249
post #232

Earlier quoted context omitted.

This seems written by AI? And as such it comes across as not genuine

It's from WSO2, a company selling enterprise middleware. Of course, the paper would read like something you bring to a sales meeting, not a tech talk.

Interesting feedback, I'll see how I can address this perception of a 'sales pitch' during the next revision. The intention was to define a vendor and technology-neutral reference architecture to the community.
Post reply on HN