 |
| 10 myths about Micro-services, that we often hear to believe it is true. |
Microservices has become a very hot topic in the last half-decade. After Agile, DevOps, its Microservices that we hear where ever we go. The unfortunate thing that I witnessed though, is that, every organization and every person in that organization has their own definition of what a Microservice is. Just as the way, Agile and DevOps momentum are abused because of the cult status it achieved, Microservices too seem to have fallen in the same bandwagon.
This post is about recording the top myths that I often hear about Microservices and without much ado, they are:
- Microservices is SOA rebranded.
- Managing Microservices are easier than managing a Monolith.
- Embrace Microservices so you can avoid the hard XP practices (to hell with TDD).
- Micro-services are app developed using web-frameworks like Spring-boot, Dropwhizard, Micronaut, Quarkus, Koa, Express, Flask, Sinatra etc.
- More Microservices in your system implies better the System Architecture for its loose coupling, so look for ways to leverage Lambda services in the cloud.
- Microservices are small apps sharing a common DB.
- Microservices reduce complexity by having smaller code-base per microservice.
- Bigger code-base of a service implies ill-designed Microservice.
- Microservices Architecture greatly reduces system downtime.
- Microservices imply services can be deployed independently without having to wait for the entire system to be published.
- If scalable architecture then microservices. Or microservice is a silver bullet to scalable systems.
- Building microservices forces you to think about building your apps in a more modular way.
- Building a Monolith and building Microservices aren't different paradigms
- The smartest thing is to start building your systems the Microservice way from the very beginning.
- Microservices architecture greatly reduces the onboarding time of new team members to hit the ground running, because they don't have to learn the entire system.
As bonus, here are a few notable Anti-patterns in the implementation of Microservices architecture that tech leadership takes great pride in:
- Microservices architecture allows for leveraging different technology platforms by different teams. You can often hear say engineering leadership screaming with beaming pride, "We have microservices developed in Java, Ruby, PHP, Javascript, DotNet etc. with teams having independence to build systems in platform and tools of their choice". This in reality is abuse of leveraging emerging technology in the evolution of existing system, making a trade-off between tech and business deliverables.
- With Microservices architecture, we could do away with complex engineering practices like writing Unit Tests for CICD and be more productive. This is classic escapism from core engineering practices, for short-term gains thus catapulting tech-debts to dangerous levels.
- Microservices increases ownership in teams. This is another fallacy. What I witness repeatedly is orphaned microservices that every team fought to disown. An engineering leader comes, randomly re-organizes his teams, fires X% of engineers, promising magical returns to business only to face the wrath of his own making. Conway's Law states that structure of a system often reflects the structure of the organization that designed it. In my experience, I have seen this happen when engineering leadership works in silo, perhaps mimicking his counterparts. So a siloed organization leadership resulted in orphaned microservices, contributing to the increased business issues raised by its dissatisfied customers. Bingo, what goes around, comes around!
It took me a lot of conversations back and forth, up and down the organization hierarchy to reset the expectations and work my way to do the course corrections and see smiles on faces of people I work with. But until reaching that point of demonstrating results, it is sure sweltering as hell!