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

141–150 of 181 posts

Re: Write libraries instead of services, where possible

#141

Post by catern »

yawboakye wrote: post #93

> 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. this definition makes (open source) self-hosted services libraries too, and so i think it’s wrong and unusable. the distinc…

What do you suggest as an alternative way to express these concepts?

Colloquially, "library" and "service" have 95% of the correct connotations.

Re: Write libraries instead of services, where possible

#142

Post by actionfromafar »

crabbone wrote: post #116
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…

This is a completely broken model. You are wrong by pushing your changes on "slow to update" customers. Customers know when to update much better than you do. If you are trying to update before they want to, you are doing them a disservice. This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are eithe…

It can be that, but it doesn't have to be. It depends on the business model and it's quite orthogonal to library vs service.

Re: Write libraries instead of services, where possible

#143

Post by capableweb »

giancarlostoro wrote: post #132
capableweb wrote: post #130

Earlier quoted context omitted.

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.

So what kind of service were you doing? As far as I know, nginx and others can handle more things than just http.

Re: Write libraries instead of services, where possible

#144

Post by stefan_ »

crabbone wrote: post #116
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…

This is a completely broken model. You are wrong by pushing your changes on "slow to update" customers. Customers know when to update much better than you do. If you are trying to update before they want to, you are doing them a disservice. This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are eithe…

Unless they have a specific problem or missing feature, customers want to update never.

Re: Write libraries instead of services, where possible

#145

Post by fl0ki »

I also tend to advise people not to write so many services -- a generation of developers has entered the workforce thinking "cloud native microservices" are the only way to factor software of any kind -- but I also caution people not to make everything a library either. Libraries have maintenance costs that have to pay off overall, and I consistently see people underestimate those costs when first making a library.

Any library used by more than one project faces friction making almost any kind of changes, especially if the ideal form of the change breaks backwards compatibility even a little bit. Even if it's used by only one project (an unfortunate antipattern some teams fall into), it still introduces friction to individual changes, which is worse in some languages than others because even just testing against a WIP version of the library might be a whole tangle that everyone seems to reinvent "workspaces" to try to mitigate even a little.

I now urge people to keep closely related projects in a single repo with purely internal libraries, so you can make backwards incompatible changes because you fix them for all consumers within the same commit that made them. This is like a monorepo but only for closely related projects.

It cuts out a lot of the friction of updating shared code, so it's a good way to avoid tech debt and keep both the library and its users evolving. This was inspired by working in an actual monorepo for years, but avoiding the size of repo where you can no longer make every related change in the same commit.

When an internal library's API surface has proven to work well for several projects and for long enough to be considered stable, then it can be spun off as a standalone library, and whatever warts slowly form there are probably acceptable in return for the wider reuse.

Re: Write libraries instead of services, where possible

#146

Post by jbverschoor »

bilalq wrote: post #70
jbverschoor wrote: post #62

Earlier quoted context omitted.

sqlite is a library zeromq is a library That’s all the storage you need

No? If you have a horizontally scaled architecture or anything with multiple nodes, you can't just get away with "sqlite is a library".

Almost all software is multitenant / easily shardable in some way. Ans almost all software can easily run on a single machine.

Re: Write libraries instead of services, where possible

#147

Post by bilalq »

TeMPOraL wrote: post #87
bilalq wrote: post #70

Earlier quoted context omitted.

No? If you have a horizontally scaled architecture or anything with multiple nodes, you can't just get away with "sqlite is a library".

SQLite is more about letting you get away with not having a horizontally scaled architecture or anything with multiple nodes in the first place.

SQLite alone doesn't help you get away with any of that. If you already know that a single machine is enough for you, then sure, SQLite is a fine choice. Availability needs alone often force you to run multi-node setups.

Re: Write libraries instead of services, where possible

#148

Post by rascul »

catern wrote: post #138
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?

I guess service is actually fine. Calling everything a user can run a library is what messed me up. I don't know what a better term might be.

Re: Write libraries instead of services, where possible

#149

Post by jbverschoor »

bilalq wrote: post #147
TeMPOraL wrote: post #87

Earlier quoted context omitted.

SQLite is more about letting you get away with not having a horizontally scaled architecture or anything with multiple nodes in the first place.

SQLite alone doesn't help you get away with any of that. If you already know that a single machine is enough for you, then sure, SQLite is a fine choice. Availability needs alone often force you to run multi-node setups.

I'd argue that salesforce could run on sqlite (library)

Re: Write libraries instead of services, where possible

#150

Post by fl0ki »

LtWorf wrote: post #135
zja wrote: post #99

Earlier quoted context omitted.

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.

That's not a great example given OpenSSL versions are famously backwards-incompatible. Older versions get ABI-compatible security patches because people put in the time to backport all of them to every version still supported, in many cases by distro package maintainers. It's exactly the situation libraries should generally avoid, because there are maintainance costs for older versions of the library as well as migration costs for all of its users.

https://wiki.openssl.org/index.php/Versioning

Post reply on HN