Monolith First (2015)
martinfowler.com
Monolith First (2015)
1–10 of 82 posts
Re: Monolith First (2015)
#2the problem with the yagni argument is is you aint gonna need it until you do
Re: Monolith First (2015)
#3Recently 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.
Re: Monolith First (2015)
#4A monolith is just one microservice. Is there a choice to be made?
"We love monoliths so much so we have dozens of them"
Re: Monolith First (2015)
#5the problem with the yagni argument is is you aint gonna need it until you do
[deleted]
Re: Monolith First (2015)
#6the 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.
Re: Monolith First (2015)
#7Yes strive to find one good language and use it everywhere. Then when greater languages like Rust come out you have a problem.
Re: Monolith First (2015)
#8the 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.
Re: Monolith First (2015)
#9Yes? but that really isn't the problem. You can do both monoliths and micro-services badly.
The real thing that makes software easy to maintain is consistency with itself.
If you have one guy that formats his code with spaces and another tabs, that creates friction in the codebase. If you have one guy that always uses `const` or `final`, but another guy that doesn't, again hard to maintain.
The hard problems are boundaries between business logic is divided. If the application is consistent in how it divides responsibilities, it'll be a pretty clean codebase and pretty easy to navigate and maintain. If you have two different rouge agents that disagree on coding styles and boundaries, you'll have a pretty difficult codebase to navigate.
The easiest codebases have consistent function signatures, architecture, calling conventions, formatting, style, etc and avoid "clever" code.
Re: Monolith First (2015)
#10A monolith is just one microservice. Is there a choice to be made? "We love monoliths so much so we have dozens of them"
[deleted]