Foojay Today

SKP’s Definitive Primer: Failures, Pitfalls, and Disadvantages of Microservices

August 02, 2021

Microservice adoption has almost become the norm in most software product and IT services organizations. Below, I take the opportunity to make you aware of real-world issues faced by organizations of all sizes in migrating or adopting microservices. Since learning from others' mistakes and knowing pitfalls upfront can be helpful in preparing and planning better, this overview will be of help to those planning a shift to a microservices strategy organization-wide or simply making a move from monolithic to a microservices architecture.

The idea is for you to skim through the below lists of links and then read in detail a few that you find are closest to your needs. In this article, I provide brief explanations of the main challenges of adopting microservices. Also, you may use this as a reference index for articles published online to further your knowledge regarding the pitfalls of adopting microservices.

Practical Challenges in the Adoption of Microservices

  • Overhead. The set up of microservices requires more effort than one might expect as there are several infrastructural architectural pieces that are part of a complete microservices architecture. For example, you will encounter terms such as API Gateway, Circuit Breaker, Discovery Server, Config Server, Health Monitoring, Vault Service, Token Service, Logging & Auditing, as just a few of the initial infrastructural services typically required to correctly implement a complete microservices architecture in the enterprise.
  • High Skill. There is a high skill level required, especially in terms of experienced senior architects, DevOps, and developers who now need to understand the change in development paradigm. Also, this may either increase development time or development costs or both.
  • Complexity. One of the most important disadvantages of microservices is the complexity involved. Even though this point is captured in the above two points already, it requires a mention on its own here. The interplay of the plethora of infrastructural services along with the actual application of microservices may create unending cycles of complexity.
  • Redundancy. During development, architects and lead engineers may need to continually make sure that there is no duplication of code, configurations, or any other effort that may already have been developed by another team. This starts becoming a greater concern when there are geographically distributed teams focusing entirely on their own set of business or product deliverables. Though some very trivial code duplication may be inevitable, discipline will be required to isolate and group common functionality or common code together correctly.
  • Data Duplication. One of the greatest challenges is data duplication. Most inexperienced architects and engineers may end up in such situations because the thought that was required to build monolith data access and creation cannot now be used for microservices. The mechanism to maintain data integrity and data consistency in a product to make sure that there exists a correct 'Single Version of Truth'. This needs to be planned, architected, and infused into the design.
  • Communication. The communication between the external world and microservices or within microservices may fail. This could be due to multiple reasons including network failure and service unavailability. In any case, the communication between microservices is critical and is tough to set up and maintain. It also requires constant monitoring of health and performance of each of the microservices. Partial failure is actually an advantage of microservices, but still the monitoring, failure detection, failure handling and simply the internal/external communication can be quite an overhead in the implementation of microservices.
  • Maintenance. Once the initial part is over, even If the microservices strategy and implementation turn out to be a success, it still means a heavy hit on the pocket for maintenance. Even though all of the current generation organizations rely on an external Cloud provider, it still means more expenditure on hardware, software, Cloud, and DevOps engineers. Also, the total cost of ownership of such an infrastructural masterpiece is only bound to Increase as more abstractions are added over time, while the maintenance itself could be a complicated process.

Challenges of Moving from Monolithic to Microservices

Top 3 Challenges of Adopting Microservices as Part of Your Cloud Migration
From Monolith to Microservices: Horror Stories and Best Practices
Advantages and Disadvantages of Microservices Architecture
Fearless Monolith to Microservices Migration – A Guided Journey

Failure and Pitfalls of the Microservices Strategy

Experiences from Failing with Microservices
How To Succeed at Failure with Microservices
How to Condemn Your Microservices Architecture to Fail
Your Microservice Architecture Will Collapse

Learn from Others' Mistakes in Microservices

5 Big Microservices Pitfalls to Avoid During Migration
Tech Talks With Tom Smith: Issues in Migrating to Microservices
11 Reasons Why You Are Going To Fail With Microservices
Failing at Microservices - Please Avoid Our Mistakes!

Planning a Microservices Adoption in the Enterprise

Pitfalls & Challenges Faced During a Microservices Architecture Implementation
4 Challenges You Need to Address with Microservices Adoption
Challenges when Implementing Microservices
How to Plan a Microservices Migration
Fearless Monolith to Microservices Migration – A Guided Journey

Real-World Case Studies of Microservices Adoption

Why and How Netflix, Amazon, and Uber Migrated to Microservices: Learn from Their Experience
Explore UBER’s Microservice Architecture
Why Microservices Fail? — Xebia Blog

Death of Microservices, Already, In 2021 ?

Microservices to Not Reach Adopt Ring in ThoughtWorks Technology Radar
The Death of Microservice Madness in 2018
Goodbye Microservices: From 100s of Problem Children to 1 Superstar
Unraveling Microservices: Higher Agility or Hype?


  • Sumith Puri

    Sumith is a Enterprise Architect (Java / Java EE) at Mphasis, Bangalore. He is a Hard-Core Java / Java EE Architect and Developer with ~17yrs of Progressive Work Experience. He ... Learn more

Comments (0)

Your email address will not be published. Required fields are marked *

Highlight your code snippets using [code lang="language name"] shortcode. Just insert your code between opening and closing tag: [code lang="java"] code [/code]. Or specify another language.

Save my name, email, and website in this browser for the next time I comment.

Subscribe to foojay updates:
Copied to the clipboard