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

211–220 of 243 posts

Re: Monoliths are not dinosaurs

#211

Post by kqr »

simplotek wrote: post #207
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…

> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The main misconception about microservices is that people miss why they exist and what problems they solve. If you don't understand the problem, you don't understand the solution. The main problems microservices solve are not technical, but organizational and operational. S…

> Once you feel the need to assign ownership of specific responsibilities or features or data to dedicated teams, you quickly are better off if you specify the interface, and each team owns everything begind each interface.

If team A needs a new endpoint from team B, what would a typical dialogue look like under microservices and a modular monolith, respectively?

Re: Monoliths are not dinosaurs

#212

Post by grumpyprole »

ndriscoll wrote: post #195
grumpyprole wrote: post #171

Earlier quoted context omitted.

> The challenge in monoliths is that the boundary is so easily breached The biggest challenge with monoliths is the limits of a single process and machine.

Typically the application server is stateless and any persistent state is kept in a database, so you can just spawn another instance on another machine.

Sure but there's still limits such as the binary size and working memory etc

Re: Monoliths are not dinosaurs

#213

Post by kqr »

simplotek wrote: post #208
paulddraper wrote: post #192

Earlier quoted context omitted.

It's a frame of mind. Often a developer will see something big or complex and see it as a problem. But they should consider whether this matches the size/scope of the problem being solved

> But they should consider whether this matches the size/scope of the problem being solved In professional software development projects, specially legacy projects, often times the complexity is not justified by the problem. There is always technical debt piling up, and eventually it starts getting in the way.

> often times the complexity is not justified by the problem.

Often times means not always -- what would you say some projects are doing right so that their complexity is justified by the problem?

Re: Monoliths are not dinosaurs

#214

Post by kqr »

grumpyprole wrote: post #212
ndriscoll wrote: post #195

Earlier quoted context omitted.

Typically the application server is stateless and any persistent state is kept in a database, so you can just spawn another instance on another machine.

Sure but there's still limits such as the binary size and working memory etc

Could you give a concrete example from your experience? I ask because in my experience, services have had a relatively small (say less than a few hundred GB) fixed working memory usage, and the rest scales with utilisation meaning it would help to spawn additional processes.

In other words, it sounds like you're speaking of a case where all services together consume terabytes of memory irrespective of utilisation, but if you can split it up into multiple heterogeneous services each will only use at most hundreds of GB. Is that correct, and if so, what sort of system would that be? I have trouble visualising it.

Re: Monoliths are not dinosaurs

#215

Post by kqr »

papito wrote: post #164
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'…

This is a very nice academic theory, but in real life you get half-assed, half-implemented hairballs that suck out your will to live if you have to untangle that.

What are the sequence of events that happen in real life that take us from nice theory to hairballs, that academics fail to foresee?

Re: Monoliths are not dinosaurs

#216

Post by kqr »

tracker1 wrote: post #198
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…

I'd add that abstracting complexity should be done where it makes the rest of the system easier to understand over the abstraction. Too much abstraction can make systems harder to understand and work with instead of easier.

Assuming you are not perfect, you must have implemented too much abstracted systems at some point. What went through your head when you did that? What thoughts legitimized that extra layer of abstraction that turned out to be superfluous?

Re: Monoliths are not dinosaurs

#217

Post by kqr »

byyyy wrote: post #173
justinclift wrote: post #138

Earlier quoted context omitted.

> I blow.up a car. Complexity is destroyed. Wouldn't the blown-up car be more complex than the non-blown-up car?

In that case complexity is created thereby proving my point anyway. Typically I define complexity as a low probability macrostate meaning low entropy. So debris generated from the explosion has a high probability of randomly occuring, while a new car has a very low probability of randomly occuring. Following this definition you arrive at a formal definition of complexity that is intuitive. Imagine a tornado that rand…

> So it is very likely for a tornado to reconfigure things into debris and extremely extremely unlikely for the tornado to reconfigure everything into a brand new car.

Is this not a linguistic sleight of hand? There are billions of trillions of states we label with "debris" but only a few thousand we would call "car". So a specific state of debris, then, is equal in complexity to a car?

Re: Monoliths are not dinosaurs

#218

Post by viraptor »

benjiweber wrote: post #210
viraptor wrote: post #134

Earlier quoted context omitted.

That doesn't translate from the mandate, which is what I'm trying to cautiously call out. There's a big difference between "our company will not have a god database" and "we need to make more services just because we have more people". The link also mentions that the mandate was "something long these lines" - we don't know exactly what the split rules were. I think people bring up an exaggerated idea of extreme micro…

It does if there's an upper bound on the number of people in an effective team.

It's not "there's an extra person, now we need to create a new service". It's more likely "we need this extra service and that means some people will need to take care of it". It's an inverse of what the comment I'm disputing said.

Anyways, it's still not an example of this happening. It's a recollection of a letter that maybe implies this result.

Re: Monoliths are not dinosaurs

#219

Post by papito »

kqr wrote: post #215
papito wrote: post #164

Earlier quoted context omitted.

This is a very nice academic theory, but in real life you get half-assed, half-implemented hairballs that suck out your will to live if you have to untangle that.

What are the sequence of events that happen in real life that take us from nice theory to hairballs, that academics fail to foresee?

Most companies severely underestimate the complexities of a distributed system and the work that goes into a truly resilient, scalable setup of this kind.

An infrusctructfre of this sort is meant to solve very hard problems, not to make regular problems much harder.

Re: Monoliths are not dinosaurs

#220

Post by lelanthran »

simplotek wrote: post #209
lelanthran wrote: post #152

Earlier quoted context omitted.

> Complexity can neither be created nor destroyed, only moved somewhere else. I have to say that this short quote is not the whole story; for example it's ridiculously common for artificial complexity to be introduced into a system, like using microservices on a system that gets 1k users a day. In which case, it is sometimes possible to remove complexity, because you are removing the artificial complexity that was ad…

> (...) like using microservices on a system that gets 1k users a day. This sort of specious reasoning just shows how pervasive is the fundamental misunderstanding of the whole point of microservices. Microservices solve organizational problems, and their advantages in scaling and reliability only show up as either nice-to-haves or as distant seconds. Microservices can an do make sense even if you have 10 users makin…

> Microservices can an do make sense even if you have 10 users making a hand full of requests, if those services are owned and maintained by distinct groups.

Maybe, but after the next CEO comes in, those groups would be reorganised anyway :-/

Few companies maintain their org chart for a large length of time. My last place had the microservices maintained by distinct groups when I joined. When I left a third of the people were gone and half the groups were merged into the other half.

This is not an uncommon thing. Going microservices because you don't want to step on other peoples toes is a good reason, but it's an even bet that the boundaries will shift anyway.

Post reply on HN