Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monoliths are not dinosaurs

allthingsdistributed.com

Post reply on HN
Print view View original

81–90 of 243 posts

Re: Monoliths are not dinosaurs

#81

Post by rqtwteye »

Aeolun wrote: post #45
keyle wrote: 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.

Even for a tech lead the former is definitely very bad for your resume. You pretty much kill your own career.

Re: Monoliths are not dinosaurs

#82

Post by rqtwteye »

osigurdson wrote: post #67

I think the first step toward sanity is to stop factoring services by team sizes - “we have 100 people so require 20 microservices”. Instead, factor services along natural fault lines. These are areas in the solution that scale differently from other parts and can tolerate communicating over http or message queue. It is fine to have lots of people work on a single service. We compose things using 3rd party libraries…

“we have 100 people so require 20 microservices”.

More like 3 people requiring 13 microservices

Re: Monoliths are not dinosaurs

#83

Post by rqtwteye »

Jtsummers wrote: post #78
sublinear wrote: post #74

Earlier quoted context omitted.

> 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 bypass…

"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."

I just doubt that people who don't have the discipline to write decent modular code will do any better with microservices. You will end up with a super complex, hard to change and hard to maintain system.

Re: Monoliths are not dinosaurs

#84

Post by Spivak »

rqtwteye wrote: post #82
osigurdson wrote: post #67

I think the first step toward sanity is to stop factoring services by team sizes - “we have 100 people so require 20 microservices”. Instead, factor services along natural fault lines. These are areas in the solution that scale differently from other parts and can tolerate communicating over http or message queue. It is fine to have lots of people work on a single service. We compose things using 3rd party libraries…

“we have 100 people so require 20 microservices”. More like 3 people requiring 13 microservices

I'm convinced that micro-service hell happens when the primary app calcifies and becomes too difficult to modify.

Re: Monoliths are not dinosaurs

#86

Post by yotamoron »

rqtwteye wrote: post #83
Jtsummers wrote: post #78

Earlier quoted context omitted.

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 bypass…

"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." I just doubt that people who don't have the discipline to write decent modular code will do any better with microservices. You will end up with a super complex, hard to change and hard to maintain system.

Exactly. 100% right.

Re: Monoliths are not dinosaurs

#87

Post by hibikir »

paulddraper wrote: post #37

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…

The talk of essential and incidental complexity is, in practice, far less useful than it seems. It's just very easy to just agree in trying to just get rid of incidental complexity, in the same way that it's easy for people to agree on getting rid of unnecessary, wasteful government programs, until the second you define which ones you mean.

Every time I've had that argument at work, ultimately there's no agreement of what is essential. In one of the worst cases, the big fan of the concept was a CEO considering themselves very technical, who decided that everything they didn't understand was obviously valueless and incidental, while everything they personally cared about was really essential complexity, and therefore impossible to simplify... even though the subsystem in question never had any practical applications until the company failed.

So ultimately, either the focus on avoiding incidental complexity is basically a platitude, or just a nice way to try to bully people into your favorite architecture. A loss either way.

Re: Monoliths are not dinosaurs

#88

Post by kqr »

missingcolours wrote: post #70
Aeolun wrote: 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.

In the past and in other industries you'd choose the former because you'd get hit hard if your manager realized what you were doing. But in the easy-money FAANG world your manager is usually playing the same game, so they actually prefer that you go with the latter.

I agree. These decisions are not made economically, they are made politically. And the big complicated thing is far more prestigious.

Then let's say half of our profession has less than five years of experience (though I would guess it's closer to two years) -- they see what the elders do and copy that, like any good apprentice would. Suddenly, it's all they know.

Wild conjecture, of course. I would like to see it studied!

Re: Monoliths are not dinosaurs

#89

Post by viraptor »

osigurdson wrote: post #67

I think the first step toward sanity is to stop factoring services by team sizes - “we have 100 people so require 20 microservices”. Instead, factor services along natural fault lines. These are areas in the solution that scale differently from other parts and can tolerate communicating over http or message queue. It is fine to have lots of people work on a single service. We compose things using 3rd party libraries…

> "we have 100 people so require 20 microservices"

Is this something that actually happened? Not heard from some third party - actually has someone experienced this as a decision in a technical team? It seems... unlikely.

Re: Monoliths are not dinosaurs

#90

Post by mullingitover »

I can’t believe it’s news that someone said this. I thought everyone understood: you don’t try to do microservices until you have to. Before you get to that point you make your monolith modular enough that if you ever need microservices you’re prepared to break them out.
Post reply on HN