Why You Should Think Twice Before Even Considering Polyglot Microservices

Last Update: 22.07.2017. By Jens in Developers Life | Learning

Microservices can be a good solution for a particular problem. But, sometimes they are not a good fit. One of the aspects involved is that developers praise the benefit that you can develop every service in your landscape in a perfectly fitting tech stack for a given problem. Honestly, this can become your worst nightmare, so I will cover why you should think twice about this before going that route.

The idea behind polyglot microservices is to let a team which is responsible for a certain set of services decide which tech stack they are going to use to solve the problems. At first, this sounds fine. The devs can work in their favorite stack, get more autonomy and eventually become more motivated. Although I think it has some real drawbacks for you especially if you are not Google, Apple or any other of the big players.

Say, we have three teams with four developers on each team. Also, for simplicity, each team is maintaining roughly four microservices.

Team One is going with Java and Spring Boot for all services.

Team Two is using Python and Node. They also maintain UIs with Angular and React.

Team Three is more adventurous and uses Go, Kotlin, and even a test with Swift.

I’ll skip framework deviations here before it gets too complicated.

Problem 1

What might happen in a typical dev environment is, that positions in a team are not fixed, meaning when there’s less work for a team, it shifts helping out in other teams.

How do you think it will work out if one has to help out with another team? Maybe a team working in a tech stack the developer doesn’t even know? Or doesn’t like or whatever. It’s still common around Java guys that they have a problem with dynamic languages like Python and especially hate Javascript.

Now imagine what could happen when the Java guys must help out Team Two? Sounds like fun explaining to the managers why you can’t do that… and they have to wait till Team Two can solve it alone.

However, the same problem can happen in a single team. Take Team Three for example. With four devs and three tech stacks, chances are high that one service can only be maintained by a single person. And when this dev is sick, on vacation, etc the rest of the team just hopes and prays that nothing will happen or needs to be changed with this particular service.

This is already a huge problem in a team working in one tech stack and domain know-how isn’t spread evenly across the team. It’s not that uncommon as you might think. I’ve worked numerous times in teams with these problems even without running microservices. It’s no fun when a service crashes and the guy typically maintaining it is on vacation, the docs suck…

Sure, you can fix that with good documentation, checklists, and regular knowledge transfers.

Honestly, how often did you see that?

Problem 2

The next problem in these scenarios is when one or two members of a team leave the company and you have to find a replacement.

For Team One you’ll probably find enough Java devs and still enough with Spring knowledge.

You still find devs for Team Two but it might get harder in this combination. How many Python devs do code in Node too and vice versa?

Good luck for Team Three.

You will not find a single developer having production experience with exact these stacks. You might even have problems to find one for at least one stack. One, who’s also in budget.

If you are Google, Apple, etc., you’ll probably have no problem at all finding and paying someone. But there’s a huge chance that you are not working there and it can essentially hurt your company.

Conclusion

At first polyglot microservices sound great and like a dream for developers. However, on a closer look, it seems not to be such a good idea for your company and possibly you. Maybe you are part of Team One and are now forced to work with Javascript which you absolutely hate. Eventually, you motivation drops and you look for the exit.

Maybe you are the manager of these guys and are now seeking a replacement.

When you are not Google and alike, think twice about going this route. It might make your life worse. Rather stay in the safe field and go with a single tech stack or at least with common combinations of tech stacks, so you will find more easily a developer for it.

What’s your experience or take on it?