I think this is a false dichotomy. Most places I've worked with microservices had 2 or 3 approved languages for this reason (and others) and exceptions could be made by leadership if a team could show they had no other options.
Microservices doesn't need to mean it's the wild west and every team can act without considering the larger org. There can and should be rules to keep a certain level of consistency across teams.
Not sure why you’re downvoted - but you’re right. We heavily use microservices but we have a well defined stack. Python/gunicorn/flask/mongodb with k8s. We run these on Kafka or rest api. We even runs jobs and corn jobs in k8s.
Functional decomp is left to different teams. But the libraries for logging, a&a, various utilities etc are common.
No microservices that don’t meet the stack unless they’re already developed/open source - eg open telemetry collectors.
Edit: I think the article is a path to a book written by the author. It’s more of an advertisement than an actual assessment. At least that’s my take on it.
> Most places I've worked with microservices had 2 or 3 approved languages for this reason (and others) and exceptions could be made by leadership if a team could show they had no other options.
This works well if you have knowledge redundancy in your organization, i.e., multiple teams that are experienced in each programming language. This way, if one or more developers experienced in language 'A' quit, you can easily replace them by rearranging developers from other teams.
In small companies, this flexibility of allowing multiple languages can result in a situation in which developers moving to other jobs or companies will leave a significant gap that can only be filled with recruiting (then onboarding), which takes much more time and will significantly impact the product development plan.
More often than not, the choice between Microservices and Monoliths is more of a business decision than a technical one to make.
> More often than not, the choice between Microservices and Monoliths is more of a business decision than a technical one to make.
I think that, technically you can use one or the other and make it work.
However management is very different in the two cases, so I completely agree with you. I hadn't thought of the part about moving people between teams.
It's my first job but I understand why they chose microservices : 6 teams working on 6 "features/apps" can be managed (almost) fully independently of each other if you split your code base.
I think it's fair to say microservices increase the need for governance, whether manual or automated systems. When you start having more than 1 thing, you create the "how do I keep things consistent and what level of consistency do I want" problem
Microservices doesn't need to mean it's the wild west and every team can act without considering the larger org. There can and should be rules to keep a certain level of consistency across teams.