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.


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! 🍨

Written by

Simon Lasselsberger

Founder Lasssim, Software Architecture and Development Expert

Privacy Policy

Written by

Simon Lasselsberger

Founder Lasssim, Software Architecture and Development Expert

Over the past ten years, I’ve worked with small startups as well as global companies like adidas, helped them implement their business ideas by creating technical plans and by guiding their development teams through projects. The proudest I am about the success we had with Runtastic. They got acquired by adidas in 2015 for €220 million.

Contact me anytime!

Software Architecture and Development Expert

Get the FREE
Software Architecture Diagram Checklist!

Boost your diagramming skills with this checklist.

Enter your email to receive the checklist directly to your inbox and join my newsletter.

Preview Image