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

181–190 of 243 posts

Re: Monoliths are not dinosaurs

#181

Post by seabrookmx »

pjmlp wrote: post #141
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.

I prefer the SOA terminology because as the post you're replying to says, you don't need to make these services too small, whereas "micro" implies that they are.

Monoliths vs microservices is really a spectrum.

Re: Monoliths are not dinosaurs

#182

Post by selcuka »

ProZsolt wrote: post #158
NohatCoder wrote: post #150

Earlier quoted context omitted.

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.

But you can make a "new service" in code in the same binary communicating through memory. You can then separate it to a separate binary, when the network and serialisation overhead worth it. 80% of the time it will never come.

Microservices are not only "function calls over TCP" though. There are other concerns such as database per service vs a single shared database. There are also security implications that you don't have with a monolity. Designing it that way from the beginning could easily be as complicated as making them separate services.

Re: Monoliths are not dinosaurs

#183

Post by selcuka »

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)

Obviously you haven't seen the Substring [1] type of Swift.

[1] https://developer.apple.com/documentation/swift/substring

Re: Monoliths are not dinosaurs

#184

Post by tinco »

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've never done it myself, but it seems startups are succesfully deploying using for example auth0. Outsourcing auth like that is using microservices right?

Re: Monoliths are not dinosaurs

#185

Post by pjmlp »

seabrookmx wrote: post #181
pjmlp wrote: post #141

Earlier quoted context omitted.

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.

I prefer the SOA terminology because as the post you're replying to says, you don't need to make these services too small, whereas "micro" implies that they are. Monoliths vs microservices is really a spectrum.

I fully agree with that.

Re: Monoliths are not dinosaurs

#186

Post by kqr »

vinay_ys wrote: post #151
kqr wrote: post #144

Earlier quoted context omitted.

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.

Well, flip-flop is usually due to heavy investment too early – on poorly formed thesis of a potential product-market fit or business model (ie., vision). Early days has to be about optimizing aggressively for speed of learning/validation/formation of thesis. There has to be an overarching thesis that is well-formed (formed based on experience/tests from adjacent/related markets, key assumptions validated at reduced s…

This is an incredibly insightful response. Thank you!

Re: Monoliths are not dinosaurs

#187

Post by osigurdson »

viraptor wrote: post #89
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.

I personally know of a two person team that claims to have over 100 microservices. I think most are just lambda functions however.

Re: Monoliths are not dinosaurs

#188

Post by disgruntledphd2 »

jowdones wrote: post #145
disgruntledphd2 wrote: post #135

Earlier quoted context omitted.

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

It's just kinda crap. It's not the same bloody thing. FWIW, I agreed with the general point but disagreed with the language.

I commented to make the OP aware, as I always dislike being downvoted with no explanation. Shrug, it's not like I can pay my mortgage with HN karma.

Re: Monoliths are not dinosaurs

#189

Post by dasil003 »

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…

You're right that factoring into services should be based on natural domain boundaries. That said, it feels like a bit of a strawman to suggest that people are driving their architecture with naive math like this. I've definitely seen journeyman engineers coming out of FAANG and other big companies proposing overly complex service topographies, but there is always at least a veneer of semantic justification.

That's not to say there's no relationship between team size and the applicability of a service-oriented architecture. Microservices are a way of drawing hard boundaries around blocks of logic. These boundaries come with cognitive and operational costs, so they represent significant overhead, but they are a tool for abstracting both logic and physical operations to the maximum degree possible (100% is never possible for a single application). In order to get a net benefit, you have to have enough engineers that they can be experts in a subset of services, and the interfaces to their peer services have to be reliable and stable enough that they can be productive without knowing anything about their internals. So while I agree with you there is no universal floor of microservices that makes based purely on team size, there definitely is a ceiling.

Re: Monoliths are not dinosaurs

#190

Post by sebhans »

ed_elliott_asc wrote: post #118
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…

Does Tesler’s law apply to lines of code or architecture? I have absolutely seen complex code that was created (often for perceived “best practices” like DRY) which could be removed by simplifying the code.

I think it applies to problems, not solutions. The complexity of a given problem cannot change. If you try to ignore part of the inherent complexity of a problem (also called essential complexity) in your solution, it does not disappear but someone else must solve it somewhere else, or the problem is not really solved. If you build a solution that is more complex than the problem itself (in other words, if you add incidental complexity), this does not increase the complexity of the problem either, only the complexity of the solution.

I think a good solution to any problem needs to match it in complexity. I regularly use this comparison as a benchmark for solutions.

Of course, you can also see it this way: The complexity you remove from the code by making it cleaner is added to your team communication because you now have to defend your decision. (Only half joking.)

Post reply on HN