Yeah, it’s tricky. If a project is more complex than a single dev team can handle, then managers feel forced to makes decisions around complexity, because of that whole “software architecture resembles organization structure”.
But they obviously don’t understand the whole complexity ahead of the project start, so making nuanced decisions is not possible. They’d have to arbitrarily pick an architecture sizing in between.
And that makes it quite tempting to simply reach for the biggest hammer.
But they obviously don’t understand the whole complexity ahead of the project start, so making nuanced decisions is not possible. They’d have to arbitrarily pick an architecture sizing in between.
The single most important decision is external interfaces, and establish service level agreements with clients.
Once the external interface is set, managers have total control over what happens internally. If they choose to, they can repeatedly move back and forth peeling out and merging in microservices. That’s actually one of the main selling points of microservices: once an API gateway is in place, they are completely free to work independently on independent services and even their replacements.
Microservices are first and foremost an organizational tool.
Hmm, not sure, I fully understand your point.
Yes, having those API gateways in place gives you flexibility in organization, but they cost developer velocity and therefore also money.
So, if you won’t need the flexibility of those API gateways, then you shouldn’t build/maintain them. But that is obviously easier said thsn predicted, which is why misjudgements happen…
