Yep, this has been my experience as well. When micro services work well they have a simple and well-defined API that is easy to keep backwards compatible as it evolves, and it tends to be something that evolves quite slowly compared to the primary application codebase.

For the posters who said "like a library," yeah that's exactly the idea, but consider if you have an operation that can be done by a library but that has very different scaling characteristics compared to the rest of your system. Eg. you have one highly compute intensive operation while the rest of your system is IO bound. If you can split these apart it's easier to deal with scaling.

So basically a library? :)

It's like a library that you can call regardless of language ecosystem.

I joined a company that had a large, old, and mature selection of services written in PHP. If I'd tried to rewrite that mature code in a different language I probably would have wasted a lot of time for little benefit. If I'd had to write new code in PHP just to access old code as libraries that would have been a problem too. But functionality was exposed over HTTP APIs that could be used from any language, any runtime.

Well you don't want to call a processor intensive task with a library. A separate service for these types of tasks is a better architecture.

Although I'm not sure whether or not a task queue architecture with separate server workers executing code passed over from a central monolithic app server is still considered a "microservice" architecture.

Closer to command line tools in systems where you can just pipe output around in to whatever you want.

well a library + deploying it into its own space so that it doesn't bring down your main app due to compute time.

The operational part of microservices can end up being pretty important in these cases

HTTP-as-an-ABI

Sounds like a candidate for serverless.