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

131–140 of 243 posts

Re: Monoliths are not dinosaurs

#131

Post by javanonymous »

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…

There are tools for enforcing boundaries.

One name for this is "Modulith" where you use modules that have a clear enforced boundary. You get the same composability as micro-services without the complexity.

Here's how Spring solves it: https://www.baeldung.com/spring-modulith

It's basically a library that ensures strict boundaries. Communication has to go through an interface (similar to service api) and you are not allowed to leak internal logic such as database entities to the outer layer

If you later decide to convert the module into a separate service, you simply move the module to a new service and write a small API layer that uses the same interface. No other code changes are necessary.

This enables you to start with a single service (modulith) and split into microservices later if you see the need for it without any major refactoring

Re: Monoliths are not dinosaurs

#132

Post by bilalq »

jeswin wrote: post #106

HN could be a little less pessimistic. People aren't choosing microservices merely because of the hype. Here's why I'd choose microservices for a large project: 1. People don't produce uniform code quality. With microservices, the damage is often contained. 2. Every monolith is riddled with exceptional cases in a few years. Only a few people know about corner cases after a few years, and the company becomes dependent…

I very much agree with these points.

1 & 8: This is something I've experienced first-hand quite a bit. When code quality starts slipping in service, it accelerates and inevitably leads to more hacks built on hacks. The containment afforded by service separation helps keep these hacks quarantined and minimizes the pollution and spread.

6. There's no ambiguity or question of who owns what when services/packages are separated and have distinct owners. Transferring ownership means transferring ownership of the service. In large companies with some teams working on secret projects, it's much easier to have viable workflows with service separation than with a monolith. Permissions management and so many other things are easier.

7: I think this is an excellent point. Another way of looking at this is as having multiple focused monoliths.

I'd also add that there's a benefit in blast radius minimization. Updating a library or merging in a risky change doesn't risk breaking literally everything all at once. One service can update something and you know for a fact that it can't break anything other than that service and its dependents.

Re: Monoliths are not dinosaurs

#133

Post by cjfd »

jeswin wrote: post #106

HN could be a little less pessimistic. People aren't choosing microservices merely because of the hype. Here's why I'd choose microservices for a large project: 1. People don't produce uniform code quality. With microservices, the damage is often contained. 2. Every monolith is riddled with exceptional cases in a few years. Only a few people know about corner cases after a few years, and the company becomes dependent…

The truthfulness of this comment depends very heavily on four words: 'for a large project'. This is the problem with the microservices hype. It is so very easy to ignore this four word restriction and start applying them everywhere. As such your post is a contribution to the problem and not the the solution.

Re: Monoliths are not dinosaurs

#134

Post by viraptor »

benjiweber wrote: post #113
viraptor wrote: post #89

Earlier quoted context omitted.

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

It's usually a consequence of something like Bezos' API mandate https://api-university.com/blog/the-api-mandate/ Multi-team ownership of a single deployable has downsides to tradeoff against the complexity of more service and harder boundaries.

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 microservices being forced on people when it rarely if ever happens. If not, I'm happy to hear actual first hand experiences.

Re: Monoliths are not dinosaurs

#135

Post by disgruntledphd2 »

jowdones wrote: post #108
EasternGuy wrote: post #104

Earlier quoted context omitted.

On a vaguely related note but still shows how the World works. Back in 1992, my Eastern European computer science teacher told us a story. He used to work as a programmer, doing "ERP" software for communist companies (state-owned, of course). The software would run on machines featuring Z80 CPU with CP/M operating system. Anyhow after the change of regime they got 386 PCs and rewrote the software to run on them. The…

This shows what they failed to consider in those optimistic views of the 1930s like John Maynard Keynes who predicted that his grandkids would work just 15 hours a week. Slaves don't trade productivity for their lives, they trade time. No matter how many trillions of times more productive human activities will become, slaves's time will still belong to the masters and very little of their life will belong to them.

[flagged]

Re: Monoliths are not dinosaurs

#136

Post by makapuf »

kqr wrote: post #107
dimtion wrote: post #41

Earlier quoted context omitted.

Given your last sentence incidental complexity can be created and destroyed (and is more difficult to destroy than create). The quote would probably be more accurate as: > "ESSENTIAL Complexity can neither be created nor destroyed, only moved somewhere else."

Essential complexity can also be created and destroyed, though sometimes it happens earlier in the design process. Picking the problem you choose to solve is how you control essential complexity.

Essential complexity is inherent to the problem you have. The solutiom is layered between product design, technical design and implementation. What is essential complexity for a layer can be accidental for the layer above.

Re: Monoliths are not dinosaurs

#137

Post by jack_riminton »

m463 wrote: post #76
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…

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"

How does that apply here? (I’m not being facetious)

Re: Monoliths are not dinosaurs

#138

Post by justinclift »

byyyy wrote: post #99
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…

>Complexity can neither be created nor destroyed, only moved somewhere else. Not true. I blow.up a car. Complexity is destroyed. I rebuild the car from blown up parts. Complexity is created. There's no underlying generic philosophical point about microservices and monoliths. What we can say is that microservices are not necessarily less complex than monoliths, but this relationship has no bearing on the nature of com…

> I blow.up a car. Complexity is destroyed.

Wouldn't the blown-up car be more complex than the non-blown-up car?

Re: Monoliths are not dinosaurs

#139

Post by przemo_li »

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.

Over focusing on source leads to stand conclusions.

True remedy in both cases is refactoring. So if team don't have time for refactoring in monolith, then switch to microservices would need to free up enough time for the team to start doing it.

Can that even with on a level of a single team?

Re: Monoliths are not dinosaurs

#140

Post by justinclift »

kqr wrote: post #124
Spivak wrote: post #84

Earlier quoted context omitted.

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

What are the specific decisions along this course of events? I guess nobody says "Our primary app has calcified and become too difficult to modify. Let's make microservice hell!" But what do people say that leads down that road, in your experience?

Pretty sure this would be fairly common:

    Welcome to your new job as Architect for our software!

    What are some of the main bullet points you have in mind
    for our next major release... ?
Post reply on HN