Running your system in smaller, independently deployable and isolated modules allows you to use whatever technology that can suite your problem the best for that particular business domain.
Since each service is self-contained, and the only way in which it can be communicated with is via the publicly-defined interface of the service, it means that pretty much whatever happens behind the public interface is the sole business of your service! So, in theory, you are free to use whatever technology that your tech-crazed heart desires!
Why would you want to do this?
There's a very (I think) over-used expression in the software world that says: "if all you have is a hammer, everything looks like a nail".
Sometimes you are using the incorrect tool for the job that you are trying to do. In a monolithic codebase, however, it can be difficult to change since you may find that you would need to change everything at once which would be too risky and time-consuming. Since microservices are small, you could experiment by changing the underlying technology for a portion of your system while leaving the remainder of the system unchanged. You can then test this thoroughly in your staging environment and determine whether or not it does better than the existing technology.
This is not necessarily just good for trying new technologies out and fixing a technical problem, but it can also help your business by expanding the pool of developers to hire from.
If, for example, your company does only Java for the backend, but good Java developers are difficult for your company to find and employ, and the company has seen that there are a lot of good Python developers in the market, then you could, again - in theory, now start to hire python developers!
The potential problems with this
Using new technology - whether that is a new framework, language, database - comes with more overheads than simply you, sitting at your computer and learning to use it.
There will be quirks with it, hidden gotcha's that will come out of the woodwork when you least expect it. The grass is not always greener on the other side of the fence. Are the risks worth the potential rewards?
What about other people learning the new tech? Are the other developers willing to put in the time and effort to become familiar with it?
How about maintenance? Many companies have DBA's that are familiar with the types of databases they use. Adding a new one to the company will require involvement from them too.
What about down-stream reporting? How will the new database fit into the existing business processes?
Adding new technology to your system will require some potentially big shifts in your organization in order to be successful!
It's good to have the option
Even if you never use a different technology for a particular service,
it's still really good to be able to if needed! Even if in the future the system becomes legacy and needs to be rewritten, at least it can now be done in isolated portions rather than a big bang approach often needed by large enterprise systems.
Top comments (8)
Honestly, if you have an autonomous work culture where teams do vastly different things to accomplish the goals of their delivery, why not? And if the project is smaller, has a rock solid technical path, then perhaps not the best choice.
Your example is a bit extreme but it is essentially right. Nobody should have to learn old code base components if they are just going to make a new thing, and perhaps utilize some api's to the old thing. Doesn't even have to be the same language, framework, whatever.
I suppose it's up to the culture and willingness of the people that work there to learn and apply themselves to maintaining such a solution. Traditionally I've found (in the ones I've worked for, at least) that companies tend to stubbornly stick to a particular stack. Introducing new technology is seen as an overhead (which it is!) since it will impair onboarding time for existing developers.
The example was more of an aside - an additional benefit to suggest that even if all the tech you use is the same, this could be another reason to go this route. I've seen a few corporate systems that got re-written because it was written in VB6 or some other legacy language/framework. Since it was a monolithic app, it has to be done all at once. This always takes far longer than scheduled with many mistakes, much stress, and panic from all stakeholders. My point is, at the very least, this allows you to rewrite a system, one service at a time - phasing it out slowly and steadily, rather than replacing everything at once.
Sure, it makes sense. Strang(edit: l)er vines pattern.
Strangler? Yeah
If there's only one person responsible for that solution and only they know how it works, then I would be worried too, at least from the company's perspective.
overused, but accurate 😂
Check the Enduro/X microservices framework.
For what reason in particular?