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

141–150 of 243 posts

Re: Monoliths are not dinosaurs

#141

Post by pjmlp »

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…

Microservices are rebrandend SOA.

We weren't doing Sun RPC, PDO, CORBA and DCOM everywhere for fun, yet with some rebranding, SOA should be the solution for everything.

Re: Monoliths are not dinosaurs

#142

Post by justinclift »

bedobi wrote: post #55
gabereiser wrote: post #54

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)

Meh, "text" is where it's at. "varchar()" is so Oracle. :p

Re: Monoliths are not dinosaurs

#143

Post by sverhagen »

For many years to come, for better or for worse, people will point to the Prime team's blog post as the definitive proof that microservices are inferior. And instead of perspective of nuance, it'll be used for absolutist arguments. I'm already tired of it in anticipation...

Re: Monoliths are not dinosaurs

#144

Post by kqr »

vinay_ys wrote: post #128
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…

Both essential complexity and accidental complexity can be created or destroyed based on how functional scope or technical scope is defined and understood. In a live and evolving system, a lot of complexity is also because of not having a vision for how the product domain or market or ecosystem might evolve and having a coherent shared understanding of it amongst product managers and platform builders. When product d…

Do you have a suggestion on how to avoid the flip-flopping problem? Or is there a way to turn with the wind without increasing complexity? Genuinely curious.

Re: Monoliths are not dinosaurs

#145

Post by jowdones »

disgruntledphd2 wrote: post #135
jowdones wrote: post #108

Earlier quoted context omitted.

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]

So using the "wage slave" rethoric is punished now by the Thought Police. Happy happy thoughts and be greatful for the opportunity to trade our lives for a measly pay working for the man.

Re: Monoliths are not dinosaurs

#147

Post by andyjohnson0 »

There was a perceptive comment on HN a few days ago [1] to the effect that microservices are a useful way to package a body of code if the team that is consuming the code doesn't trust the team that built it. This brings to mind Conway's law - "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure" [2] - and also that meme from a few years back about the internal structure of tech companies [3]. So you can argue that monolith/non-monolith it not purely a tech-driven consideration

[1] Too lazy to keep looking right now

[2] https://en.wikipedia.org/wiki/Conway%27s_law

[3] https://www.reddit.com/r/ProgrammerHumor/comments/6jw33z/int...

Re: Monoliths are not dinosaurs

#149

Post by eternalban »

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…

tldr:

Microservices trade design complexity with operational complexity, to address the shortcomings & patterns of the modern IT sector, at both worker and management levels.

This was an excellent choice for consulting (companies like ThoughtWorks, who were pushing microservices) as it optimized their workflows and bottom line: the answer to every client's question of "what's the architecture?" was "Microservices". The companies pimping m.s. were internally optimized for this architecture - running a consulting shop where the time between "here is our project" to "here is our proposal" is approaching zero is profitable.

And the best part -- just like all those "GPT-processes" now being pushed by companies built around an api -- is that by the time clients encounter operational complexity of running micro-services, the consultants have long left the building.

Re: Monoliths are not dinosaurs

#150

Post by NohatCoder »

Zanfa wrote: post #120

A good rule of thumb is that if you’re starting a new project and immediately implement microservices, you’ve already failed. Never seen it work, don’t think I ever will. The only way microservices can ever work is if they’re extracted over time as the monolith gets fleshed out, likely over the course of years. And even they’re probably a bad idea.

I think that splitting things can be a good idea once in a while. The important part is that you only make a new service because some job fits being its own service.

The microservice syndrome begin once you start splitting services simply because you arbitrarily declare them too large.

Post reply on HN