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

Monolith First (2015)

martinfowler.com

Post reply on HN
Print view View original

11–20 of 82 posts

Re: Monolith First (2015)

#11

Post by kemitche »

I firmly believe that monolith vs microservice is much more a company organization problem than a tech problem. Organize your code boundaries similar to your team boundaries, so that individuals and teams can move fast in appropriate isolation from each other, but with understandable, agreeable contracts/boundaries where they need to interact.

Monoliths are simpler to understand, easier to run, and harder to break - up until you have so many people working on them that it becomes difficult for a team to get their work done. At that point, start splitting off "fiefdoms" that let each team move more quickly again.

Re: Monolith First (2015)

#12

Post by brodouevencode »

taeric wrote: post #6
brodouevencode wrote: post #2

the problem with the yagni argument is is you aint gonna need it until you do

I think there is a variant of "you don't currently need it" that people should follow more. Build towards what you think you will need, by all means. But try and only build what you need right now.

This is a good point, and lines up with the real yagni argument.

However, I do not like the readiness that people have with throwing around the yagni argument for things they don't want to support, build, or disagree with, often contorting or oversimplifying it to get their way.

The yagni argument itself is reasonable, but is often misused/abused.

Re: Monolith First (2015)

#15

Post by brodouevencode »

rwmj wrote: post #8
brodouevencode wrote: post #2

the problem with the yagni argument is is you aint gonna need it until you do

Unless you are actually a FAANG, you don't need them. And in the extremely unlikely case you become the next FAANG you'll have plenty of money to throw at the problem.

This is a gross oversimplification.

Re: Monolith First (2015)

#16

Post by kgeist »

Rickasaurus wrote: post #3

Recently was looking at a distributed microservice system at a company that thought they would need massive scale, but pivoted from d2c to enterprise b2b and then found out enterprise b2b companies want data separation. They would have been much better off going monolith first and probably actually sticking with a monolith.

You mean it's easier to shard databases per tenant when it's a monolith?

Re: Monolith First (2015)

#17

Post by loughnane »

> Almost all the successful microservice stories have started with a monolith that got too big and was broken up

The less certain you are about a system's requirements the more you should prefer a monolith.

A well-understood system (eg an internal combustion engine) has well-defined lines and so it _can_ make sense to put barriers in between components so that they can be tweaked/replaced/fixed without affecting the rest of the system. This gives you worthwhile, but modest overall performance improvements.

But if you draw the lines wrong you end up with inefficiencies that outweigh any benefit modularity could bring.

Start with a monolith and break it up as the system's ideal form reveals itself.

Re: Monolith First (2015)

#18

Post by delecti »

taeric wrote: post #6
brodouevencode wrote: post #2

the problem with the yagni argument is is you aint gonna need it until you do

I think there is a variant of "you don't currently need it" that people should follow more. Build towards what you think you will need, by all means. But try and only build what you need right now.

Yeah. There's a healthy middle ground between boxing yourself in and boxing yourself out. Don't write things before you need them, but if you can tweak an implementation slightly with knowledge of things you're thinking about adding later, that's often a good idea idea.

Re: Monolith First (2015)

#19

Post by brodouevencode »

curious_cat_163 wrote: post #14

Yes. It does require thinking about the monolith in a way so it can be broken up should the need arise. Going down the monolith path != Having spaghetti as the core abstraction. :)

There's the ideal path, then the actual. Most monoliths, unchecked and with enough age, turn into spaghetti due to turn over, changing priorities, entropy, etc.

Re: Monolith First (2015)

#20

Post by negus »

Alifatisk wrote: post #13
negus wrote: post #4

A monolith is just one microservice. Is there a choice to be made? "We love monoliths so much so we have dozens of them"

A monolith is not a single microservice.

Any arguments to support this claim? What's the difference then?

If there is three communicating servces: first has 90% of the business logic, second has 7%, and the last one has 3%. Should we call the first one a monolith? And if they don't communicate?

Post reply on HN