4 ms·
I don't understand how Guava couples my services, could anyone explain me? Let's say I have service A that uses Guava v18, and service B that uses Guava v19. N
by deepsun 11y ago
I don't understand how Guava couples my services, could anyone explain me?
Let's say I have service A that uses Guava v18, and service B that uses Guava v19. Neither of them care what other one use, all they see is RPC (or HTTP) calls.
- hatchoo 11y agoI don't get it either. If I use Spring WS to provide the endpoints, how does it make it a monolith? It's always using the right tool for the right job but if one set of libraries are the right tools, why not use it across everything where appropriate.
- jupp0r 11y agoOne of the benefits of microservices are your ability to choose the right tools for each of them instead of a common denominator. I don't know about Spring WS, but if it makes harder for ie a Go microservice (or whatever makes sense for your domain) to talk to your service then I would consider it a liability.
- skybrian 11y agoThat assumes they were written independently. But if your services have a large heap of shared libraries in common, they all need to work together. Then when you upgrade Guava, there may be a lot of code to fix.
- deepsun 11y agoThank you. But if my services have a large heap of shared libraries in common, it's by definition a monolith. With Guava, or without. I shouldn't call it "microservices architecture" in the first place. What I always meant by "microservices" is whatever servers talking to each other by some kind of RPC, e.g. Protobuf in Google (HTTP+JSON works as well if you don't operate terabytes). Then it doesn't matter what Guava version, or even what programming language my services are written in, as long as they support RPC format (e.g. Protobuf). So I conclude that original post author does microservices wrong. Or just don't understand what he's talking about. Sad to see it on InfoQ.
- alcima 11y agoI think his point is that if ALL of your services have to use Guava (perhaps because you included some functionality that only Guava provides) then you have coupled your service to Guava. You can't use nodejs to build a service.
- Randgalt 11y agoI was the guy at Netflix that had the task of moving the Company from Guava 10 to Guava 11. Guava 11 was backward-incompatible with Guava 10. On the Platform team (produced libraries the entire company consumed) we could only move to Guava 11 if EVERYONE moved to Guava 11. The only alternative would have been to shade Guava 11 into the platform library which wasn't pleasant.
- BurningFrog 11y agoThat sounds like a real impractical way to run a platform team. Moving the entire company codebase at the same time may be possible with a dozen developers, but when you reach Netflix size it seems impossible. What am I missing?
- Randgalt 11y agoIt wasn't practical. But that's what we had at the time.
- hardwaresofton 11y agoJust to chime in here -- I think this is a relatively common happening. I've found that companies with lots of teams developing software often look to "standardize" the software being used to create things like web services/pieces of infrastructure. This often starts with creating a local nexus server (in java land), then is followed relatively quickly by creating a "X company commons" for "everyone" to use.
- BurningFrog 11y agoI see :) That kind of problem is tricky, since nobody decided to make it that way. A system worked great when it was instituted, and was never changed, but is now no longer good. Anyway, if/when I become Netflix CTO, I will make sure this is fixed!
- foota 11y agoWhat is shading a library?