Is there any place for monoliths in 2021? (2020) • Hacker News Board

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

#51

Post by majormajor » Wed, Aug 04, 2021, 3:54 PM UTC

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…

Last time I was scaling a monolith I basically did it purely by splitting up the DB into multiple ones with different purposes and improving query perf just through that.

I would've had to do all the same work to extract it to microservices, but also would've had to do a lot more on top. Had it not been a legacy system, probably worth it - but as it was, leaving it as a monolith querying a now-split-up set of DBs was cheaper and faster.

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

#52

Post by ihuk » Wed, Aug 04, 2021, 3:57 PM UTC

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…

Well said.

I had a misfortune to work on a project where this exact thinking was used to carve up relatively simple system into about a dozen microservices. Turns out referential integrity and transactions are really, really useful. For example, most task required calls to multiple microservices and if something broke in one of the microservices involved it would often leave other microservices in inconsistent state and retrying failed task became almost impossible. Project was scrapped after 3 years of development.

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

#53

Post by mamcx » Wed, Aug 04, 2021, 4:08 PM UTC

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…

Also "High coupling between components" is, a lot of times, GOOD.

The more everything in the pipeline know about each other, the easiest is to code it and the FASTEST will be.

You can say any performance gains is possible when you exploit this facts. And the more "abstract/invisible" everything is the more impossible is to make it so.

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

#54

Post by scottious » Wed, Aug 04, 2021, 4:10 PM UTC

Spivak wrote: post #48

drbojingle wrote: post #41

Earlier quoted context omitted.

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.

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

Yes... exactly. More things are monoliths than we want to admit.

> We need a definition of what it means for two services to communicate while being “uncoupled”

Take a dead simple example: an application server that talks to an in-house video encoding micro-service

Even if that video encoding service only has a single really well designed endpoint, there's STILL coupling between the application server and the video encoding service.

Just because we've replaced a method call with an HTTP request doesn't mean things aren't coupled anymore.

Sure -- you may be able to deploy certain changes to your video encoding service without changing your application service. However, you need to be keenly aware of what changes are compatible with existing application servers and which are not and that adds complexity and cognitive load. Maybe it's worth it in some cases. In many cases, it's not.

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

#55

Post by drbojingle » Wed, Aug 04, 2021, 4:10 PM UTC

Spivak wrote: post #48

drbojingle wrote: post #41

Earlier quoted context omitted.

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.

I don't think a monolith is defined by coupling. I think it's defined by being a single deployment of custom code covering many domains/including many kinds of functionalities, rather than many deployments.

Your definition of uncoupled makes some sense. It's a good starting place at the very least.

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

#56

Post by drbojingle » Wed, Aug 04, 2021, 4:12 PM UTC

pulse7 wrote: post #46

drbojingle wrote: post #41

Earlier quoted context omitted.

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.

from your perspective, what are the differences?

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

#57

Post by xnx » Wed, Aug 04, 2021, 4:17 PM UTC

mmazing wrote: post #38

zinekeller wrote: post #10

> If we analyze most of the successful migrations into microservices, they were driven almost exclusively from necessity rather than preference. This is basically how everything should work. There's no need to rush things if you don't need it now, especially that some that do convert are disappointed at the results (it's not the microservices themselves, it's the specific migration planning, design, and maintenance.)…

> This is basically how everything should work. There's no need to rush things if you don't need it [right] now. I'm really not sure why this is so difficult to grasp for so many people in IT. I think it stems from a desire to not have to think too hard about how to solve a problem since "someone else has already solved this." ... or maybe an inability to do so.

Many IT people are tech-fetishists and only solve genuine problems incidentally.

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

#58

Post by derefr » Wed, Aug 04, 2021, 4:20 PM UTC

majormajor wrote: post #47

derefr wrote: post #20

Earlier quoted context omitted.

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…

> "Make a synchronous RPC call between components" is still the "easy" and "obvious" way to get things done.

It all depends on relative friction. Systems designed from the ground up to "think service-oriented" will use languages/runtimes/frameworks that make low-coupling options easier and more idiomatic than synchronous RPC calls.

For example, if your SOA is built on CQRS/ES, then adding an Event to the event store, for another Command to react to, should be easier than making an RPC call.

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

#59

Post by ludston » Wed, Aug 04, 2021, 4:22 PM UTC

andrewstuart2 wrote: post #45

ludston wrote: post #33

Earlier quoted context omitted.

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 per…

Most systems don't need to scale beyond "please no obvious performance bugs", so it makes sense to write most applications as monoliths for the reason that you are stating (i.e. development is faster).

It only makes sense to write services (note, "services", not "micro-services") when it is inevitable and obvious that your software is hitting scaling issues related to some subsystem, or when you have systems that need to be independently reliable. (i.e. ATM's should work even when the banks website is down)

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

#60

Post by ludston » Wed, Aug 04, 2021, 4:38 PM UTC

meowface wrote: post #42

ludston wrote: post #33

Earlier quoted context omitted.

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 appr…

Your thinking is along the right lines. The "you can focus your effort on improving or isolating those parts" is the trouble. With a sufficiently complex code-base this has a very high cost, and the number of programmers capable or willing to do this sharply declines.