We are in 2022, where Microservices are the norm. Most companies are either already on microservices or migrating to microservices or at least planning to do it at the least.
Microservices seem to be a solution for all the past Technology and Agility problems. Is this really true? Are there any cons to this approach and if yes, how do you manage them? This is what I will be exploring in this blog post.
Why Microservices?
Microservices have several advantages as have been outlined in numerous articles.
Listing some of the prominent ones:
Technical Rationale
- Scale – Independent scaling of microservices as per traffic patterns.
- Choice – Choice of technology suitable to the microservice and flexibility for regular upgrades.
- Abstraction & Contracts – Bounded context leading to data and business logic abstraction.
Team Rationale
- Ownership – Aligning squads to ownership of microservices
- Scaling teams – Fewer tight dependencies between teams lead to higher development parallelization and improved developer productivity.
Can the Quest for Microservices Lead Us to Nanoservices?
In the quest to move to microservices and to make use of the above advantages, it is possible that you end up creating nano-services.
What’s the problem with nano-services? At a high level, there is always a balance that has to be found. Beyond a certain point of decomposition, the ROI may flatten out or actually decrease.
Every microservice will need the following to be setup:
- Dependent services need to handle resiliency
- Deployment sequencing
- SLAs, Observability, Alerting, Distributed Tracing,
- CI/CD pipeline with all the stages in CI and CD
- QA Contract tests
- Dev and QA environment setups need more microservices to be setup
- A minimum set of resources for the container. Sum of all the minimums can end up being sub-optimal resource utilization which needs to be managed
- Separate repositories and management of them
These challenges can have a significant impact on the original problems it set out to solve, but can also create new problems:
- Engineer productivity – More time to set things up and debug a slew of microservices to isolate a problem
- Quality – More touchpoints and dependencies decreases the robustness of the system
- Cost – Cost in terms of resources and people for operational management
What is the Solution?
Is the solution to go back to a monolith? No, because that would take us back to the original set of problems. Although admittedly, some organizations have chosen this approach based on their context.
What we recommend is to take a balanced approach based on your context. You can ask these questions and consider the pointers while deciding.
- Are the scale requirements in the split-up microservices that different?
- With a difference of e.g. 10 reqs/sec vs 100 reqs/sec the services need not be split up. The threshold can be higher e.g. 100x
- Is the bar for “Bounded context” appropriate?
- Approach it from the product angle top-down
- E.g. If you have different personas for your product, the bounded context is the product, and not the “persona-product” combination
- Scaling Teams – Have a higher bar at the team level and not at an engineer level
Parting Thoughts
Let’s look at the advantages of Microservices, as well as what can be the downsides if it becomes one too many.
Once you are aware that you can end up with a lot of Microservices (Nano services), you can take a more conscious approach while creating new microservices.
If this sounds like something that tickles your brain cells, then we have some exciting opportunities lined up for engineers just like you!
