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

61–67 of 67 posts

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

#61

Post by Spivak »

scottious wrote: post #54
Spivak wrote: post #48

Earlier quoted context omitted.

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

If we go with your definition then my app is a monolith with S3 and SQS which doesn't help me pinpoint where the potentially bad architecture thing is.

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

#62

Post by bwship »

eric4smith wrote: post #37

Every project should be started as a monolith. Period. Then as it grows and it makes sense to decouple at the edges then it makes sense. And these micro services only make sense when there is a team responsible for each one. Otherwise the whole thing is like a game of chess - you will forget to make a move at some point.

This seems to be a little over-simplistic. There are many good cases for microservices, and there are times when going into the project, you know it is what is needed. I think there are also a number of ways to make microservices, and it doesn't have to always be difficult. For instance, the last 4 projects I have built have been done with microsoervices, where the API Gateway endpoints such as /user or /machines each talk to their own lambda microservice.

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

#63

Post by scottious »

Spivak wrote: post #61
scottious wrote: post #54

Earlier quoted context omitted.

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

If we go with your definition then my app is a monolith with S3 and SQS which doesn't help me pinpoint where the potentially bad architecture thing is.

yeah -- your app is coupled to those services. I've definitely written code before that depended on a third party API only to have that API break on me.

Granted, this is not something to worry about with S3 or SQS.

> If we go with your definition then my app is a monolith with S3 and SQS

okay sure, I agree that calling your app a monolith with S3 and SQS is ridiculous.

The point is that we all may think that we're writing another S3 or SQS when we write our own micro-services. However, in practice maintaining a stable, backwards compatible, public API like that is quite costly and we usually end up re-implementing function calls as HTTP requests and then calling it "loosely coupled".

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

#64

Post by sailingparrot »

jacobkg wrote: post #32
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…

I’m very intrigued by this comment. It probably captures the thing that has held me back from microservices. Can you explain how one can break up a monolith without keeping the interdepencies?

Say you have some unit of work A within a monolith, and it is used by service B, C, D also in the monolith.

You can carve out A as a microservice with a clean general interface, and write an adapter layer to translate calls from your old messy interface to your new one, and B, C, D call that. Then start refactoring B, C, D one by one depending on your priorities.

That way new service X that needs to use A, can directly start using the clean general API even if B, C, D are not refactored yet.

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

#65

Post by loourr »

After much debate my company recently switched back to a monolithic architecture and it may be the greatest decision we've ever made.

It dramatically simplifies so many aspects of development, which means you can have developers working on more impactful features and you don't have to worry about create a meta structure for keeping things consistent across all your micro services which is one of the biggest benefits I didn't see mentioned in this article.

And in many systems with interdependent logic (which ours is), not duplicating data and not having micro services calling other micro services in loops become incredibly difficult things to avoid.

I highly recommend the monolith for anyone who is not trying to cope with epic scaling issues.

All hail the monolith!

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

#66

Post by KingOfCoders »

js8 wrote: post #49
barbarbar wrote: post #39

Earlier quoted context omitted.

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.

"CORBA was in fashion"

Exactly this.

Post reply on HN