Hacker News Reader

Comment by msluyter | Hacker News Reader

"Another dangerous decision is to use a lib for reusing code. This is particularly bad if the lib contains domain logic."

Question about this: if we're to take the above to heart, doesn't that imply that we may implement some common functionality multiple times? It seems there's a real tension here between "code re-use" as a generally laudable goal and the need to avoid sychronization of testing/deployments.

I'm curious how others out there have dealt with this particular issue.

View on HN

In the end I think the idea of microservices as totally independent from each other is just a pipedream. There will always be dependencies between them. His solution to create more microservices for shared libs will create a whole other set of problems. In the end people just have to talk to each other and sometimes you just can't avoid that people have to synchronize their work.

I wrestle with this one all the time. A shared library creates a weak dependency between the systems that use the library. Making changes to that library may affect those other systems in unpredictable ways. In my opinion if you leave business and domain logic out of those libraries and have a well defined and tested service contract then it is reasonably safe to create shared libraries. I have found that maintaining backwards compatibility and using feature flags in these libraries goes a long way at making them relatively painless for the microservices that use them to deal with change. We also generally only use shared libraries for codifying best practices and conventions.

But really, it's a constant struggle. Micro-service teams are semi-autonomous and are going to recreate functionality at will. That's a communication problem mostly though.

I'm currently struggling with dealing with shared libraries at work. I think the challenge is that the whole concept of dev-ops is fairly new[1], and from my experience Java, .Net, Python, etc. weren't designed for easy management of versioned dependencies. You have tools like Maven, Nuget, and Pip that pop up because it's a real problem, but they're add-ons to the ecosystem rather than built-in at a foundational level. And more to the point, if you want to set up your own package server[2], it can be a huge effort to integrate it into your build process[3].

[1] Disclaimer: I've only been programming for ~10 years, and professionally for ~3 years

[2] Personally, I'm currently using Sonatype Nexus

[3] I'm currently grappling with trying to automate building a multi-targeted assembly .Net assembly, and the co-dependency between VS, msbuild, and Nuget gives me agita

I can speak best to pip, but versioned dependencies are a non-problem in Python because of it. Who cares if pip isn't baked into the standard library?

Versioned dependencies absolutely still are a problem, even with pip. You still need something like virtualenv to isolate dependencies for different projects. And virtualenv is a compete hack (granted, one that works; but still a hack)

What? Virtualenv is not a hack, and "problem" doesn't mean what you think it means if you think pip is a "problem".

You're barking up a tree that was cut down a few years ago.

pip ships with python now

If a library update requires all teams using the library to start using the new version simultaneously, then you're pretty tightly coupled. Not a good thing. But if different services can interoperate while running different versions of the library, then it's less challenging.

Combine that with a reasonable deprecation schedule on old versions of the library and let teams upgrade when they're ready.

Now you have the best of both worlds - a library that keeps moving forward with a known window (per the deprecation schedule) when they can completely drop old functionality, all while other teams are happily using the library.

Ofcourse, a number of things needed to pull this off:

* independent deployments so services don't automatically share the same library versions

* communication tools so library owners can publish a deprecation schedule and the right people are notified effectively

* verification mechanisms so library owners can make sure everybody has upgraded before pushing out breaking changes

Depends, the author suggests that one way to fix this is to extract the shared logic into a microservice of its own, but that may not be possible at all times.

I also think that functionally, there's a very small difference between a library with a public API and a microservice with a public API - the only main advantage is that microservices can be written in any language, but that may not be important for many businesses.

I think you should never "take it to heart", at least not in the meaning that you should follow advice slavically. It's just one more tradeoff you should be thinking of to avoid cargo culting.

> slavically

Nit, but you probably meant "slavishly" (even given that the author is Polish)

Usually the only thing that should be shared is base process bootstrap related code. So for example I've used a shared lib in a microservices environment which had common boilerplate code for starting a web server that connected to a database, and initializing a router.

The other microservices all included this shared library, and it benefited devs by providing them with an easy way to create a new microservice quickly without having to recreate a bunch of boilerplate. It also provided an easy way to centrally manage a few things like the version of express (the node.js web server we chose) and a few other things. By updating that central lib the rest of the microservices would all get upgraded automatically the next time we rebuilt them.

Reply on news.ycombinator.com