9 ms·
I enjoyed the article. As ever, there are tradeoffs and your milage will vary using different approaches. This doesn't seem like an entirely fair comparison:
by aidos 12y ago
I enjoyed the article. As ever, there are tradeoffs and your milage will vary using different approaches.
This doesn't seem like an entirely fair comparison:
"It seems to me that all three of these options are sub-optimal as opposed to writing the piece of code once and making it available throughout the monolithic application."
There's a different scenario that could have played out with how to share a library between different services. You could have written the bulk of your application in the same language, like a monolithic application but split into several services. In that case you could create a library for your tax calculations and use it freely within your services.
For me, I split my application into a small number of services and, as much as possible, split things out into libraries to make reuse simple (more libraries, thiner applications).
Sometimes I use different languages, but when I do, I consider very carefully whether the (rather large) tradeoff that presents will be worth it in the long run for what I'm getting in the short term.
A question: when people talk about microservices, how small are they talking?
- blatherard 12y agoThe OP addresses this as one of the three options: The final option is to share resources such as a tax calculating library between the services. This can be useful, but it won't always work in a polyglot environment and introduces coupling which may mean that services have to be released in parallel to maintain the implicit interface between them. This coupling essentially mitigates a lot of the benefits of Microservices approaches.
- aidos 12y agoI rambled a little - my point was that by avoiding te polyglot language situation you make things easier (and closer to the monolithic application). I take the other point though, parallel releases are harder.