[groaner]

It doesn't even take oodles of money from a SaaS platform to motivate turning a library into a service.

Even in in-house development, developers are often motivated to build services and have internal customers take dependencies on them so that they can expand influence and demonstrate ownership in a way that gets noticed by senior leadership and put them in line for promo. It also opens up the possibility for stakeholders to build their own little fiefdoms with access controls, intake processes, and a justifiable source of funding.

Can't do that with a library.

[thinkharderdev]

That seems like an overly cynical explanation. There are many reasons why you would want a service instead of a library:

1. Even if the service is just a CRUD API, then you can isolate the storage layer from external users. If you just a have a library then every application needs to be able to connect to the DB.

2. You can protect mission critical resources through rate-limiting in a way that is way harder with a library.

3. Even if those are not problems, if someone has a DB connection then there is nothing really stopping them from just going around your library entirely. So random service X gets popped by an attacker. Now they can execute arbitrary queries against your DB. With a service they are still constrained to the operations exposed through the API.

4. You have a lot more freedom to change internal implementation details for a service. Need to change your DB schema (or migrate between postgres and mysql) then you can hide that behind the service interface. If you have a library out there then you have limited control over when people take version updates and it is virtually impossible to synchronize the update across all consumer of said library.

[groaner]

You've just described requirements that belong to a service. Congratulations, you made the right (obvious) decision.

I'm talking about writing entire services that are just wrappers around ffmpeg, pdf2html, parquet-tools, Olson tzdata, or a 10-parameter logistic regression. No stateful behavior, storage, or authoritative source of truth involved. The worst case I've seen was a service that just enumerates a bunch of values of constants (that actually never change).

There may have been some future-proofing in mind at the time, but more likely it was a solution in search of a problem.

[thinkharderdev]

Fair enough, but that is why the question of service vs library is not really a question that has ONE answer. It depends on the use case.

But to push back (slightly) on your chosen examples. Dealing with binary codecs is actually something where it can make a lot of sense to wrap it in a service (even if you're just using the open source tools under the hood). It is a space that is notoriously prone to security vulnerabilities up to and including RCE vulns (https://www.cvedetails.com/vulnerability-list/vendor_id-3611...). So doing it in it's own sandbox can be a smart move. Maybe not a SaaS product per se but still something you might want to isolate as a service separated from your application server.