> Pass messages. Use json. I shouldn’t need your code to function. Just your API.

Yes, but there’s likely a lot of common code related to parsing those messages, interpreting them, calling out to other services etc. shared amongst all of them. That’s to be expected. The question is how that common code is structured if everything has to get updated at once if the common code changes.

▲

reactordev 6 hours ago | parent | next [-]

Common code that’s part of your standard library, sure. Just parse the json. Do NOT introduce some shared class library that “abstracts” that away. Instead use versioning of schemas like another commenter said. Use protobuf. Use Avro. Use JSON. Use Swagger. Use something other than POCO/POJO shared library that you have to redeploy all your services because you added a Boolean to the newsletter object.

▲

narnarpapadaddy 6 hours ago | parent [-]

So, depending on someone else’s shared library, rather than my own shared library, is the difference between a microservice and not a microservice?

▲

__abc 5 hours ago | parent [-]

This right here. WTF do you do when you need to upgrade your underlying runtime such as Python, Ruby, whatever ¯\_(ツ)_/¯ you gotta go service by service.

▲

reactordev 5 hours ago | parent | next [-]

If needs be. Or, you upgrade the mission critical ones and leave the rest for when you pick them up again. If your culture is “leave it better than when you found it” this is a non issue.

The best is when you use containers and build against the latest runtimes in your pipelines so as to catch these issues early and always have the most up to date patches. If a service hasn’t been updated or deployed in a long time, you can just run another build and it will pull latest of whatever.

▲

mjr00 5 hours ago | parent | prev [-]

The opposite situation of needing to upgrade your entire company's codebase all at once is much more painful. With services you can upgrade runtimes on an as-needed basis. In monoliths, runtime upgrades were massive projects that required a ton of coordination between teams and months or years of work.

	▲	__abc 4 hours ago \| parent [-]
		Fair point.

▲

c-fe 7 hours ago | parent | prev [-]

one way is by using schemas to communicate between them that are backwards compatible. eg with avro its quite nice

▲

gmueckl 7 hours ago | parent [-]

But the you're outsourcing the same shared code problem to a third party shared library. It fundamentally doesn't go away.

	▲	reactordev 5 hours ago \| parent [-]
		That 3rd party library rarely gets updated whereas Jon’s commit adds a field and now everyone has to update or the marshaling doesn’t work. Yes, there are scenarios where you have to deploy everything but when dealing with micro services, you should only be deploying the service you are changing. If updating a field in a domain affects everyone else, you have a distributed monolith and your architecture is questionable at best. The whole point is I can deploy my services without relying on yours, or touching yours, because it sounds like you might not know what you’re doing. That’s the beautiful effect of a good micro service architecture.