> I think you still want to use the same language, same serialization libraries, management practices, etc. across all of these services otherwise you are going to get eaten alive dealing with boring but essential problems.
Standard formats and protocols are probably more important than same languages and libraries for that particular issue; but, at the same time, not being tied to a particular language/library doesn't mean you should add them willy/nilly. It means that when a particularly component has a compelling reason to use a different language library, you aren't constrained to not do that (or you decide for a good reason to begin a major transition from one language to another, or one library to another, you can do it incrementally rather than in a big-bang transition or behind an additional adapter layer.)
Adding multiple languages is, by itself, a bad thing. If there is a good reason to add another language (like a lot of stuff already written) than the good outweighs the bad.
I hear so much crazy stuff about microservices like: we can have different teams making all the microservices and they don't need to share any people or talk to each other at all, etc.
Practically microservices contribute to real world agility not when they encourage silo-building, but when you can move developers from task to task as necessary. Perhaps Microservice A has reached stability and doesn't need to change much. The more standardization you have, the more you can move somebody who worked on A to work on microservice C, and the have somebody on B make a quick fix to A when the first guy is busy on C.
> I hear so much crazy stuff about microservices like: we can have different teams making all the microservices and they don't need to share any people or talk to each other at all, etc.
Minimizing coupling between components -- teams -- in the development process (as well as in the deployed systems) is a major benefit of SOA/microservices.
> Practically microservices contribute to real world agility not when they encourage silo-building, but when you can move developers from task to task as necessary.
Sure, being able to share staff in series is a benefit. Not needing to share resources in parallel is also a benefit. Silo building is harmful, because sharing best practices and tools that are a good fit for different teams tasks are a good thing.
Coupling that limits flexibility of one team to meet its requirements because of conflicts with another teams needs are bad. There's a big difference between enabling sharing (which is mostly a social/process thing) versus requiring sharing (because of poor architecture choices.)
That silo-building is sort of the logical extreme.
The happy medium is more like "because our services are loosely coupled, we're free to make code changes to our service and not worry about inadvertently breaking any other team's service as long as we keep our API stable." Which is a huge win over a monolithic system where everything is tightly coupled.
Standard formats and protocols are probably more important than same languages and libraries for that particular issue; but, at the same time, not being tied to a particular language/library doesn't mean you should add them willy/nilly. It means that when a particularly component has a compelling reason to use a different language library, you aren't constrained to not do that (or you decide for a good reason to begin a major transition from one language to another, or one library to another, you can do it incrementally rather than in a big-bang transition or behind an additional adapter layer.)