Live data from Hacker News

Monoliths are not dinosaurs

allthingsdistributed.com

71–80 of 243 posts

Re: Monoliths are not dinosaurs

#71
post #65
post #45

Earlier quoted context omitted.

If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.

Not just managers, but the senior engineers too. You can aggregate all the inter-service communication and say that you’re managing 1000 QPS service mesh rather than a meager backend with 10 QPS.

[deleted]

Re: Monoliths are not dinosaurs

#72

Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…

Aren't microservices an example of complexity creation over the fundamental base case?

Re: Monoliths are not dinosaurs

#73
post #5

Can't we all just go back? Seriously every system I've worked on in the last 10 years seems worse in every metric than what I worked on 2000-2010.

People doing development/marketing/sales of software for money will not go back, but end users who can write software could go back.

The systems can be worse because of what other commenters mention, the financial incentives, but also the companies profiting from worse systems must ensure that expectations are gradually lowered amongst people who write software and that these peoples' "skills" are progressively dumbed down. That is how they ensure that status quo is maintained and that people will never "go back".

Meanwhile, hardware and networking improvements have been amazing.

Re: Monoliths are not dinosaurs

#74

Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…

> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain?

The net gain was composability of microservices, distribution of computing resources, and the ability to marshall off implementation details. Just because those requirements were routinely ignored in the era of monoliths doesn't mean the complexity wasn't essential or didn't exist.

Re: Monoliths are not dinosaurs

#75
post #55

Earlier quoted context omitted.

What do you mean "the type of strings"? In pretty much every programming language, String is one of the most fundamental types. There's no "different types of string". (yes, this is a joke, a bad one at that. badum tish)

there's String, string, std::string, and the satanic *char. Just like there's Slinky, Super Slinky, Extra Slinky, Heavy, and Pro. Nickel-wound (ref counted), steel wound (raw array), and classical nylon (a fucking pointer).

What are gut strings then? Indexed addressing?

Re: Monoliths are not dinosaurs

#76

Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…

reminds me of that law:

"For something to get clean, something else must get dirty"

and the corollary:

"You can get something dirty without getting anything clean"

Re: Monoliths are not dinosaurs

#77
post #47

Earlier quoted context omitted.

Can confirm. judyrecords is built on a near framework-less monolith in PHP + 2 search servers. Searches complete within 100 milliseconds and SRPs return in less than 15 milliseconds on average. Runs a trimmed down version of CodeIgniter 2 (released in 2012) updated to run on PHP 8.2. Still got the CI 2 profiler. https://postimg.cc/TLbvvSzm https://news.ycombinator.com/item?id=30481230

I wonder how many people did their own CodeIgniter updates. I’ve also almost completely transformed the thing, but the base is still CodeIgniter.

Curious, if you don't mind sharing, what site/app!?

Re: Monoliths are not dinosaurs

#78

Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…

> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The net gain was composability of microservices, distribution of computing resources, and the ability to marshall off implementation details. Just because those requirements were routinely ignored in the era of monoliths doesn't mean the complexity wasn't essential or didn'…

Before "microservices" there are services, which are also composable. And in the realm of monoliths there are also modules. Which are the key to composability.

What microservices give you is a hard boundary that you cannot cross (though you can weaken it, you cannot eliminate it) between modules. This means the internal state of a module now has to be explicitly and more deliberately exposed rather than merely bypassed by lack of access control, or someone swapping out public for private, or capitalizing a name in Go. If there's any real benefit of microservices, this is it. The hard(er) boundary between modules. But it's not novel, we've had that concept since the days of COBOL. And hardware engineers have had the concept even longer.

The challenge in monoliths is that the boundary is so easily breached, and it will be over time because of expedient choices rather than deliberate, thoughtful choices.

Re: Monoliths are not dinosaurs

#79

Earlier quoted context omitted.

Netflix is one of AWS largest customers.

True, but I'd say there's zero relationship between the AWS price list and what Netflix pays. So Netflix doesn't really count as an example of how AWS is a practical option for video hosting.

Because Netflix doesn’t do video hosting on AWS. “Running” on AWS isn’t necessarily hosting on AWS.

Re: Monoliths are not dinosaurs

#80
post #32
post #5

Can't we all just go back? Seriously every system I've worked on in the last 10 years seems worse in every metric than what I worked on 2000-2010.

There is no going back. The industry has seen a 5X raise in money and people. It's only natural that a job that used to take 2 now takes 10 people because of those facts. And I agree. We've traded safety and a few other things that could have been ironed out in exchange of massive gridlocks, headaches and colossal facepalms. Performance is only on par if you consider the hardware improvements, it's crazy.

All the laid off tech workers disagree
Post reply on HN