Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write libraries instead of services, where possible

catern.com

Post reply on HN
Print view View original

121–130 of 181 posts

Re: Write libraries instead of services, where possible

#121

Post by __MatrixMan__ »

closeparen wrote: post #109
__MatrixMan__ wrote: post #68

Earlier quoted context omitted.

It's only an unreasonable amount of work if you assume that the user is managing a separate storage backend for each library. If you take the Tim Berners-Lee approach (re: https://solidproject.org/ ) then each user is only managing one storage backend: the one that stores their data. The marginal cost of hooking in one more library to the existing backend is low. We just have to get a little more fed up with all of t…

I think most interesting web services are providing structured access to the same data for multiple people. A private, individual data silo wouldn't get the job done unless combined with some kind of message-passing. A silo to which users can invite peers is interesting, but it's an important characteristic of many web services that the specific read and write transactions allowed are application-defined... you don't…

I think we just need smarter browsers which can be configured to know who we trust in which dimension.

If I want to leave a comment on an article and then delete it, I can publish the comment in my pod, and I can also publish the deletion. If you've got your browser in a mode where it's interested in my comments, it can pull in the data from my pod and render it in context with the article--whether or not the article's author cared to provide a comments section.

If you drop the idea that anyone is authoritative about how it all comes together on the viewer's screen, you can also dispense with the headaches of being that authority (e.g. services).

Re: Write libraries instead of services, where possible

#122

Post by crabbone »

closeparen wrote: post #6

Services usually depend on databases. Libraries usually don’t. Either you need to support every storage backend your users might have, require them to write an integration layer from your generic hooks, or expect them to provision and manage new storage when using your library. In any case you are asking them to do a lot more work (manage the data) and in some sense breaking encapsulation by making them responsible f…

The title of the article literally says "where possible". You found a case when it's not possible, and decided to argue against that...

No, not all services come connected with a database. Alternatively, often times a database is an artifact of tenancy and the need to manage users which would not be needed, had the functionality be exposed as a library.

More importantly, whether users realize this or not, a library is more beneficial for them than a service in majority of cases. Much in the same way how it's almost always better to own something than to rent it.

Just to give some examples of the above: all the Internet of crap stuff, all sorts of "smart" home nonsense which requires that you subscribe to a service, install an app on your phone and send all your private data unsupervised to some shady Joe Shmo who you know nothing about. To be more specific, take something like Google Nest thermostat. There's no reason this contraption should ever go on the Internet, nor should it require to know your street address, nor your email etc. In fact, the utility it brings is very marginal (saves you few steps you'd have to make to reach for the boiler's controls to program it). It absolutely could've been designed in such a way that it doesn't connect to the Internet, or, at least, to never leave the local area network, and yet it's a cloud service...

Re: Write libraries instead of services, where possible

#124

Post by Joel_Mckay »

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…

We usually wrap a set of valgrind debugged small test/demo programs that hammer a library to monitor for leaks etc.

However, ensuring thread safety can sometimes be a challenge. =)

Re: Write libraries instead of services, where possible

#125

Post by giancarlostoro »

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.

Re: Write libraries instead of services, where possible

#126

Post by eikenberry »

90% disagree.

At an enterprise scale shop the service model will always win as it will better match the organization structure and avoids the maintenance burden of having to keep a dozen or so libraries in sync. Enterprise shops never standardize solely on a single language as they are filled with exceptions and the new hotness.

Everyplace else I'd say it will vary but I agree with the general consensus that shooting for the model of a library that can be easily run as a service is your best approach.

Re: Write libraries instead of services, where possible

#127

Post by crabbone »

ben_jones wrote: post #46
Kinrany wrote: post #39

Earlier quoted context omitted.

This shows that we lack good abstractions over storage.

It’s more like data storage needs are not one size fits all so it’s better left to the user who best knows their storage needs.

Nah. It's not that. We lack a concept that can organize storage. Let me illustrate this.

So, until some years ago there was complete nonsense and anarchy in Linux networking management. That is until we got the "ip" program. There's still nonsense and anarchy, because the "ip" program doesn't cover everything, but it's on the right track to organize everything Linux knows about networking under one roof. So, vendors today, like, say, Melanox (i.e. NVidia) choose to interface with "ip" and work with that stack rather than invent their own interfaces.

When it's extendable in predictable and convenient ways, user will extend and enrich functionality.

Now, compare this to Linux storage... I want to scream and kill somebody every time I have to deal with any aspect of it because of how poorly mismanaged it is. There's no uniformity, plenty of standards where at most one is necessary, duplication upon duplication, layers... well, forget layers. Like, say, you wanted a RAID0, well, you have MD RAIDs, you have LVM RAIDs, you have ZFS RAIDs, you have multipassing with DM (is that a RAID, well sorta' depends on what you expected...) also, well, Ceph RDB are also kind of like RAIDs, DRBD can also sort of be like a RAID...

Do you maybe also want snapshots? How about encryption? -- Every solution will end up so particularly tailored to the needs of your organization that even an experienced admin in this very area your org is specializing will have no clue what's going on with your storage.

Needs can be studied, understood, catalogued, rolled into some sort of a hierarchy or some other structure amenable to management. We haven't solved this problem. But we have an even bigger one: no coordination and no desire to coordinate even within Linux core components, forget third-party vendors.

Re: Write libraries instead of services, where possible

#128

Post by throwbadubadu »

eikenberry wrote: post #126

90% disagree. At an enterprise scale shop the service model will always win as it will better match the organization structure and avoids the maintenance burden of having to keep a dozen or so libraries in sync. Enterprise shops never standardize solely on a single language as they are filled with exceptions and the new hotness. Everyplace else I'd say it will vary but I agree with the general consensus that shooting…

But you can add the generic all problem solving run a library as a service service wrapper around it and have both and be done forever?

Re: Write libraries instead of services, where possible

#129

Post by crabbone »

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.

Oh, absolutely. Service brings convenience to the backoffice and money! Libraries suck to support and hard to sell.

Of course users want libraries but vendors want services. There are plenty of examples where something could've been a library, if the vendor had user's interest at heart, but instead it's sold (or rather rented out) as a service.

Go to Amazon marketplace, for example. Virtually everything there is a product that should've been a library but is sold as a service...

Re: Write libraries instead of services, where possible

#130

Post by capableweb »

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.

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!
Post reply on HN