[bsder]

> Microservices, as a philosophy, is encoding your org design at the networking layer.

Not always. One of the things where I desperately wish people would adopt the "microservices philosophy" is in applications which provide a scripting language.

For example, if I want to "script" OpenOffice, I am stuck with the exact incarnation of Python shipped with OpenOffice. Nothing newer; nothing older; exactly binary compatible. This is a really irritating limitation.

If, however, they simply provided a "microservice interface" that anyone could talk to rather than just the anointed Python, then you could run your own Python or script using a completely different language.

I'm picking on OpenOffice here, but this is not specific to them. Nobody who has a "scripting extension language" as part of their application has demonstrated anything better.

[p_l]

That's how a lot of Windows stuff and MS Office stuff is built - as (D)COM components you can arbitrarily connect to from anything that can speak COM.

It's also how Windows Scripting Host operates (it also makes the language interpreters into COM objects, so you can extend the list of available languages yourself)

[remram]

What you're wishing for is usually called an API. It allows third-party applications to interface programmatically.