Printable View
Question: Should microservices be designed to be generic, or ver specific?
Got a case where I think some "requirements" were misinterpreted and some microservices were developed as some very generic services, and now it's causing some pain (at least for me). Personally I think they should have been built as specialized services, which would have made them lighter weight, more efficient, and easier to refactor to better support the app they were built for.
-tg
I would personally tend towards specific, the main point seems to be they are lightweight and do one thing well. The services should have a well defined method of communication (whatever that may be) so changes can easily be isolated, even down to replacing an entire microservice.
I find it hard to think of a more generic service as a microservice, the very nature of a generic service seems to entail a lot of abstraction, code, etc. that always seems to result in a very large, microservice.
To put it into context - we have a calendar microservice that's been built to be very generic - any app can use it ... but then that means when you create a calendar, you need to make sure it's your admin role person doing it (so they take ownership of it, because later only the owner can make changes to it, including adding events to it) but then also, you need to store the calendar ID somewhere so you can get to the calendar and its events... so you've effectively created a "magic" UUID that you now have to keep track of somehow.... grrrr.... It's not the way we would have done it, but there's a lot about this project that isn't the way we would have liked to have done it, but we're stuck with it.
-tg
I think that's a slight miss-use of generic/specific and might cause some confusion. If I create a service that returns the square root of a number I would argue that it is specific (it carries out a single, easily defined operation) but that wouldn't stop it being used by multiple applications. Indeed, the fact that it can be used by multiple applications is a good thing (you know, code re-use and all that). What would be a bad thing would be if different applications expected to get different results from it by calling it in slightly different ways, e.g. they expected different levels of rounding or a specific algorithm to be used.Quote:
we have a calendar microservice that's been built to be very generic - any app can use it
So, as I see it, microservices should be specific in that they should carry out a single isolated function, but it's desirable that they be reused wherever it's suitable to do so.