Should I use different programming languages in my microservices?

Hi, I’m Simon. I help companies to design scalable and easy to change software systems that fit their needs and capabilities.

Currently I am on holiday but software architecture is everywhere. Did you know that ice cream offers a great way to explain the most common decisions about software architecture? One can solve anything with ice cream 😉

Let’s start with today’s question: Should I use different programming languages in my microservices?

Whenever I talk to teams and decision-makers about software architectures, we also discuss if microservices are a good fit almost every time. This is fine. And almost always, somebody emphasizes this argument: Microservices allow teams to choose which programming language to use freely.

While this is theoretically true and great, I believe this is a common misconception about microservices architectures in practice.

With every new language, you will roughly double the effort to maintain toolchains, sacrifice the possibility of reuse code, and lose standardization. These are essential aspects of a healthy development process that allows you to move fast.

Small teams

Let’s say you host a kid’s party and serve ice cream. It is way easier and faster to hand out chocolate ice cream to every kid than to let them choose. If you let them choose the flavor, things will quickly be out of control, and you won’t be able to scale well. There will also be a lot of leftovers if you offer multiple flavors.

Letting software teams choose the languages and frameworks independently brings the cost of maintaining different development stacks, from editor configurations over dependency management to deployment. These costs are high and don’t directly contribute to any business value because they address internal processes.

We must enable development teams to move fast. To achieve that, they must be allowed to make independent decisions. But there are constraints that I believe actually make their lives even easier because they limit their options and will enable them to benefit from shared code. Locking down the options on programming languages and frameworks is such a constraint.

Huge teams

Let’s say you are hosting huge kid events where more than just a handful of kids will participate. In that case, you might decide to offer more than just chocolate ice cream. But you separate the flavors by giving them out on different booths by different adults. That way, you will be able to scale better and keep control over the process.

My point is that you need to take care of your development stack (the booths serving ice cream). The fewer booths you need, the better. But there might be reasons at some point to use more than one language, but you shouldn’t take this decision lightly, and you should avoid it as long as possible.

Take a look at Google, for example. They have more than 20k developers and use eight different programming languages for their web applications. Even if these numbers might not be very accurate, they likely have more than 2k developers per flavor. They can spare a certain percentage of developers to maintain and support multiple languages.

Conclusion

As a software architect, I’m very well aware that the individual situation of teams and projects could justify multiple languages. But I mostly advise against it because most projects are not that special or huge to really require or benefit from multiple flavors.

Make a conscious decision; multiple languages are costly, and sticking with one might be more than good enough.

Enjoy! 🍨