Why Are Software Engineers Quitting Microservices?

Modern Software Engineering

62,594 views • 10 months ago Save 13 min 4 min read

Video Summary

The notion that developers are abandoning microservices is likely a misconception. While search trends for "microservices" remain strong, a surge of articles questioning their popularity suggests a growing realization of their complexities. An often-cited, yet now-unavailable, article from Amazon detailing a move from microservices to a monolith is discussed. However, the presented architecture in that article doesn't align with true microservice design, appearing more like a generic workflow orchestration. This suggests the issues stemmed from the misuse of tools like AWS Step Functions, not from the microservices approach itself.

Microservices, when implemented correctly, are an excellent solution for scaling development by enabling small, autonomous teams to work independently. However, they introduce significant complexity, which is often underestimated. The core principle of microservices is independently deployable services, requiring sophisticated design for strong decoupling and modularity. Ignoring these principles, such as by focusing solely on small services without addressing inter-service coupling or decentralized data management, leads to problems. The inherent costs of microservices include translation at boundaries, remote call overhead, and managing failures in distributed systems, which dramatically increase complexity compared to local calls.

Achieving the benefits of microservices demands a high degree of sophistication in both development approach and design. This includes autonomous teams, continuous delivery, trunk-based development, TDD, continuous integration, contract testing, and a ports and adapters design. Furthermore, understanding the intricacies of distributed systems, such as circular communications, distributed transactions, race conditions, deadlocks, and eventual consistency, is crucial. While large distributed systems are inherently complex, a well-architected microservices approach, emphasizing decentralized governance, clear communication abstractions, and treating services as products rather than projects, offers the most scalable way to build software. It is essential to approach microservices with caution and a deep understanding of their principles, rather than as a simplistic solution.

Short Highlights

The claim that developers are dropping microservices is likely inaccurate, as search trends remain high.
A reported case of moving from microservices to a monolith may have been due to misapplication of tools like AWS Step Functions, not a fundamental flaw in microservices.
Microservices excel at scaling development for autonomous teams but come with significant overhead and complexity.
True microservices require independently deployable services, necessitating strong design principles like decoupling and modularity.
Successful microservice implementation demands sophisticated development practices and a deep understanding of distributed systems, with an emphasis on communication and decentralized approaches.

Key Details

The Misconception of Developers Dropping Microservices [0:00]

There is a growing discussion and numerous articles suggesting developers are abandoning microservices.
This notion is considered potentially wrong and a mistake if true.
Search trends for "microservices" as a search term show it is not going away.
The number of articles with titles like "the death of microservices" indicates a realization that the approach isn't as straightforward as once believed.
An Amazon article, no longer available, described moving an application from microservices to a monolith to improve performance, reliability, and reduce costs.
This article is speculated to be a root cause for the flurry of "death of microservices" posts.
The description of the so-called microservice approach in the Amazon article doesn't align with typical microservice design, raising questions.
An architectural diagram from the disappeared article shows a system that does not resemble a microservice design, lacking clear "bounded contexts."
The system's aim was to analyze frame and audio buffers in real time for defects.
The core of the system described was built from AWS Step Functions, an orchestration system for managing workflow between services, often generic ones.
This orchestration system is not considered a microservice architecture.
The original article cited this orchestration as the bottleneck causing poor system performance.
Using a generic low-code tool for high-volume data processing is seen as a risky strategy.
The speaker speculates that the article's removal from Amazon's site was because it exposed a weakness in their design and tool misuse, rather than a flaw in microservices.

It raises some questions.

My first thought is that this looks nothing at all like a micros service design to me.

This is not really the same thing as a micro service architecture at all by any stretch of the imagination.

This isn't really surprising since they're using a generic low code tool for processing high volumes of data.

They realized that this story exposed a weakness in their own design and their misuse of their own tools rather than a weakness in microservices in general.