[rewmie]

I understand your comment is tongue-in-cheek, but there's indeed a luddite-like movement that hides itself behind microservices cliches but under the surface they deny the very reason of existence of distributed systems in particular and the system design field in general. To them, the work of putting together a web app is a solved problem consisting of a single process doing everything under the sun, and the only acceptable hint of a software architecture is breaking the app in modules.

[mattmanser]

With a lot of systems, the business system design is complex enough in the first place that if you add a distributed system design to it as well you just end up with a colossal mess. And worse still you can't even see a lot of the complexity easily as it's hidden in how the distributed system is configured.

A normal system design, derisively called a monolith by some, is much clearer and explicit. It's less code. It's more reliable, less brittle. It comes with less footguns.

Distributed systems are not a better technology, like weaving looms were, they are simply an alternative design that is presently overused by incompetent software architects.

So it's not a luddite movement, it's an anti-complexity-for-the-sake-of-complexity movement. Try to not call us luddites again. Personally I view people that advocate for such designs by default as incompetent and that they should never be let anywhere near system design as they clearly don't understand the costs.

Simpler is almost always better, and there needs to be extremely good reasons to switch to incredibly costly distributed design patterns.

[rewmie]

> With a lot of systems, the business system design is complex enough in the first place that if you add a distributed system design to it as well you just end up with a colossal mess.

The goals of system design are a) a system actually works, b) the system is not a colossal mess.

In a similar manner, the challenge of any engineering field is to not allow things to become overly complex.

> A normal system design, derisively called a monolith by some, is much clearer and explicit. It's less code. It's more reliable, less brittle. It comes with less footguns.

You're presuming that your average monolith is the result of a refined design. It is not. The main gripe that the luddite-like movement directs at systems design in general is basically the reality that software projects actually need planning and a working software architecture, where in monoliths they can just pile stuff in there without thought or criteria.

[rcxdude]

Doesn't seem like you're actually disagreeing then, if systems design can apply just as well to a 'monolith' and it's often the better design.

[rewmie]

> Doesn't seem like you're actually disagreeing then, if systems design can apply just as well to a 'monolith' and it's often the better design.

"Can" and "do" are two different words.

"Monolith" is often a cop out to hide amorphous big-ball-of-mud projects. In fact, the luddite-like movement's aversion to system design is rooted in the fact that it's not necessary, and their irrational aversion to microservices and distributed systems and systems design lies in the fact that, unlike monoliths, they are far less tolerant of hacking together big balls of mud and demand instead some degree of discipline to design a system and comply with the system design.

[edwardsdl]

> unlike monoliths, they are far less tolerant of hacking together big balls of mud and demand instead some degree of discipline to design a system and comply with the system design.

A demand that is often poorly met, leaving one with a distributed ball of mud that is more difficult to reason about and refactor.