Hacker News Reader

Comment by hbn | Hacker News Reader

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.

View on HN

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 library or as a new adapter micro-service A which will encapsulate knowledge about platform G and will interact with X, Y, Z the way it would be easier for X, Y, Z developers to integrate. Micro-service will add network latency but will allow to make/deploy all changes only to service A. With a library one would have to test and release a new version and then ask X, Y, Z maintainers to switch to this new version. In some organizations it will be a very slow process because X, Y, Z can put an update request (from the library team) at the bottom of the backlog. With a micro-service A teams X, Y, Z would have much less power to stop/slow development.

This is making technology objectively worse to solve people problems, and this only expands.

More software needs iron clad leadership and control. Any organization that lacks this can’t help but produce shit software. There has to be a single person with real decision making power than can force upgrades and prioritization of work, and they need to be able to axe people or teams who can’t hack it.

OK but most business compete in a market. And the people they employ are in a labour market.

It seems that worse is better.

What we see is just another manifestation of the current economic paradigm. Waste is winning.

Making too many pairs of jeans so we burn tons of perfectly good new pairs daily wins.

Throwing hundreds of engineers on problems bashing out hundreds of thousands of lines of code sending megabyte messages between dozens of service instances in multiple kubernetes clusters appear to be a winning move. Otherwise someone would beat them, right?

Most engineering orgs don’t understand or feel “the market” until mass layoffs. They exit their companies with beautiful resumes touting micro services and k8s.

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.

If you're distributing something publicly, it's fairly obvious which to pick, yeah.

It's less obvious for internal systems and architecture. For example, your company wants to add domain-specific auditing to all of your existing services. You could have every service add a library dependency that lets them just call `auditor.log(...)` and the library internally writes to storage. Or you could add an auditing service with a full HTTP/GRPC API. Or you could go halfway and build an auditing service but provide a library that acts as an interface.

There's no right answer for this IMO, all those approaches have pros and cons.

> Is this really a common scenario where there's a choice between these 2 options that isn't obvious?

In my experience, no, it isn't any common. But it is somewhat common for people to ignore the obvious option and go for services anyway.

This was a really common dilemma at Amazon. The prevailing wisdom was opposite to the advice in the article though. Unless you had an exceptional reason, your functionality and data should be exposed as service, not a library.

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...

Based on the fact that everyone seems to turn every desktop app into a service, yes?

Exactly. I've never run into a situation where there was even a choice.

Is it something that relies on a private database, queue, massive processing, dedicated hardware, shared state, something geographically distributed? It's a service out of necessity.

Or is it just a bundle of quickly executing code? Then it's obviously a library.

I've never seen anybody try to turn leftPad() into a service.

Fair to assume it’s a joke, but: http://left-pad.io/

I've seen plenty of engineers try to turn trivial functionality like that into a microservice "to avoid version upgrade hell" (quote from one person in a previous job), or bundle what should be a simple self-contained (i.e. no-dependencies) library of functions (i.e. an API) into a REST/gRPC interface service. Microservices fad-following is as bad as TDD in this industry.

Reply on news.ycombinator.com