Write libraries instead of services, where possible • Hacker News Board

Re: Write libraries instead of services, where possible

#131

Post by scubbo » Thu, Nov 23, 2023, 9:02 PM UTC

evntdrvn wrote: post #115

scubbo wrote: post #98

Earlier quoted context omitted.

> it’s not really feasible/easy unless you have a monorepo or otherwise extremely good build/integration tooling to deal with many repos[...] The issue is coordinating changes [...] across repos is often an utter nightmare with multiple PR/merge builds I'm coming up on a year out of $BIG_TECH_JOB (where the idea of a monorepo was horrifying) and transferred to $WAY_SMALLER_NON_TECH_COMPANY_WHO_USES_TECH_JOB (where th…

What I’ve heard from friends working at places where the monorepo model has worked well, is that it also involved a culture shift such that the burden of upgrading the consuming services is put on the shoulders of the _providers_ of the library, rather than the consumers. This implicitly brings along some benefits, like making the providers not cause excessive/unnecessary version churn and ensuring easy upgrade paths…

Wow, that is certainly a _huge_ culture shift. It certainly explains why it's not sitting right with me - while I do think that "providers not caus[ing] excessive/unnecessary version churn and ensuring easy upgrade paths" is a good thing in isolation, it seems like it would be massively outweighed by the downsides of forcing a library provider to maintain familiarity with all their consumers' codebases and business areas. Seems to me like that would make it impractical to make any changes to a library that is consumed by more than a few other teams - which runs totally contrary to the intention of extracting _commonly_-depended-upon logic. The ideal situation would be to create a library that is _so_ popular that maintaining that level of familiarity is literally impossible.

There are already incentives in place to ensure that a library provider is doing right by their consumers (building features that they want, making upgrades not too arduous), because if they make a hard-to-use library then people won't use it which should show up in however their team's success is judged. Seems to me that going the extra mile from "you have to provide a good desirable library" to "and you must also be familiar enough with your consumers' services to do the integration/upgrade work _for_ them" gives no new upside but all downside - service teams _already_ know their domain area, why should someone else have to?

(I recognize that you're just reporting what you've heard, I'm not arguing _with you_, I'm trying to reason out the arguments in my head to get them straight)

Really appreciate the insight, thank you!

Re: Write libraries instead of services, where possible

#132

Post by giancarlostoro » Thu, Nov 23, 2023, 9:11 PM UTC

capableweb wrote: post #130

giancarlostoro wrote: post #125

Earlier quoted context omitted.

Used to do this in .NET for personal projects then got pulled into various dotnet projects that had their own approaches. But it was really nice. What I had hoped to eventually achieve is being able to hotswap the library somehow so I can have a server with zero downtime for updates, but never found the time to do so. I would assume I would do it via a microservice type of architecture instead.

You can just do this with nginx or whatever you have in front (IIS if you're into Microsoft stuff I guess?). Run service at port xxx1, this is your "live" port. When you wanna upgrade, launch service to port xxx2, do graceful reload of config, swap the ports around so "live" port now points to right service, graceful reload of config again and done!

I should have added I was not doing a web service.

Re: Write libraries instead of services, where possible

#133

Post by Matthias247 » Thu, Nov 23, 2023, 9:23 PM UTC

I had the same opinion in the past. But after some more years of work experience - mostly in the managed services area - I don't think it's that clear anymore:

- If you offer your users a library, you are competing with tons of open source libraries which claim to offer the same thing. A lot of those will be incomplete, buggy or insecure. But most potential users will never know and try to get them work instead of looking at your offering.

- If you are offering a library, debugging and user support can at times be challenging. Do you expect user to look at the internals (source code) of your library? Provide core dumps?

- Having to support N different [major] versions of libraries can become challenging. It's hard to know when all users have upgraded. With a service, you can control the update schedule. Even though changes to public APIs of the service certainly are still problematic.

- Write a library - but in which language? You might prefer Rust, but your users might prefer Go, Java or Python. You could write the core in one language, and add wrappers in other languages, but some users will still be unhappy with it (e.g. because it makes compilation difficult, people don't want "unsafe C code" in their high level language project, or the wrapper might slow down performance).

- Libraries which are general-purpose and are not targetting a specific application/service can over time become feature bloated since things are added "just for the case that someone might need it". This makes them hard to maintain. And since there's no feedback/telemetry, it's also hard to say whether something can be safely removed.

Note that all of this doesn't mean "don't write libraries". Even if you write applications/services, its good to structure internal components into libraries. It's mostly about "what is preferrable to offer for users".

Re: Write libraries instead of services, where possible

#134

Post by swagmoney1606 » Thu, Nov 23, 2023, 9:50 PM UTC

capableweb wrote: post #130

giancarlostoro wrote: post #125

Earlier quoted context omitted.

Used to do this in .NET for personal projects then got pulled into various dotnet projects that had their own approaches. But it was really nice. What I had hoped to eventually achieve is being able to hotswap the library somehow so I can have a server with zero downtime for updates, but never found the time to do so. I would assume I would do it via a microservice type of architecture instead.

You can just do this with nginx or whatever you have in front (IIS if you're into Microsoft stuff I guess?). Run service at port xxx1, this is your "live" port. When you wanna upgrade, launch service to port xxx2, do graceful reload of config, swap the ports around so "live" port now points to right service, graceful reload of config again and done!

IIS makes me want to explode and then die

Re: Write libraries instead of services, where possible

#135

Post by LtWorf » Thu, Nov 23, 2023, 9:52 PM UTC

zja wrote: post #99

gjadi wrote: post #36

Earlier quoted context omitted.

> It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. How is that different with services? I don't develop services, but I can imagine that before breaking the services, you have to poll with your biggest customers and you don't break until they are ready to move to the new version. The alternative I can imagine is to keep providing the old se…

You have the same problem with services and libraries when you’re introducing a breaking change. With services you can make non-breaking changes like security patches on the server side, without needing to coordinate with a customer.

And with libraries you can't make breaking changes?

The fact that I don't need to recompile everything whenever libcurl or libssl has a security fix proves otherwise.

Re: Write libraries instead of services, where possible

#136

Post by LtWorf » Thu, Nov 23, 2023, 9:53 PM UTC

mooreds wrote: post #35

NBJack wrote: post #27

It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my per…

I thought the author addressed that point: "But this assumes that slow-to-upgrade users can have negative effects on everyone else. If one user can't have a negative impact on other users, then you don't care if some users are slow to upgrade; they're only hurting themselves." There's still the support issue, I agree. If a customer paid you money and they are on version n-10, they still expect support. > Plus, if the…

If your updates don't break every single time, your customers will be more likely to do them.

Re: Write libraries instead of services, where possible

#137

Post by bardsore » Thu, Nov 23, 2023, 10:06 PM UTC

citrin_ru wrote: post #40

hbn wrote: post #7

Is this really a common scenario where there's a choice between these 2 options that isn't obvious? I've never considered libraries and services to be two equal options of distributing functionality, and you just pick one of them. It's usually a function of practicality and monetization.

In my experience a new micro-service considered the default option for anything which could be done as a micro-service nowadays. Library API design is the lost art (almost). And the choose is not always obvious for non-technical reasons. Consider a following example: you have 3 micro-services X, Y, Z which need to interact with a platform G but this interaction requires non-trivial chunk of code. It can be done as a…

Worked a place where we switched from having a client library to making the other teams use our APIs directly themselves. Of course, we had to do the switch for them because they were too busy... Pretty much just copy-pasted the library code directly into their projects.

Re: Write libraries instead of services, where possible

#138

Post by catern » Thu, Nov 23, 2023, 10:41 PM UTC

rascul wrote: post #92

> By library, I mean any software that can be run by the user: shared objects, modules, servers, command line utilities, and others. By service, I mean any software which the user can't run on their own; anything which depends (usually through an API) on a service provider for its functionality. These seem to be odd definitions and they make the article hard to reason about.

Do you have better suggestions for what words/phrases to use to refer to these two categories?

Re: Write libraries instead of services, where possible

#139

Post by neonsunset » Thu, Nov 23, 2023, 10:45 PM UTC

giancarlostoro wrote: post #125

inetknght wrote: post #78

I've been writing services... as libraries first. Then just wrap the library in a very simple `main()`: ``` #include "servicelib.hpp" int main(int argc, char argv) { return servicelib{argc, argv}.run(); } ``` The library can be re-used in other apps or services. Then the whole damn library is unit-testable with any arguments you throw at it. Got an OS where argv may be null? You can unit test that. Got a user who dec…

Used to do this in .NET for personal projects then got pulled into various dotnet projects that had their own approaches. But it was really nice. What I had hoped to eventually achieve is being able to hotswap the library somehow so I can have a server with zero downtime for updates, but never found the time to do so. I would assume I would do it via a microservice type of architecture instead.

In .NET for plugin management there are unloadable assemblies so you can dynamically load and unload e.g. plugins at runtime. However, it requires care, has caveats and the industry generally gravitates to other techniques for zero-downtime and/or rolling deployments where the replicas (nodes) are at first drained, then shut down, and replaced one by one or in groups but never in a way where there are none to serve the requests.

Re: Write libraries instead of services, where possible

#140

Post by catern » Thu, Nov 23, 2023, 10:47 PM UTC

wqtz wrote: post #29

I don't get it. Can anyone kindly share where this practice can be applied to a commercial software? I am struggling to wrap my head around "how run by user" works where they are using a commercial software service.

Ultimately, it can't. Proprietary software has fundamental limitations that force proprietary software developers to choose technically inferior designs. It's why in the long run proprietary software is doomed.