> If code is kept organized, it can be split into microservices when/if the need arises.
You can still keep a client interface, but in the monolith impl you can just have it call code directly instead of transport data over a wire. Then, when/if you separate, the only code changes you need are the transport layer (not necessarily non-trivial, but it's just a single point of code that needs major overhaul).
I find usually when people say they are pro/against monolith/micro-services, they are using very overloaded terms.
When I hear "anti-microservice" my brain thinks "wow, this person is against code that separates concerns into their own logical buckets - they must love entangled messes of code that take months to make changes in" when usually they are thinking "I'm against severe premature optimization, and rolling out/maintaining orchestration for all 5 of my miniature services when I can really just build this out in a single repository that is able to maintain those concerns for me without duplicating work/effort."
Honestly we probably just shouldn't talk about being pro/against any of these patterns dogmatically, and really should talk about the specific issues present in each and when those are worthy trade-offs.
'When I hear "anti-microservice" my brain thinks "wow, this person is against code that separates concerns into their own logical buckets'
... Then you're not really listening.
Especially in this day and age of cheap machines capable of doing thousands of requests per second and hundreds of thousands of IOPS... almost nobody needs 'microservices'. Hell, I worked at Google and that's not how they solve scaling problems and their scale is bigger than yours... So why does the industry reach for this as a tool?
Microservices != separation of concerns or designing for modularity. It's actually a pretty terrible way of designing for that.
(Sometimes I feel like if I see another client-side join in my life, blatantly abusing and/or ignoring the presence of a relational database in the stack, I'm going to cut my fingers off with wire snips, throw out all my computers, and leave this industry forever.)
You can still keep a client interface, but in the monolith impl you can just have it call code directly instead of transport data over a wire. Then, when/if you separate, the only code changes you need are the transport layer (not necessarily non-trivial, but it's just a single point of code that needs major overhaul).
I find usually when people say they are pro/against monolith/micro-services, they are using very overloaded terms.
When I hear "anti-microservice" my brain thinks "wow, this person is against code that separates concerns into their own logical buckets - they must love entangled messes of code that take months to make changes in" when usually they are thinking "I'm against severe premature optimization, and rolling out/maintaining orchestration for all 5 of my miniature services when I can really just build this out in a single repository that is able to maintain those concerns for me without duplicating work/effort."
Honestly we probably just shouldn't talk about being pro/against any of these patterns dogmatically, and really should talk about the specific issues present in each and when those are worthy trade-offs.