When starting out with microservices there are common misconceptions that can get you into trouble later. This article gives a short overview of these myths and offers a good next step towards avoiding several pitfalls.
Myth #1: microservices is about technology
Not true:
The only valid reason to do microservices is because it optimises team size and velocity, by avoiding that developers step on each other’s toes in the codebase and mess up release cycles. So it's all about efficiency, not about technology. Technology is only there to enable certain things.
Myth #2: microservices means HTTP/REST/JSON
Not true:
This practice invariably leads to many more technical failures that users don’t want to know about (see the download at the end of this post for what can go wrong). Also realise that serverless still runs on servers (and thus requires network delays and all that) so beware of the cost.
Instead, consider messaging (to limit network issues) or gRPC (to enhance compatibility across releases).
If you can't do either, consider doing a consumer-driven contract approach to test new releases early for compatibility with existing clients / microservices. This, however, comes at an extra development cost.
Myth #3: believing that it’s all about being polyglot
Not true:
Every microservice needs some crosscutting concern support, and this requires extra overhead from your infrastructure teams. Limit this overhead in exchange for better and more efficient support from the infrastructure teams: monitoring, instrumentation, reliability and fault-tolerance.
In other words: just because you have a couple of idle .Net developers around doesn't mean you should not focus on Java. Or the other way around.
Related to this: if you're a technology or development manager then you probably know how much developers like to learn and use new technology. Going microservices is not an excuse to mix-and-match whatever new gadgets you (or rather: they) like.
To make matters worse: polyglot persistence has serious pitfalls with respect to data consistency (see the download at the end of this post for what can go wrong).
Myth #4: “distributed transactions - just say no!”
Not true at all:
Believing that data consistency is guaranteed by the “patterns” out there (notably sagas and/or eventual consistency) is the final and probably the most dangerous myth.
You would be surprised how many experts still claim this to be the case. The cause of this misconception is that people tend to confuse distributed transactions with synchronous calls. Even if you make things asynchronous via your latest greatest event bus / broker, you still have "distributed transactions" that need to be managed (whether you choose to call it an "elephant" instead does not change the core of the matter).
The bottom line regarding this myth: the patterns people use don't actually work correctly and on top of that take a lot of needless development effort. See the download below for what can go wrong…
FREE PDF cheat sheet: 5 common data consistency pitfalls with microservices
We have 20+ years of experience in reliability for distributed systems geared towards customers who value data integrity the most: financial services.
This has allowed us to identify 5 common data consistency pitfalls that people encounter in their microservice architectures.
Learn these 5 data consistency pitfalls (that happen even with Sagas, Kafka brokers or eventual consistency) and get introduced to our way of doing microservices:
