Distributed Systems
What?
"A system in which the failure of a computer you didn't even know existed can render your own computer unusable" - Leslie Lamport
- Multiple computers/machines typically communicating over a network
- Can involve all elements of usual Executions, but since a network and different environments are getting involved - things get tricky.
Why?
Some applications are inherently distributed. Example, sending message from your phone to your friend's phone - no two ways about it.
But other reasons why you may choose to have distributed systems could be:
- Better reliability: Even if one node fails, system as a whole keeps functioning
- Better performance: Get data from nearby node, rather than one halfway around the world
- To solve bigger problems: Huge amounts of data - can't fit on one machine
- Different applications/services talking to each other: Your app might need to talk to other applications or services over network.
Why NOT?
- Communications can fail – and we might not even know it.
- Malicious players
- Processes themselves may crash - other systems might not be aware of it.
- All these failures may happen nondeterministically.
Why study?
The main challenge of having distributed systems is to keep them fault tolerant – whole system should work despite failures of some parts.
💡 Tip: If it can be done on one computer -> keep it that way
Communication
Communication between nodes can be either Executions#Synchronous or Executions#Asynchronous.
The method to be used is mainly dependent on what kind of Executions#Synchronicity, systems.char.performance.i.latency and systems.char.performance.i.throughput is required in the system.
APIs
APIs define the interface or contract of how different nodes in distributed system are supposed to interact with each other.
REST
aka REpresentational State Transfer.
- Set of architecture principles => implementation is up to developers
- built for web services and mobile applications => lightweight
- Request for data is usually sent over std.web.http.
- Return message can be in a variety of formats:
- HTML
- XML
- Plain Text
- Web#JSON
Application is said to be RESTful if it follows these 6 architecture guidelines:
- Client-Server architecture composed of clients, servers and resources.
- Stateless client-server communication
- No client content is stored in server between requests i.e. requests don't share any client information on server side.
- Information about the session's state is held with client
- Cacheable data to eliminate the need for some client-server interactions.
- Uniform interface between components => information is transferred in a standardized way instead of being application-specific.
Central feature that distinguishes the REST architectural style from other network-based styles. - Roy Fielding (originator of REST)
- A layered system constraint => client-server interactions can be mediated by hierarchical layers.
- Code on demand: Allowing servers to extend the functionality of a client by transferring executable Code. => Also reduces visibility => Optional.
RPC
RPC is a protocol to implement APIs. It allows a program to execute a Program Components#Functions on another computer - as if it were a local function call.
Emphasis on the last part because that's what RPC emphasizes - abstraction of network call from the developers.
SOAP
- Was first designed so that different languages on different platforms can communicate.
- Standard protocol
- Built-in rules => increases complexity and overhead => longer page load times.
- Built-in compliances => ensure security and Transaction#ACIDity => preferable for enterprise scenarios.
