this post was submitted on 13 Sep 2023
17 points (100.0% liked)
Cloud
527 readers
1 users here now
This community was created to share news, hold discussions, insights, and knowledge sharing about cloud computing and different cloud services like AWS, Google Cloud, Azure, and many others.
Read our rules here
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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...