The book of Iris
II. Nuts and bolts
- Request/reply pattern
- Broadcast pattern
- Tunnel pattern
III. Skyscrapers & spaceships
- Iris inside docker
IV. Case studies
- Embree decentralized
- RegionRank internals
- The night is dark and full of terrors
From the previous chapter we know, that the goal of Iris is to greatly simplify the design and development of decentralized backend services, but what makes it stand out of the crowd exactly? Why is Iris a better solution than the competition? In short, it is a different solution than the competition; and by the end of this chapter you'll know whether or not it is the right tool for you personally.
Units of composition
Messaging middlewares in general consider an application instance (e.g. webserver, database) as the smallest block out of which to construct the system. The problem with this model is that communication becomes overly complex when multiple instances of the same type are allowed to co-exist beside each other. Although flexible, it requires significant developer effort to use properly.
The unique concept of Iris is that clusters are the smallest logical units out of which distributed systems are assembled: a group of applications responsible for the same sub-task of the service (e.g. collection of databases). At any point in time there can be any number of instances belonging to the same cluster (including zero), the size being irrelevant: it can either be contacted or not.
These clusters can then be assembled into a service, where any component can query other member clusters for some sub-service, without having to know neither how many instances serve the arriving requests nor where these might be located. Such a service is considered the unit of security. These services can further be composed into a federation, but more on that later.
A significant difficulty using classical messaging systems arises from the use of low level network addressing. Whenever distributed applications scale up, new IP addresses get allocated and need to be integrated into the system. This leads to challenges of service discovery (i.e. how to locate an instance) and load balancing (i.e. how to distribute tasks to available instances). Typical solutions are registries and balancers, but these introduce extra moving components as well as possible single points of failure.
This is where Iris really shines: since the smallest unit of composition is a cluster opposed to an instance, the physical addressing scheme can be completely hidden behind semantic addressing. Whenever a node joins the network, it specifies the name of a cluster to be part of (e.g. "crawlers"), implicitly forming it if non-existent. The cluster can then be reached simply through its name (i.e. "crawlers"), Iris taking care of all the low level networking details for locating, routing and balancing.
Cluster names can be arbitrary string literals, with the sole limitation that they may not contain colons, as these will have special meaning within federated services.
The final component playing a major role in the capabilities of a messaging system is the security model, since it both defines the supported deployment environment, as well as the ways the system can be composed. Usually messaging middlewares stand at one of two extremes. Some provide zero security, leaving it to the developer to add it, which is hard, requires crypto knowledge and can conflict the core messaging system. Others employ full point-to-point security, which is slow and hard to configure properly.
Iris uses a relaxed security model that provides perfect secrecy whilst at the same time requiring effectively zero configuration. This is achieved through the observation that if a node of a service is compromised, the whole system is considered undermined. Hence, the unit of security is a service - opposed to individual instances - where any successfully authenticated node is trusted by all. This enables full data protection whilst maintaining the loosely coupled nature of the system.
The major benefits of the Iris security model are its simplicity and speed. Since all authenticated nodes are trusted, only a single service-global private key is required to access the network, making distributed deployment trivial (i.e. zero configuration). Additionally, due to the same trust model, Iris can employ a blazing fast encryption whilst remaining completely stateless by using a hybrid scheme: message payload is encrypted/decrypted once and only a tiny temporary key is processed at each hop.
Request/reply is the simplest communication pattern for backend services: a consumer sends a request to a sub-service, which responds with a reply. However, since a cluster is the smallest addressable unit, the target of a request is never a single entity, but rather the cluster of entities serving the same purpose (i.e. instances under the same name). A consumer addresses a cluster by its name, and Iris will route the request to an appropriate member, load balancing between all available.
Broadcast is a supporting scheme besides the request/reply, with the difference that whilst a request is delivered to a single member of the cluster, a broadcast is forwarded to all participants. This is the only way to contact every instance within a group, but since there is no concept of member count, there is no possibility for individual responses, as the recipient would never know how many replies to wait for.
The third pattern is the tunnel, another supporting scheme of cluster communication. Its goal is to solve the challenge of stream communication and/or stateful protocols, where an operation may consist of multiple data exchanges (e.g. database transaction). A tunnel establishes a communication stream between a client and a member of a cluster, with the guarantee of ordered and throttled delivery of messages.
Until now, all schemes were limited to a single target cluster. The last one - publish/subscribe - is a specialized communication pattern as it allows breaking cluster boundaries. Any instance within the network may subscribe to a topic (any number of them), effectively forming temporary clusters. Any entity can then publish events to these topics in a similar way to broadcasting. However, topics do not support request/replies or tunnels.