Distributed systems
“There’s no such thing as free lunch”
The story of distributed systems goes way back, and it can be traced to the early days of computing around the 1980s with Client-Server architecture.
In today's day and age with the rise of containerization technologies and microservice architecture, distributed systems are more prevalent than ever, and given the current rate of cloud adoption, the approach toward architecting systems in a distributed manner will increase even more.
The strong nature of distributing tasks can be seen in our organizational framework…we’re working in distributed teams, and projects and we even distribute compute resources in geographical Regions and Zones.
Microservices
Microservices are self-contained and “independent” services decoupled from each other that can communicate between them via:
Cross dependencies are implied since no service can perform without getting help from other services.
Challenges
In a distributed system when it comes to high-availability and resilience there’s always a tradeoff and it’s impossible to simultaneously guarantee Consistency, Availability, and Partition tolerance (check CAP theorem).
The gist of it…a distributed system can prioritize at most two out of these three properties:
- Consistency — data is the same across the cluster, so you can read or write to/from any node and get the same data.
- Availability — the ability to always respond to queries irrespective of nodes going down.
- Partition tolerance — the system continues to function even if there is a “partition” (communications break) between two nodes — both nodes are up, but can’t communicate.
False assumptions are usually made concerning distributed computing also known as fallacies of distributed computing.
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn’t change
- There is one administrator/orchestrator
- Transport cost is zero
- The network is homogeneous
Conclusions
“There’s no such thing as free lunch” …distributed systems are indeed built for size and resilience, but don’t forget distributing state across services means that every call to an external service is more or less an availability dice roll.
