When not to use Microservices Architecture?

I believe microservices is not a one size fit all application architecture, similar to the Public Cloud business model to reduce capex or usage of virtualization for consolidation. It has its use cases and should be used after proper and complete planning. Let’s start by understanding the promises of microservices.

The promises of Microservices

Based on the problem you are trying to solve microservices can enable an organization to go faster by reducing the time & friction to make changes to the system. With a microservices architecture, each service would likely be operated independently and have its own release cadence/lifecycle independent from others. This would give the developers and operators parallel tracks to move faster without the locking/synchronization/coordination of making changes which can serve to slow down deployments and feature changes.

Another reason why a service may be further broken down is its usage patterns and scaling properties. For a simple example, a service that has heavy reads and writes may benefit from separating out reads from writes because reads may be more memory intensive (maybe needing more cache space to make the reads super fast) while writes may be more storage or network intensive. You could optimize the read part of a service on machines/quotas that allow it to scale independently (more memory) then have the write part of the service on other machines that have SSD or optimized EBS/SAN, etc.

Other reasons why you might split an app into services:

• security concerns
• domain grouping
• different language optimizations
• criticality of service

What exactly is the underlying problem being solved with microservices?

DevOps approach gives the developers and operators parallel tracks to move faster without the locking/synchronization/coordination of making changes which can serve to slow down deployments and feature changes. This brings us to the critical question of why frequent changes? To solve a bad code or to solve a bad infrastructure choice? Or something else?

There is a price to be paid 

When you go from one thing (monolith) to a bunch of little things communicating with each other (to optimize for a particular concern), you significantly increase complexity both in the architecture as well as the infrastructure necessary to run things. This might an acceptable price as long as you are completely aware of assumptions alongside what is the long & short term benefits you hope to reap.

Most of the tools used to manage, monitor and report in microservices themselves have their own update cycles. Once a tool is update then its compatibility with running application which in microservices is now running as multiple services must be tested and since with a microservices architecture, each service would likely be operated independently and have its own release cadence/lifecycle independent from others the time taken for testing goes up when compared to monolith where you are dealing one app.

While each service might be at the liberty of choosing its own security approach sometimes this can become a communication bottleneck both at the network or processing layer. 

Infrastructure choices for a line of business applications are very critical and very time-bound processes. Just trying a new approach each time is just not a great way to deal with it. Also if the organization lacks the discipline for writing quality code, this most likely will carry the problem into the microservices architecture as well. Are microservices a viable substitute for code quality, standards, and discipline? Absolutely not.

Conclusion

The point is that all that complexity associated with microservices is only worthwhile in the end if it delivers the desired results. Whether it’s because of scaling concerns, the desire to use different languages for different purposes, domain groupings, or security concerns, there are valid reasons for microservices, but simply avoiding the feared term “monolith” is just not one of them. Much like a complete Public cloud is not practical or all-out virtualization approach for all application platform is not advisable, similarly, a complete microservices migration of existing Line of Business application for all application is also not advisable a better approach might be to continue using monolithic app and new feature or change to the monolith app could be integrated as microservices. Then again it differs from app to app and organization to organization needs. The bottom line is to study your existing app requirements and dependencies take into the consideration of complexities for deploying your apps as services, have detailed testing a rollout plan to move to microservices and rollback plan if required.

Disclaimer: This is a personal article. Any views or opinions represented in this article are personal and belong solely to the owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity unless explicitly stated.