Scalability is always such a spur of the moment implementation at a startup. This seems to be cruft left over from that startup phase. Would a scalability audit have caught it? Tough to say as Slack came from that build fast and break things era.
A terrible, horrible, no-good, very bad day at Slack
141–150 of 282 posts
Re: A terrible, horrible, no-good, very bad day at Slack
#142This is one of the biggest arguments I see for serverless (AWS Lambda + DynamoDB) or at least managed PaaS systems (Google App Engine, Heroku with RDS or CloudSQL). These systems may seem to cost more for some workload curves (or might even be cheaper for your curve), but the difference is worth it because you're paying for specialized 24/7 dev-ops teams whose only job is to keep these systems running smoothly, and b…
Replace "serverless" with "managed service" and I agree. But serverless doesn't give you any magical reliability improvement over anything else, because your NFRs dictate the implementation that will produce the most reliable product.
The design of a wooden table will inform what tools will produce the best version of that table. It may not be the newest power tool; it may end up being chisels, hand planes, winding sticks, a kerf saw and a mallet. If somebody maintains your tools for you they'll stay reliably sharp, but that doesn't lead to a good table unless you pick the right tools and use them the right way.
Re: A terrible, horrible, no-good, very bad day at Slack
#143Earlier quoted context omitted.
I work for a PaaS. - The ideal fit for any hosting PaaS is a company who has a large hosting and infra footprint but for whom the technology is _not_ the core competency of the business. Slack is very much better off running their own systems with their own people. - As someone who deals with customers every day I can tell you that yes - we know our platform specifically and how the internet works generally better th…
>>"but we do not know _your application_ at all." You're missing the point. A PaaS, or serverless service doesn't need to know your application. That's the whole point. They're just API calls, and they need to succeed with consistently low latency.
You're telling someone who works for a PaaS company what a PaaS does and doesn't do. I think maybe they know.
More broadly, almost any application these days is "just API calls". The issue is which API calls, how many, with what frequency and where. That essentially is the application, and a PaaS employee doesn't magically know that stuff instinctively.
Re: A terrible, horrible, no-good, very bad day at Slack
#144Earlier quoted context omitted.
So this is where 12factor comes in - unless the application is operating at lower than layer 7 (and with some of the newer offerings even layer 3) there’s not much technology centric stuff going on. Everything Slack is doing is happening at the HTTP / gRPC / Websocket level, and it’s hard to make the case for self managed hosting. The idea of requests going to an application server on a TCP or HTTP connection with th…
If I had To guess, I’d say that Slack’s infrastructure footprint is probably as big if not bigger than any popular PaaS.
Slack had 12m DAU at the end of last year.
Re: A terrible, horrible, no-good, very bad day at Slack
#145Re: A terrible, horrible, no-good, very bad day at Slack
#146Earlier quoted context omitted.
The specialized 24/7 devops team (if it's there) also has a few thousand other customers instead of being there just for you. They might have other priorities at any given moment. It's not like AWS or GCP are renowned for the quality of their customer service.
AWS is pretty good whenever we've needed them. Google? Probably not.
I launched a large AAA game backed by a hybrid (GCE+Physical) infrastructure and I would swear by their support.
Yes, we paid for enterprise support, but it's especially good. They even contributed code to third-party open source projects to solve one of our bugs.
I hear often about google's support being terrible, but the enterprise support on google cloud is definitely an exception.
F.D: Aside from giving a talk at google stockholm once, I am not affiliated in any way.
Re: A terrible, horrible, no-good, very bad day at Slack
#147After I used Discord in different contexts for months now (and Slack for years), I can't understand why someone willingly chooses Slack. It's the Atlassian of chat tools. Horrible performance and bad usabillity.
[deleted]
Re: A terrible, horrible, no-good, very bad day at Slack
#148Re: A terrible, horrible, no-good, very bad day at Slack
#149Not being involved in this kind of scaled-up devops kind of stuff, my read of this article was "HAProxy sounds awful"... but they noted in the article
1) Migrating to better software, and 2) Newer versions of HAProxy are also better software.
But yeah, the first half where they're discussing "we don't do X, Y, or Z clean, idempotent way of doing config because the HAProxy doesn't perform right if you do it that way." sounded painfully familiar for a bunch of awful tools that I've used.
Re: A terrible, horrible, no-good, very bad day at Slack
#150Earlier quoted context omitted.
I'm not saying Discord is perfect or "always up", it's just that their client UI is better structured and more responsive in most cases. I am on multiple OSS Discord servers with thousands of users, and it works just fine most of the time. I am on multiple Slack servers with just 10-20 users and it is unbearably slow.
What are some open source discord servers you are a part of? I would like to know about some open source communities if you do not mind.
I'm on the React and Rust servers.