[sameg14]

Yeah but then who is responsible for maintaining the library? If you have a bunch of internal teams that depend on your library and there is an issue or a feature request, you're back to the same position of being the one that does the work to implement. Better to have a service IMO, you can get telemetry out of it and scale it out or replace internals without having to worry about who will get affected.

[hamandcheese]

If you can maintain a stable service API, why can't you maintain a stable library API?

I don't see any inherent reason why it should be easier to change the behavior of a service rather than a library.

[TeMPOraL]

Because if you ship code to users (library), you lose control. You may want to change something, but your users will just tell you to go pound sand. Conversely, if you keep the implementation on your side (service), you get to control how things work and when things change, and your users don't have a say in this.

It's an ownership and control issue.

[bigstrat2003]

I don't see the issue here. If I release my_fancy_lib 2.0.0, and I have users who only ever want to stay on the last 1.x release, that's fine. It's no skin off my nose if users choose to stay on an old version forever.

[TeMPOraL]

Yeah, exactly. However, if you were to make it a service, those users would have to switch to 2.0.0 or stop using it, as 1.x no longer exists.

[15457345234]

Some people don't think like that when they write software. They view it as a knife, not a noose.

I prefer those people.

[TeMPOraL]

I'm writing from the perspective of the user (which may be a developer using your product in their product). I don't really care if you view software as a knife or as a noose, I don't want to be coerced by the threat of either.

[sidlls]

Many engineering organizations have "platform teams"--teams that have as their sole responsibility maintaining shared libraries and "core" services for the entire platform.

[marcosdumay]

As opposed to being responsible for maintaining and doing operational support of the service...

I still don't get what advantage exactly you are expecting.

Scaling it is only ever a problem for the service; you don't even have to think about it in a library. You can get telemetry from a library just as well as from a service; your users may find that a bit invasive, but it's still way less invasive than calling your service. And you can replace the internals of whatever, without having to worry about who will get affected, that's what defines internals.