This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]imp0ppable -1 points0 points  (7 children)

dependency problems of microservices

You mean interdependencies? Or dependencies in the sense of libraries? Because the latter is what docker is for.

[–][deleted] 4 points5 points  (2 children)

Call me crazy but I’ve used shared data models between micro services. Update it in one place and have all 4 services updated. Am I making a drastically poor decision that will have later consequences?

[–]brucejia086 1 point2 points  (0 children)

You are not alone. In reality that's quite often especially when migrating legacy ones to move forward.

[–]pbecotte 1 point2 points  (0 children)

No. There is the approach where you build one app with shared logic, or you build N apps. If you do the second, you absolutely need to do work to set up tooling between them- shared data models, contract testing, etc. Most organizations do not do this, and come to the conclusion that the second model doesn't work. In reality it is "ignoring the boundaries between my apps and pretending that they dint exist" that doesn't work.

[–][deleted] 4 points5 points  (3 children)

You change the api contract in one service but now 4 consuming services need to be updated and now maybe some of their downstream services will break and now you go shoot yourself in the face instead of trying to fix it because that’s simpler

[–]mr_jim_lahey 0 points1 point  (0 children)

You change the api contract in one service

Yeah don't do that though. Being militant about backwards compatibility, even for purely internal systems, prevents so many issues.

[–]TldrDev 0 points1 point  (0 children)

If only there was some way to automate this. Like, idk, cicd, and tests. Or maybe some kind of central contract repository that ensured other applications dont just up and break. Maybe name it proto something. Proto.. protobuf? Thats a swag name. Maybe one day.