Comment by cogman10 | Hacker News Reader

Comment by cogman10 | Hacker News Reader

Parent Full thread

Having worked with shared library systems, yeah micro or even macro services are far and away more preferable to deal with.

At very least, having clear boundaries on data ownership is something I really wish my company had done from the start. We have legacy structures that are very hard to iterate on because they get loaded by ~20 different applications directly from the database. That means any minor change to that structure requires careful planning and roll out of the shared library to these 20 services.

Were these behind a service, we'd still have to negotiate the structure (we could, for example, delete a field willy nilly) but we'd be able to add new fields to the structure or change the way those fields are populated to meet current business requirements without a mass rollout.

I do think the micro/nano approach can often be wrong. I think a service should be as big as it should be to cover the domain it's dealing with. But, importantly, who owns what bit of information is by large the most important thing to get right.

I think there is also a category of shared library like a color library. It could be a micro service but also could be a library. Since it is easy to have services upgrade to the newest version of it without having cross dependencies that may make more sense as a library.

I see what you are getting at though.

I think we are definitely in agreement.

It can be hard to determine when something should be a service or library and I don't know if I have a clear answer either.

We also have, for example, libraries that purely compute data. However, they have to be consistent across the system and it would actually be pretty helpful if they were a microservice instead as the computations often need to be changed or updated.

Perhaps when it's business logic it should be a service?

I definitely see the need for libraries like compression, IO help, or even just pure math like doing matrix multiplication where older ways to compute aren't necessarily incorrect.

I think the parent was saying that services should own their own mutable data. Libraries should not be used to "share" mutable data.

At least that's what I believe, so that's how I read it.

Definitely what I'm saying. But the point about libraries which don't own data is also valid and those can be useful as services in some cases. Particularly when we are talking about something like a set of business rules to follow.

At a bare minimum, if there's some sort of mutable data involved then I think there should be a single service that owns it. But I could also see reasons to create services which don't involve mutable data.

It does somewhat come down to complexity though. Like, for example, I think a "matrix multiplier" service would be silly. Or even just a general "do-math" service. But a service that, for example, takes in raw video and spits out compressed video? Now we are talking about something that probably is better as a service and not a library as you likely want to do things like control encoding values and standards system wide.

Just a little about my background. The systems I worked on, for example, shared user information using the `user-lib` library which contained all the details of how to fetch (and insert, and update) a user from the users table. Many services used that library to pull user information which has been a mess to untangle.

Reply on news.ycombinator.com