Read on Twitter
This morning, I& #39;ve written a few things about the downsides of a microservice architecture. A thread 
https://abs.twimg.com/emoji/v2/... draggable="false" alt="👇" title="Rückhand Zeigefinger nach unten" aria-label="Emoji: Rückhand Zeigefinger nach unten">
Don& #39;t be a victim of the fallacies of distributed computing:
- The network is NOT reliable
- Latency is > 0
- Bandwidth is not infinite
- The network is not magically secure
- Network topology changes
- There are many admins
- Transport is costly
- Networks are not homogeneous
- The network is NOT reliable
- Latency is > 0
- Bandwidth is not infinite
- The network is not magically secure
- Network topology changes
- There are many admins
- Transport is costly
- Networks are not homogeneous
If you& #39;re building microservices, then you& #39;re essentially building a distributed system. And distributed systems are hard.
The network will fail you at times. Sometimes it& #39;ll be slow, requests will be lost, a firewall will start blocking traffic, IPs & DNS will change, etc
The network will fail you at times. Sometimes it& #39;ll be slow, requests will be lost, a firewall will start blocking traffic, IPs & DNS will change, etc
From an operational pov:
- The infrastructure required is more complex
- It is more difficult to monitor the system
It is more difficult to orchestrate deployments
- Load balancing is more complex
- Debugging problems is harder
- Configuration management is harder
- The infrastructure required is more complex
- It is more difficult to monitor the system
It is more difficult to orchestrate deployments
- Load balancing is more complex
- Debugging problems is harder
- Configuration management is harder
From a maintenance pov:
- The cognitive load is higher with multiple interacting services
- Taking over the maintenance is harder (if/when different tech stacks are used)
- Moving responsibilities around is harder (communication/collaboration, change of language, etc)
- The cognitive load is higher with multiple interacting services
- Taking over the maintenance is harder (if/when different tech stacks are used)
- Moving responsibilities around is harder (communication/collaboration, change of language, etc)
From a security perspective:
- The system as a whole is harder to monitor and trace (e2e visibility)
- Authc & Authz are harder and incur additional performance overheads
- Data is harder to keep safe (potentially scattered, duplicated)
- Increased attack surface of the system
- The system as a whole is harder to monitor and trace (e2e visibility)
- Authc & Authz are harder and incur additional performance overheads
- Data is harder to keep safe (potentially scattered, duplicated)
- Increased attack surface of the system
From a data mgmt pov:
- distributed data
- potential duplication
- potential data synchronization issues (eventual consistency)
- different data models
- different data stores
- no centralized data management
- distributed data
- potential duplication
- potential data synchronization issues (eventual consistency)
- different data models
- different data stores
- no centralized data management
From a communications pov:
- APIs evolve, and all interacting services need to adapt
- API design requires specific skills and consistency
- API documentation becomes critical (good actually)
- Interactions are not free. The more services communicates, the more the system costs
- APIs evolve, and all interacting services need to adapt
- API design requires specific skills and consistency
- API documentation becomes critical (good actually)
- Interactions are not free. The more services communicates, the more the system costs
Microservices also creates "new" needs:
Microservices that become available need to make themselves "known" by the rest of the system (ie service registration)
Services need to find the other ones (ie service discovery).
Configuration management is also specific
Microservices that become available need to make themselves "known" by the rest of the system (ie service registration)
Services need to find the other ones (ie service discovery).
Configuration management is also specific
Testing scenarios involving multiple services is also more difficult with microservices
The orchestration required is more invovled.
The orchestration required is more invovled.
If microservices expose their own UI, then integrating those can also be a challenge. The same goes for the UX/UI consistency across all the services.
