It’s hard when you have N services that need a lockstep migration from v1 to v2 of the library. I tend to agree with much of this but it’s not a one size fits all thing.
Write libraries instead of services, where possible
41–50 of 181 posts
Re: Write libraries instead of services, where possible
#42"where possible" is a keyword here and easy to argue about. For example: * my logic requires a database * my logic should be isolated for compliance reasons * my logic accesses a service which is not available for everyone * my logic should be processed async and needs to store state, how do I make sure library owners have that environment * customers embedding my library are not upgrading it frequently, which leaves…
Hm, it feels like all of these except for number 2 and the last one can be solved by appropriate interfaces and documentation.
how about 1?
Imagine a scenario, your service is a low traffic, but service which embeds you as a library is a high traffic with many instances and always opens DB connection.
Why should you optimize your Database for high traffic use case, when your use case is really a low traffic?
And then repeat this for 10 other libraries and library owners. Everyone is optimizing for nothing.
make it even more difficult, 100 different types of services with different traffic patterns are embedding your library with different behaviours when it comes to managing DB connection state
Re: Write libraries instead of services, where possible
#43And write unix-style cli tools that can be piped to and from. Make them eat and spit something structured like JSON.
Re: Write libraries instead of services, where possible
#44It'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…
> 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…
Many changes are believed to be non-breaking and so you can be running only one version in prod. (Most of the changes believed to be non-breaking are non-breaking.)
With a library, you end up with many different minor or point versions running without control over it.
Re: Write libraries instead of services, where possible
#45Is 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.
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/
Re: Write libraries instead of services, where possible
#46Services 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…
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.
Re: Write libraries instead of services, where possible
#47"where possible" is a keyword here and easy to argue about. For example: * my logic requires a database * my logic should be isolated for compliance reasons * my logic accesses a service which is not available for everyone * my logic should be processed async and needs to store state, how do I make sure library owners have that environment * customers embedding my library are not upgrading it frequently, which leaves…
Hm, it feels like all of these except for number 2 and the last one can be solved by appropriate interfaces and documentation.
how about 3?
Scenario: your service is accessing a service which exposes PII data and you only process them.
Service which embeds your service enabled audit logs of network requests and made it visible to everyone in the company. You have created a risk unintentionally
Re: Write libraries instead of services, where possible
#48I think this sentiment is a partial cause of the trend towards self-hostable, downloadable software too. The customer has a cost when they operate a library instead of consume a service, no doubt. They also get more control (no surprise upgrades, availability is their responsibility) and assurances (no worries about the service suddenly being end of lifed).
When you use a library from an outside source, if you update that library, it might break your build. When you use an outside service, they might break your system at a time of their choosing.
Yes. And if an updated library breaks you, you can fix it easily by rolling back to the earlier version of the library. If an outside service breaks you, you're hosed until they fix the service or you rework your code to route around the breakage.
Re: Write libraries instead of services, where possible
#49And write unix-style cli tools that can be piped to and from. Make them eat and spit something structured like JSON.
Not as a primary interface. By all means provide a wrapper around the library that does that, for users to use on the command line, but there should be an underlying library for other programs to use.
Re: Write libraries instead of services, where possible
#50Is 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.
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.