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

Is there any place for monoliths in 2021? (2020)

fjrevoredo.me

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Is there any place for monoliths in 2021? (2020)

#41

Post by drbojingle »

rollulus wrote: post #15

In the cons of monoliths: "High coupling between components" is listed. I think this is a misconception, and a popular one: some people apparently believe that if you take software, and introduce some RPC form at "component" boundaries, things are magically decoupled. I.e., just because execution happens in a different process, it is decoupled. And this fallacy is what leads to the distributed monolith. Or am I missi…

100%. As long as two things are communicating they're coupled. Doesn't matter if communication is calling a function or making a network request.

Re: Is there any place for monoliths in 2021? (2020)

#42

Post by meowface »

ludston wrote: post #33
rollulus wrote: post #15

In the cons of monoliths: "High coupling between components" is listed. I think this is a misconception, and a popular one: some people apparently believe that if you take software, and introduce some RPC form at "component" boundaries, things are magically decoupled. I.e., just because execution happens in a different process, it is decoupled. And this fallacy is what leads to the distributed monolith. Or am I missi…

If you compare making a call to a web service vs calling a function to achieve a similar outcome, it is definitely true that you can easily have business logic coupled between these two services. You also have the additional cost of having to handle network errors in the calling function. However, scaling a monolith (as someone who does this for their day-job) is significantly harder than scaling independent services…

To play Devil's advocate, how about just running multiple instances of the monolith behind a load balancer, and using database replicas/shards/load balancing?

Being able to scale individual components/services will be the most efficient solution, but if there doesn't happen to be a particular bottleneck that bogs down everything else (besides the database), it seems like the traditional monolithic load balancing approach may not be so bad.

Especially compared to the effort of trying to split an existing monolith into microservices. And if there are other bottlenecks, you can focus your effort on improving or isolating those parts.

(I only have intermediate experience in this area and certainly way less than you do; definitely not trying to claim anything authoritative.)

Re: Is there any place for monoliths in 2021? (2020)

#43

Post by dasil003 »

I feel all these black and white comparisons of monolith vs microservices tend towards being overly reductive and miss the crux of the matter.

First, "microservice" is a terrible name (we should have just stuck with SOA), it leads to all kinds of agile consultant snake-oil salesmen claiming some ideal size for a service. That's bullshit. Services should be defined by their interfaces, full stop. If you can't come up with a stable interface between two services such that the interface changes orders of magnitude than the code within each service, or if you find yourselves always having to deploy the services in pairs due to leaky abstraction on the interface, then they probably shouldn't be two services.

Second, SOA is primarily a tool for scaling teams. Yes there are some tangential benefits in terms of code base size, CI build time, etc, but those are false economies if you have a small team that has to deal with the overhead of many services. Modern web-scale architectures are really about factoring things to leverage specialists to scale very large tech platforms.

Third, and perhaps most importantly. In any rapidly growing business you need to evolve quickly. You should not expect to design a perfect architecture day one, you should plan to evolve the architecture continuously, so that every two orders of magnitude growth you look up and realize you've replaced most of what you've previously written one way or another. Small startups that focus on "microservices" before they are anywhere near 100 engineers tend to die before traction.

Re: Is there any place for monoliths in 2021? (2020)

#44

Post by UglyToad »

recursivedoubts wrote: post #9

microservices: let's take the hardest problem in software construction, factoring the system properly, and introduce network connections and deployment complexity into it. yeah, there's a place for monoliths, and developers who are willing to ignore the industries ludicrous fads and faang-chasing have the advantage.

I feel like the hype made a lot of people (not you) forget there's a middle ground, like you can't just have "services". I therefore propose a new hype cycle "mesoservices", i.e. only split out a service from the monolith when needed and it just does as much as is necessary.

Re: Is there any place for monoliths in 2021? (2020)

#45

Post by andrewstuart2 »

ludston wrote: post #33
rollulus wrote: post #15

In the cons of monoliths: "High coupling between components" is listed. I think this is a misconception, and a popular one: some people apparently believe that if you take software, and introduce some RPC form at "component" boundaries, things are magically decoupled. I.e., just because execution happens in a different process, it is decoupled. And this fallacy is what leads to the distributed monolith. Or am I missi…

If you compare making a call to a web service vs calling a function to achieve a similar outcome, it is definitely true that you can easily have business logic coupled between these two services. You also have the additional cost of having to handle network errors in the calling function. However, scaling a monolith (as someone who does this for their day-job) is significantly harder than scaling independent services…

Your scaling argument is one of the oft cited arguments. I've cited it myself. The reality I've experienced has largely been contradictory, though. The reality is now you have bottlenecks in each of your services and you likely have a much harder time figuring out where the internal and cross-service bottlenecks actually are. You have to add a lot of modern and cutting edge tech to really get an accurately traced performance picture, and the truth is that pretty much nobody does that when they're building their microservices. Only once things start falling over do they consider adding these things that would just be available much more readily in a single process.

Re: Is there any place for monoliths in 2021? (2020)

#46

Post by pulse7 »

drbojingle wrote: post #41
rollulus wrote: post #15

In the cons of monoliths: "High coupling between components" is listed. I think this is a misconception, and a popular one: some people apparently believe that if you take software, and introduce some RPC form at "component" boundaries, things are magically decoupled. I.e., just because execution happens in a different process, it is decoupled. And this fallacy is what leads to the distributed monolith. Or am I missi…

100%. As long as two things are communicating they're coupled. Doesn't matter if communication is calling a function or making a network request.

There is a difference between "loose coupling" and "tight coupling". Components/modules should be loosely coupled - regardless if they run within the same process or not. Component/module interfaces should be carefully designed so that coupling is loose.

Re: Is there any place for monoliths in 2021? (2020)

#47

Post by majormajor »

derefr wrote: post #20
rollulus wrote: post #15

In the cons of monoliths: "High coupling between components" is listed. I think this is a misconception, and a popular one: some people apparently believe that if you take software, and introduce some RPC form at "component" boundaries, things are magically decoupled. I.e., just because execution happens in a different process, it is decoupled. And this fallacy is what leads to the distributed monolith. Or am I missi…

Monoliths have high coupling by default — coupling components together is the "easy" and "obvious" way to get things done in a monolithic codebase, and so it's what junior devs will inevitably do when pressed for time. A monolithic system's architect would have to make an explicit choice at some point, to reject/restrict coupling (by e.g. building the monolith on an actor-model language/framework, where components th…

Microservices worked on by those same developers have high coupling by default, too.

This is because coupling is a design instead of an implementation decision. "Make a synchronous RPC call between components" is still the "easy" and "obvious" way to get things done.

It's sometimes easier to spot high coupling when looking at code in a microservice world, but it still requires you to know what you're looking for and know how to avoid it, and not give in to the temptation.

Last time I was working with people trying to split up a monolith I pleaded with them to try to understand the coupling first, and figure out what a system would look like without that coupling before actually just moving all the code around and replacing direct method calls with ... other method calls that made synchronous RPC network calls.

No luck.

Error rate went up.

Re: Is there any place for monoliths in 2021? (2020)

#48

Post by Spivak »

drbojingle wrote: post #41
rollulus wrote: post #15

In the cons of monoliths: "High coupling between components" is listed. I think this is a misconception, and a popular one: some people apparently believe that if you take software, and introduce some RPC form at "component" boundaries, things are magically decoupled. I.e., just because execution happens in a different process, it is decoupled. And this fallacy is what leads to the distributed monolith. Or am I missi…

100%. As long as two things are communicating they're coupled. Doesn't matter if communication is calling a function or making a network request.

I think this is too strong of a definition because then everything is a monolith.

We need a definition of what it means for two services to communicate while being “uncoupled”. I think “are versioned independently” or “don’t have to be upgraded in parallel” meets the bar.

Re: Is there any place for monoliths in 2021? (2020)

#49

Post by js8 »

barbarbar wrote: post #39
KingOfCoders wrote: post #27

Earlier quoted context omitted.

I've worked for a very successful very high margin $200M+ revenue company with very good salaries on a (some years back) CORBA Java system.

Some would argue that if you are using corba you probably have a pretty good idea of what you are doing and you are not doing fashion/hype driven development.

It might also mean that they had the project created when CORBA was in fashion, and it survived to this day, because it was an actually useful system, and despite the architecture being - whatever it was.

Re: Is there any place for monoliths in 2021? (2020)

#50

Post by Spivak »

kingdomcome50 wrote: post #26
rollulus wrote: post #15

In the cons of monoliths: "High coupling between components" is listed. I think this is a misconception, and a popular one: some people apparently believe that if you take software, and introduce some RPC form at "component" boundaries, things are magically decoupled. I.e., just because execution happens in a different process, it is decoupled. And this fallacy is what leads to the distributed monolith. Or am I missi…

No no no. This is right. Inserting layers of indirection doesn't change the inherent coupling that exists between components. Sure you may be able to call it "looser" coupling, but you may also be able to call it a rats nest of complexity!

Yep, monoliths aren’t a bad thing so long as the problem domain is actually inherently coupled.

If you break out a separate service from your monolith and it’s not independently useful to things other than your app then you probably should put it back.

Post reply on HN