The point is that unless you use JVM hot reloading (not recommended in Production) you will need to take down your whole app to upgrade that JAR. Now what if your microservice was something minor like a black word filter. Is adding a swear word worthy of a potential outage ?

If you run multiple instances of your server and follow certain reasonable practices, you can take down old-version instances one by one and replace them with new-version instances, until you have upgraded the entire fleet.

Alternatively, you can deploy the new version to many machines, test it, then make your load balancer direct the new traffic to the new instances, until all old instances are idle, and then take down these.

And in microservices you can just pick whatever stack you feel is the best for just that task

Is hot reloading that big of a problem?

not for everyone

You certainly can do that. A little discussed benefit (or curse) of a microservice is maintaining an API (as opposed to ABI). Changes are slower and people put more thought into the interface as a discrete concern. I am curious if an ideal team would work better with a lib--I think so, but I'm not sure!

I think people don't maintain discipline if it isn't forced. So its a round about way of forcing people to maintain boundaries, that wouldn't be needed much of the time if people had stricter development practices.

Exactly. Every single monolithic application I've seen has a utilities package that has classes shared amongst components.

With micro services you could have different versions of those utilities in use which would not be possible in a monolithic app.

> With micro services you could have different versions of those utilities in use which would not be possible in a monolithic app.

You have no idea...:)