The curse of microservices polyglotism
In the beginning there was a single language and common speech. It was easy for the developers to understand each other and to help each other when building a big application called “The monolith”.
And then someone said “Let there be microservices instead of this ugly monolith.” And it was so. They started writing services in different languages and technologies, and they didn’t understand each other anymore. So they were scattered all over the organization.
As silly as this may sound, language and persistence polyglotism, frequently portrayed as one of the main benefits when migrating to microservices, can turn your organization into a Babel tower.
If the only tool you have is a hammer…
It is obvious that not all programming languages are alike and, as time passes by, technology evolves and gives us better tools to tackle our problems.
Is trying to solve every problem with the a single technology an inefficient approach? It sounds like having a hammer as your only tool… well, you know how the saying goes.
The thing is, many times advantages from one language over the other are subtle. Is an application better than others because it was written using .NET Core instead of Python? Maybe, maybe not. Who’s to say? “Better” is a relative term, it will depend on the context. An optimal approach would be to use the best language that will solve the problem at hand.
You might be thinking, “wait, didn’t just said above that my micro-services strategy will turn into a Babel tower?”
It’s all about choices
We all know Uncle Ben’s quote. Having small and independent services, with the ability to work in the best-fitted technology, for the need they want to tackle (among other things, of course) is powerful.
But the best tool for the problem might not be the best for the team, or the organization.
In “Continuous API Management. Making the Right Decisions in an Evolving Landscape” the authors define how a governance effort can be taken, and make a great distinction over centralized and decentralized decisions.
“Bad governance (like bad design) makes life harder.”
— Continuous API Management
In the end, it’s all about choices. What choices? It depends on your governance strategy. If as an architect (or any position defining technology strategy) you don’t make them, the team will end up choosing for you, for good or bad, explicitly or implicitly.
It might sound like some sort of authoritarian old guy trying to micro-manage all the team members, but it is not the case. You need to be able to help your teams to make better decisions.
Life is a risk
It is clear that a big part of being on business is a risk, and that not all risks are alike. Each decision carries a risk, and Jeff Bezos classification for decisions can be useful here:
- Type 1: Can’t be reversed and, as such, require great care.
- Type 2: Easily reversed.
Depending on the level of risk your organization can handle, you’ll need to govern more or less of each decision type.
The Ariane 5 was a rocket “capable of hurling a pair of three-ton satellites into orbit with each launch”, built by the European Space Agency at a cost of $7B and 10 years of work. It exploded less than a minute after its launch on June 4, 1996, with a cargo valued on $50M, due to an overflow error: the program tried to store a 64-bit floating point number into a 16-bit integer variable, causing multiple problems that lead to its self destruction. But hidden behind this software bug lays a design problem. It seems someone decided (among other things) that reusing a piece of code from Ariane 4, without proper review or test, was a good idea.
Hey, but this is rocket science! Weren’t we talking about microservices?
Sure, but my point here is that you need to be able to detect the potential impact of your (or your teams’) choices, and plan accordingly. Deciding if your code will run on a 16-, 32- or 64-bit platform, or if you can reuse an existing component, or if you go live with simulations instead of tests might represent a bigger risk impact than select naming conventions for your variable names.
It’s not either chaos or peace
Your choices matter. Most of us don’t need to think about potential explosions or risks at that scale, but there are other issues that we need to think of:
- Will the selected tool carry a legal risk?
- Is my IT team confortable handling multiple platforms which in turn might represent a bigger attack surface?
- Will members be able to switch teams if needed?
- Is total cost of ownership acceptable?
A dictatorial approach could prevent all this, but it will surely deter innovation and become a bottleneck.
If only there was a better way.
Divide and decide
In “Continuous API Management” authors divide decisions into 6 different elements:
- Choice Generation
Based on this approach, you can define which of these decision elements need to be centralized or can be delegated. For example, you can come up with a list of “approved choices” that a team can pick from. They have the “freedom” to select whatever they think is the best and you are “comfortable” with whatever the choice is, because you already pre-selected it. Your team even might be able to challenge your list, and then you can either accept or reject that challenge.
Or you can let your team to freely define their choices, but have a central authority to decide if approve them or not.
In the end, there needs to be some alignment among all your team members (not just programmers); else they will end, as in Babel Tower story, not able to communicate each other.
Polyglotism is neither good nor bad, but choices make it so.
There is no right answer; you need to assess the ability of your teams to make choices, define what can be centralized or distributed, and assess the potential risks that your organization can live with. A rocket explosion, a data breach or a lawsuit can’t be reversed, a slow service can