Overview

When you write your application as a set of microservices, you’re actually writing multiple applications that will work together.
Each microservice has its own distinct responsibility and teams can develop them independently of other microservices.
The only dependency between them is the communication.
- As microservices communicate with each other, you will have to make sure messages sent between them remain backwards compatible.
- This requires some coordination, especially when different teams are responsible for different microservices.

Advantages

You can write, maintain, and deploy each microservice separately.
A microservices architecture should be easier to scale, as you can scale only the microservices that need to be scaled.
- There’s no need to scale the less frequently used pieces of the application.
It’s easier to rewrite pieces of the application because they’re smaller and less coupled to other parts.

It’s easier to write a well-structured monolith at first and split it up into microservices later.
- With microservices, a lot of extra concerns come into play: communication, coordination, backward compatibility, logging, etc.
- Teams that miss the necessary skill to write a well-structured monolith will probably have a hard time writing a good set of microservices.
A single action of a user can pass through multiple microservices.
- There are more points of failure, and when something does go wrong, it can take more time to pinpoint the problem.

Applications where certain parts will be used intensively and need to be scaled.
Services that provide functionality to several other applications.
Applications that would become very complex if combined into one monolith.
Applications where clear bounded contexts can be defined.

These fallacies were statements made by Peter Deutsch and others at Sun Microsystems.
They explain the false assumptions that people make about distributed systems.