Mixing technologies - Is it a good idea?
As any other architecture, Microservices can help in many ways. However, there are some risks and trade offs to think about.
One advantage we can read everywhere ([1] [2] [3]): We can create our service in any technology. Yay!
- “Service 1” will handle thousands of requests per second? Better use Node.js.
- “Service 2” will use a lot of IO? Better use JavaEE + Microprofile + Reactive.
- “Service 3” will work in batch? Better use Spring Batch.
- “Service 4” is not critical. Great, can test a brand new framework.
- ….
But.. is it a good approach? Is it really good to have many different technologies/frameworks/languages? Obvious answer: it depends.
Enterprise Companies?
Think about enterprise companies. How many different system does it have? How many different standards (security, architecture) your service must comply?
Forget about the whole company, think about your project. How many microservices will it have? How many BFF’s? What about MFE?
Yes, things can get messy. It will be very hard to meet your company requirements (or even your project) if everyone is using something different.
Requirements
Every enterprise company will demand some standards, no matter you are creating a microservice or a monolith. Think about common layers and activities, for example: authentication handling, collect analytics data, cryptography libraries and so on. Normally these requirements will have a existing, working, production ready library just to plug on your application.
Now we are getting in trouble. We can list at least the following problems:
Problem #1: I’m using node.js to create the new service, but the common libraries are written in Java! Should I rewrite all common libraries? What about project schedule? Everyone should reimplement those libraries?
Problem #2: Production support. How to give a proper support when each application is written in a different technology? Should you become a specialist in everything?
Problem #3: Monitoring. How will the OPS team monitor each application? Different stacks may behave differently and will be a headache for them.
It is highly recommended to watch a David Shmitz’s talk, where he mentions some tips for failing at microservices. It’s a funny talk where he elaborates about 10 tips you should follow if you want to fail.
Disclaimer: If you are luck enough to work at modern company (Netflix, Google, Amazon..) you might not have this kind of problem. However, in the real world with real enterprise companies, this happens quite a lot.
Small/Medium companies
Ok, you do not work at an enterprise company, but the same logic applies for small/medium sized companies. If most of the times these companies does not have all those enterprise requirements, on the other hand they usually does not have a big IT department. Probably a small team to do all the work (develop, deploy, monitor, fix issues, new features and so on).
Now imagine you and your team are responsible for all microservices, let’s say fifty. Which options would you prefer?
- A microservices environment where every team/developer choose a different technology, and now your company have many different mix of technologies.
- A microservices environment where all the technologies where carefully chosen, ending up with just little different setup
I choose number 2. Remember, You are not Facebook/Amazon/Netflix/Google. Think about the long term, is it going to get better or get messy? Is your company/team able to close all the gaps? Most of the times, the “technical debt” will just get higher and higher.
How to choose
In case you consider using a different stack, you should at least ask some questions:
- Why am I choosing this stack?
- Does this stack provides any advantage to my business?
- Does the operations team have the knowledge to monitor this technology?
- Will my team able to give proper support or you will be called every time?
I totally support the use of new tech, but I believe it can not be random choose. It is necessary to think, plan, analyse study before adding more complexity to your environment.