3 ms·
Not a silver bullet; you increase api versioning overhead between services for example.
by theptip 2y ago
Not a silver bullet; you increase api versioning overhead between services for example.
- whateveracct 2y agoTrue but your API won't be changing that rapidly especially in a backwards-incompatible way.
- dhfuuvyvtt 2y agoWhat's that got to do with microservices? Edit, because you can avoid those things in a monolith.
- whateveracct 2y agoYou avoid a lot of things in a monolith. But normal services mapped to your org chart tend to be pretty nice. I hate how people spam "micro" service talk as if that's the end game for putting a physical boundary between software.
- theptip 2y agoThe more/smaller microservices you have, the more frequently your APIs must change. It’s more fruitful to recognize that this is a dimension of freedom rather than a binary decision.
- whateveracct 2y agoI mean I recommend that you don't go micro right away. But a few well-placed service boundaries that align with your eng org chart pay dividends and help build discipline and rigor. Even if the services are all running on the same box to start and just IPCing over localhost or w/e. I prefer my teams build habits while it's easy and fun rather than once the monolith gets unwieldy and drawing boundaries becomes painful.
- motorest 2y ago> Not a silver bullet; you increase api versioning overhead between services for example. That's actually a good thing. That ensures clients remain backwards compatible in case of a rollback. The only people who don't notice the need for API versionin are those who are oblivious to the outages they create.
- theptip 2y agoThe comparison is with a monolith where versioning isn’t required at all, since you can refactor all clients atomically in one change.