...with one caveat: How long has the system been in place?
We have services that were built and are in the background because they are effectively finished (for now.)
An example would be a service that handles a third party integration. It might get a commit a month once it's built.
From my limited perspective, I look at two warning signs: Do changes require changes to more than two services on a regular basis? Ideally, the majority of changes are limited to one service. If you're propagating changes up a stack, it is going to be a slow change. (The whole point of microservices is that once set up, you can move faster, right?)
Yes. IME, once a service is dialed in, it should need little maintenance. That's how my team was able to handle responsibility for 5+ services on top of our slowly carved up monolith.
If your microservice code is significantly harder to manage than your monolith, you've factored it wrong. Which means you shouldn't find yourself constantly working on 6 or 7 different services at once. If so, try a different decomposition.
Saying one team per service is like saying "a team should only handle one or two classes".
We have services that were built and are in the background because they are effectively finished (for now.)
An example would be a service that handles a third party integration. It might get a commit a month once it's built.
From my limited perspective, I look at two warning signs: Do changes require changes to more than two services on a regular basis? Ideally, the majority of changes are limited to one service. If you're propagating changes up a stack, it is going to be a slow change. (The whole point of microservices is that once set up, you can move faster, right?)