3 ms·
Seems like reality is settling in. I mean, it makes sense to me: a team should keep its code well-factored but in a single codebase that's integrated and ready
by EdSharkey 11y ago
Seems like reality is settling in.
I mean, it makes sense to me: a team should keep its code well-factored but in a single codebase that's integrated and ready to deploy (as one or more deployable units) for as long as is tolerable/possible.
I think a trigger for splitting a module off from a monolithic codebase would be when its value or resource utilization has become disparate enough from the rest that it deserves its own infrastructure and/or its own maintenance crew.
- artgon 11y agoThe deciding factor probably isn't technological but rather human. If you want to keep your teams to 5-10 people and you want to maintain autonomy for teams as you scale, you'll need to split up your monolith.
- EdSharkey 11y agoThat seems reasonable. I can think of many human/organizational/rule reasons that would force the breakup of a monolith representing many separate-but-related concerns.
- matwood 11y agoAs the other poster said, micro/mono is probably more of a company culture than technical issue. When a monolith gets so big that it takes large team to maintain it, it is probably time to start thinking about splitting. At that point it is close to impossible for any person on the team to reason about the entirety of the app, and it leads to very slow changes. Something that is also often missed is what does micro mean? To some people it means a service to getDate() to others it is an authentication service. I've likened splitting off micro services like an amoeba splits. A pieces gets bigger off on it's own and eventually splits off. In that respect I agree with Fowler that micro services should be emergent.