StabbyCutyou

Thanks! In terms of backend engineering, I'd say one of the trickiest things is always depending deeply on a third party service or provider to be the backbone of the value you add.

That's a pretty high level answer, but in general that's the most difficult to wrangle with over time, in my opinion.

To give a more concrete answer, every slack instance and the way people configure it can be a little different, and in some cases we found it tricky to find the right consistent location to pull information like display names from.

In terms of what is unexpectedly easy, Slack themselves been great at giving us feedback and advice for building on their platform!

Yes! Right now we have a PD integration that will allow us to receive your alerts, and once you bind them to an Allma Incident, manage the alerts for you as well!

Hey folks! I'm Sean, the CTO of Allma.

Would love to chat about the product if folks have any questions!

So, specifically in the context of a distributed queue (which, if we're talking about using MS arch + queueing due to scale concerns, you really need some kind of distribution to the message queue imo), these things get a lot harder.

Just because TCP provides resilience doesn't mean that you're perfectly defended against all kinds of issues here.

I'm mostly talking about things in the category of bugs in the software layer using TCP (the drivers, the consumers/publishers, race conditions, batching messages, not receiving ACKs, etc). There are a lot of little things that can go wrong.

In terms of partitions, look up a series by a guy named Aphyr called "Jepsen". It goes over the CAP theorem as it applies to distributed datastores and queues. His examples and tests will demonstrate the concepts behind partitioning better than I can explain over a HN comment :)

And yes, these types of failures are implicit everywhere - but every additional layer you add, every hop in the chain, every interaction added to the request flow increases the surface area for problems. Especially once you push high scale with hundreds of nodes, become nic or cpu bound, etc etc.

There is a lot to unpack here, and it's not as simple as it seems on the face of it.

This is more of the intended audience (earlier startups or smaller groups of devs), but I could have done a better job spelling that out.

The accuracy of this statement is as depressing as it is apt.

Thanks for adding some historical context for me!

I didn't discuss queues because queues aren't intrinsically a part of a MS architecture.

You certainly can do it that way, and there are lots of benefits, but queues (and if you're doing this at scale, distributed queues) are an entirely distinct subject matter that I chose not to touch on for this.

Also, things can still get lost with queues. Network failures, partitions, bugs in your own publishers and consumers... nothing is fool-proof, and it takes a lot of work to reduce that loss rate to 0.

Hello all you nice folks on HN. Original author of the article here. A few things I'd like to add, since this is essentially what feedback I get every time this has made the rounds:

1. I don't think microservices are bad, or that they don't work. Quite the contrary. My argument is simply that there is a lot of additional complexity in using this approach to your architecture, and to consider if you're able to handle that before diving in.

2. This was adapted from a lightning talk I gave almost 2 years ago, and is almost by-design light on hard details or deep dives. It was meant to just introduce the problems by talking about fallacies (which many think are strawmen, but they're arguments that i've heard from people in my own discussions on the subject).

3. Even if you disagree with my points, I appreciate folks taking the time to read and provide feedback.

Thanks!

Hi, original author here!

Quickly, on the "elementary" nature of the post, this was adapted from a lightning talk I gave, and so it was sort of designed to be a very quick introduction into the problem space.

Also this was meant to be (and this is my own fault for maybe not more carefully spelling this out) aimed at people just starting out with a new project or endeavor, as a warning that "just sprinkling some microservices on it" is not a magical panacea for scalability or good software design.

Thanks for taking the time to read and comment!

Elegant, simple, and idiomatic.

The perfect solution for Go.

This is definitely one of the main takeaways that I wanted to get across.

Well said, thanks!

I do wish I had titled it better, as most people have (rightfully) dinged me on this one ;)