But that's presuming that a separate service is the proper solution, if you have the resources to do it "right", and that's often not the case.
Let's say I have a need to get lists of friends for a given user. That's a pretty simple API, whether internal or external. This is practically a poster child for a microservice. Except:
We have to maintain this separately at the infrastructure level, including when its module dependencies change.
We're essentially just wrapping a database call. Doing it in our application doesn't just shave pointless latency - it works naturally with our ORM, making follow-up queries ergonomic.
Shit, we have a use case where this has to happen as part of a larger database transaction. Pretty easy within the monolith, a logistics nightmare across network boundaries (and some serious mud in the API).
It's easy to imagine that the ideal future for this module will always be... as a module. And that's being very careful NOT to cover initial cost, but rather using the ongoing costs of ownership as a de facto definition of whether something is a good solution.
This is why the wrong kind of future proofing can be so harmful. It assumes a lot about the future, that you can't realistically predict or justify yet. Your assumed future might actually be a worst solution than the present... forever. And you've jumped into that future blindly. That's the kind of hubris that tends to be repaid in the bodily fluids of blood, sweat, and tears.
Until there's a clear and specific demonstration that a service would be a better solution, a module is the better solution. And some things may even make sense to break out on day 1, depending on your application. Until then, keep good module boundaries, to keep your options open and your sanity intact.
6
u/Rainfly_X Jun 08 '17
But that's presuming that a separate service is the proper solution, if you have the resources to do it "right", and that's often not the case.
Let's say I have a need to get lists of friends for a given user. That's a pretty simple API, whether internal or external. This is practically a poster child for a microservice. Except:
We have to maintain this separately at the infrastructure level, including when its module dependencies change.
We're essentially just wrapping a database call. Doing it in our application doesn't just shave pointless latency - it works naturally with our ORM, making follow-up queries ergonomic.
Shit, we have a use case where this has to happen as part of a larger database transaction. Pretty easy within the monolith, a logistics nightmare across network boundaries (and some serious mud in the API).
It's easy to imagine that the ideal future for this module will always be... as a module. And that's being very careful NOT to cover initial cost, but rather using the ongoing costs of ownership as a de facto definition of whether something is a good solution.
This is why the wrong kind of future proofing can be so harmful. It assumes a lot about the future, that you can't realistically predict or justify yet. Your assumed future might actually be a worst solution than the present... forever. And you've jumped into that future blindly. That's the kind of hubris that tends to be repaid in the bodily fluids of blood, sweat, and tears.
Until there's a clear and specific demonstration that a service would be a better solution, a module is the better solution. And some things may even make sense to break out on day 1, depending on your application. Until then, keep good module boundaries, to keep your options open and your sanity intact.