Notice:
This post is older than 5 years – the content might be outdated.
Some years ago, microservices appeared as a new architectural pattern for larger software systems. Instead of creating a big monolithic application, there are several smaller (or more precise micro, whatever that exactly means) services communicating with each other. Each microservice covers a certain well-defined business capability. This way you are forced to think more about your business domain and how to model it. You also get some other advantages, e.g. independent deployments.
IT is ever-evolving. New technologies, programming languages and tools are created on a regular basis. Not sticking to one programming language but using the best one for the particular problem at hand is called polyglot programming. With the rise of microservices, applying polyglot programming has never been easier. But what means best one? And how do you handle this new freedom within your team, while staying productive in your outcome?
What to Look out for
In an average team of software developers, you will most likely find various kinds of developers. There will be differences in experience and preferred programming languages. Which programming language skills do the team members have? How comfortable, able and willing are they in learning new languages? Are there team members refusing to use a certain programming language for whatever reason? The approaches to tackle a certain problem when building software systems will also differ.
So before everyone is doing their own thing, it may be best to find common ground on how to apply polyglot programming on your project. The result may range from use language X unless you have strong arguments against to you are free to use the language that fits best, no matter what. There is also the question of how bleeding edge the language can be. Answers may range from more conservative approaches like using settled and widely-used programming languages, to more progressive ones like also choosing new programming languages whose future is more than uncertain, but which offer other advantages such as ease of use or performance.
Choosing a programming language is therefore influenced by the amount of risk you are willing to take. You might choose a programming language that will be abandoned by its maintainers one day, leaving you practically with the task of rewriting your microservice in order to make it futureproof. And speaking of risk management—be sure you have the support and understanding of your management in what you are up to.
Once doesn’t Count
In a fast changing business like IT, finding an agreement once is often not enough. As your software system changes, technologies evolve and new ones emerge. Your team evolves, too, in skills and experience but also in its composition as team members come and go. And with them come and go preferences, skills and knowledge. So in order to keep your microservices in shape and your team happy, you may reconsider those decisions on a regular basis. There are too many things changing over time, so you must not stick to decisions made long time ago.
A Real Life Story of Polyglott Microservices
In my current project, we started from scratch about 4 years ago using Java and Clojure as our main languages, with a slight emphasis on the former. All team members knew Java pretty well and most of the team knew Clojure or were willing to learn it. Over time there were people joining and leaving the team steadily. At this stage you could already see that Java was accepted by everyone but Clojure was (exaggerating) either loved or hated.
About 2 years ago, there was a new cool kid in town, named Kotlin. We agreed to try it for a new service and we were all positive about the outcome. So not long after, we decided to consider Kotlin as an option. Over time it became the primary choice of programming language. Using the same frameworks on top (Spring Boot), it was a relatively easy path to go.
The destiny of Clojure is different story. More and more people on the team were felt uneasy with its syntax and ecosystem. We had to deal with some issues with the libraries we had used: Some had their quirks, others had bugs that were not getting fixed in time. We decided not to use Clojure for new services any longer. Lately, we also had discussions about rewriting services in order to get rid of it, so we wouldn’t have to keep them up-to-date.
Meanwhile serverless computing became more popular, which we also adopted to a certain amount by using AWS Lambda. Serverless computing makes it even easier to experiment with new programming languages, as there is less code to write or rather to rewrite.
Summary
So all in all, there is no one-size-fits-all solution or silver bullet. Examine where you are standing now and start from there by inspecting and adapting in an agile manner. There are many variables to consider in order to find a spot that fits you well. With time as an additional variable, this target spot is moving. So you have to ensure to continuously adapt to recent developments.
