Microservices — Not a Silver Bullet

Let's see a typical conversation between business/customers with the tech team on the architecture front.

This is what you hear from business/customers, and the tech team is going crazy because of this. It is really tough for the tech team to convince decision makers why they should not adopt microservices when the entire world is reaping the benefits.

Let's look at various overheads and pitfalls of microservices. One needs to address all these concerns, on top of working on the core application.

Overheads of Microservices

• Interservice communication is a huge challenge
• Service discovery and registration
• Load balancing
• Decentralized Data Management
• Distributed Logging
• Monitoring
• Security
• Testing
• Performance/metrics
• Distributed transactions
• Containers - Docker/Kubernetes
• API Gateways
• Circuit breaker
• CI/CD and DevOps
• And more...

Microservices is simply not for everyone. Some of us after weighing the complexity against the benefits, decide to remain with monolithic architectures. Just because everyone is jumping off the bridge cannot be a reason for you to jump as well.

They are choices. You can still achieve what you are set out to achieve without doing microservices.

 There are questions that need to be answered.

• Why do you want to move to microservices?

• What benefits are you looking for?

• Is your organization ready for both structural and cultural change?

• Do you have engineering expertise already available in your company?

• How much do you want to migrate? When do you stop?

• Do the benefits outweigh the cost of such transformation? 

Let's look at various scenarios where one should not go for microservices

Scenario 1: Small Team

A small team with few members cannot go faster with microservices. The organization needs a certain critical mass to withstand the nuances and overheads of microservices, whereas, as far as a monolithic application is concerned, a small team of very few staff can manage, maintain, and operate a stable, decently sized application.

Scenario 2: Organization Structure and Culture

A microservices architecture will lead to a modular structure of the application whether or not the initial monolithic application was modular. This is a great outcome, as almost all advocates of software architecture will agree. The services created will be self-contained and independent.

Conway's law states, "Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure." As understood from this law, traditional architectures are simply copies of their siloed and hierarchical organization. As an organization grows, the decision makers keep adding more personnel under their group and control as a show of strength, with all communication going through them.

In contrast, microservices practitioners suggest that for success, teams should be small (maybe less than 10 people) and independent. The teams should be cross-functional with developers, testers, database, and operations personnel on the same team. They should be responsible for all aspects of the application, including non-functional aspects like availability, scalability, performance, etc.

 If the organization is not structured like this, they should not even think about moving to microservices. This should be the first prerequisite for microservices-based architecture.

Scenario 3: Startups Which Are Trying to Prove a Business Idea PoC

For a successful product, startups — or any organization, for that matter — do several PoCs sometimes to test the need for the product, market demand, a business scenario, or maybe a technology. This is needed to prove a business idea before venturing full-blown into the development of the idea. Whenever this is done, the organization needs to move quickly and at a breakneck speed. In such scenarios, a full-blown microservices architecture may not be a good idea. It is suggested that a monolithic application should be used as a PoC and then slowly transitioned to microservices.

Scenario 4: Non-Engineering Organizations

If you are an end-user organization where engineering is not at the core, it can really be detrimental if you adopt microservices. At the end of the day, all business organizations are there to make profits. If you are not focusing on creating value for your customer and are stuck in the nuances and overheads of architecture, this is definitely not for you. Think 100 times before venturing.

Reason for Change

By now, you must understand and have identified the real reasons you have chosen icroservices architecture over others. Let us talk about a few scenarios which can start you thinking about what to choose.

• If the entire application or all services are of a nature that they need to be deployed as a single unit, a poorly-designed microservices application may aggravate the situation.

• A previous unsuccessful monolithic application: if designing a monolithic application is a challenge for the organization, a microservices application will definitely fail.

• You have a legacy application which is expected to eventually sunset. Migrating a legacy monolith requires a lot of time and effort, which may not be worth it.

• If only the UI needs to be scaled and deployed several times during the day, you may extract the UI portion separately. This portion can then be scaled and deployed in separate containers, accessing the backend application using some sort of API. There is, again, no need to move fully to microservices.

• One feature/service seems to be always under load and needs scaling.

If you only require one or a few services to be scaled, rather than scaling the entire monolith with all its components, it looks like a genuine case to move to microservices. But, there are ways to avoid it. One approach is to extract these few services out of the monolith and host them separately in separate containers. This will not only help in scaling them, but also help you NOT move entirely to microservices.

Again, it is not about monolith or SOA or microservices. It is about architecture catering to business needs. If one can gain and achieve all the gains without needing to deal with microservices overheads, why think about getting into it? You may slowly add more services as needed. Nobody is pushing you to move entirely until you really need or want it.

Conclusion

We have talked about various nuances and overheads of microservices architecture. It is by no means a simple pattern which can be adopted and dropped easily if it's not working. One needs to look into all the pros and cons before pushing the organization onto the microservices path. One needs to focus on "why microservices" rather than "why not microservices." We have also discussed various scenarios. The idea is to avoid the various complexities of getting into microservices until absolutely necessary.

Again, you may disagree with some or all of my opinions here, but I am glad that we could discuss this today.

References:

• https://www.thoughtworks.com/insights/blog/demystifying-conways-law

• https://martinfowler.com/articles/microservice-trade-offs.html