[pavlov]

Libraries offer tight integration with the language. A generic service that provides a HTTP API doesn't.

If you are currently using a library that operates synchronously on in-memory objects and offers an idiomatic API in the language of your choice, switching to a web service may feel like a bucket of cold water because suddenly you're dealing with an async-only interface that sits behind a slow socket and requires serializing everything to a lowest common denominator API. It's a huge tradeoff that requires serious justification.

Back in 1990, there was an industry standard called CORBA that attempted to turn libraries into services: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

There's a reason why we're not using any CORBA-based software. (Well, the GNOME desktop was based on it for some time, but they gave up eventually.)

[mcless]

During the time I worked for Amazon, the entire Amazon infrastructure was written as services. It indeed felt like a bucket of cold water in my first month at Amazon, especially after having worked in software products company for 10 years prior to that.

But gradually, I got used to the services based architecture, where something as simple as presenting a login page would lead to dozens of REST API calls back and forth between various backend services.

I am not saying that one approach is better than another. I would have to dedicate a separate comment to discuss that. All I am saying is that developing an entire software system composed purely of generic services with HTTP based REST APIs indeed exist and are very successful in very successful companies.

[pavlov]

Absolutely. At Amazon's scale, the justification is there. Things are different for invididual developers and small teams where the mesh of services will be maintained by the same people anyway.