Live data from Hacker News

Monoliths are not dinosaurs

allthingsdistributed.com

51–60 of 243 posts

Re: Monoliths are not dinosaurs

#51

Like most articles in distributed systems, this makes wild assumptions about the most important, i.e. the human layer. I would bet $100 that this is written by the same sort of person who thinks "Managers – what do they do all day exactly?" [1] > If you hire the best engineers.... Guess what, there is no broad consensus on what "best engineer" means. I bet your org is rejecting really good engineers right now because…

Their point on hiring the best engineers was specifically about not following the hype, and allowing engineers to engineer. Also, they never claimed technical superiority of microservices, quote: > For example, a startup with five engineers may choose a monolithic architecture because it is easier to deploy and doesn’t require their small team to learn multiple programming languages.

> Their point on hiring the best engineers was specifically about not following the hype, and allowing engineers to engineer.

That’s weird. Any time I’ve seen anyone let their engineers engineer, those engineers have immediately started following the hype.

Re: Monoliths are not dinosaurs

#52
post #50

Earlier quoted context omitted.

This is probably good advice for CTOs and directors who manage software products, but it seems to imply the rest of us have to make software that already matches the political structure.

Try building software that doesn’t match the political structure. I guarantee you will regret it. You’ll constantly be dealing with all the problems because nobody else will care.

Sounds like a way to spend a lot of your time doing “cross functional work.”

Re: Monoliths are not dinosaurs

#53

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…

[dead]

Re: Monoliths are not dinosaurs

#54

You know, I'm pretty sure you could build a PHP monolith in 2023 without a framework and it would do what it needed to do.

Bad coding is infinitely worse than a “bad” language. I don’t know how many of you are musicians, but many people are surprised to find that the tone quality of a guitar has way more to do with the person playing it than the way it was built.

A great player can make a Squire sound like a Studio Strat. Indeed. The type of strings make a difference too.

Re: Monoliths are not dinosaurs

#55

Earlier quoted context omitted.

Bad coding is infinitely worse than a “bad” language. I don’t know how many of you are musicians, but many people are surprised to find that the tone quality of a guitar has way more to do with the person playing it than the way it was built.

A great player can make a Squire sound like a Studio Strat. Indeed. The type of strings make a difference too.

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)

Re: Monoliths are not dinosaurs

#56
post #55

Earlier quoted context omitted.

A great player can make a Squire sound like a Studio Strat. Indeed. The type of strings make a difference too.

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)

In some languages it's two or more of the fundamental types. Obviously you haven't been using the big brained languages like Rust, Haskell, or Elixir.

(Also a bad joke.)

Re: Monoliths are not dinosaurs

#57
post #45
post #32

Earlier quoted context omitted.

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.

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.

What do you mean zero prestige in that? Do you know the difference in salary, importance and status in managing a team of 50 vs one of only two?

Re: Monoliths are not dinosaurs

#58
post #40
post #34

Earlier quoted context omitted.

Now that PHP has lost its massive deployment advantage, step up to Rails or Python.

I hear about Python all the time. Rarely hear about Rails now. I think the world picked one over the other.

I was at RailsConf 2022 and it was packed, even considering the strict covid rules. There were lots of people there from teams transitioning from React+Go to Rails.

Re: Monoliths are not dinosaurs

#59
post #50

Earlier quoted context omitted.

Try building software that doesn’t match the political structure. I guarantee you will regret it. You’ll constantly be dealing with all the problems because nobody else will care.

Sounds like a way to spend a lot of your time doing “cross functional work.”

I never thought about that as a euphemism for "you're doing it wrong." Makes me rethink my priorities...

Re: Monoliths are not dinosaurs

#60
post #55

Earlier quoted context omitted.

A great player can make a Squire sound like a Studio Strat. Indeed. The type of strings make a difference too.

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)

When I worked at Google, they had their own string type in place of std::string for various reasons.

Python has byte strings, Unicode strings, format strings, regular expression strings, and probably a few others!

Rust has str and String, depending on ownership.

Post reply on HN