Describe use cases

[thedrow]

We all know the usecases for projects like ZeroRPC & Serf. It seems that they provide similar features (especially Serf). How is iris any different?

[coopernurse]

I won't be able to do this question proper justice, but until Peter replies, here are my thoughts:

(a) Discovery. Iris attempts to solve the issue of cluster peer discovery. The iris agent running on each node scans the network for its peers and given sufficient time will converge. This happens continuously and is particularly useful if you're in a cloud environment where nodes may come and go. By contrast Serf and ZeroRPC require you to explicitly dial endpoints. Tracking the health/state of those endpoints is left to you, and that's a non-trivial problem.

(b) Messaging patterns. I'm not too familiar with ZeroRPC, but presumably you've got the full suite of ZeroMQ patterns at your disposal (not sure). Serf appears to only support a "broadcast" pattern where all peers in the cluster receive every message. That's useful for devops type messages ("upgrade to release v1.3.1", "restart nginx", etc) but less useful for RPC applications where you want each message consumed once and only once. Iris provides the ability to do RPC, pub/sub, tunnel, or broadcast.

I see Iris competing more with ZeroRPC than Serf, but IMHO the discovery bit is the killer feature. If you layer something like Barrister RPC on top of Iris then you have a full RPC solution (disclosure: I'm the author of Barrister RPC).

I've been watching Iris for over six months and I'm very interested to see where it goes. I hope more folks get involved.

[thedrow]

Both ZeroRPC and Serf are designed for service discovery. Serf after all is used for service discovery. Serf and ZeroRPC have mechanisms that allow you to track a node's health. Serf also has membership which means that you can track the health of a cluster. Serf and ZeroRPC does require you to dial endpoints but with Serf, the defaults might work.

With ZeroRPC you can of course perform RPC requests and you can stream.responses which is enough for most cases.

How is Iris superior over ZeroMQ as a distributed messaging framework for backend services? Especially if you have projects like https://github.com/tailhook/zerogw that already work with ZeroMQ.

Does it have more discoverability patterns out of the box? Do you consider the fact that it is protocol agnostic (at least I think it is) provides an advantage over ZeroRPC which uses the widely known and used MessagePack?

[karalabe]

My goal with Iris was that whilst resource provisioning in clouds (e.g. rent a hundred VMs) is dead trivial, wiring those rented VMs together to collectively perform something useful is anything but. I wanted the simplicity of clouds available at software level, to have the whole network of nodes "just" work together, without me needing to manually configure, monitor and etc.

You can find a more detailed discussion of the core concepts behind Iris in the book of Iris, but in a few words, the benefits of Iris:

• Zero configuration: you simply start up an Iris node on each VM, and they will find each other and self organize into a P2P overlay (ZeroMQ and inherently all project built on top of it require manual configuration, and topology management; Surf also requires the address of an already existing node).
• Semantic addressing: all networking details are hidden. Whenever a nodes joins the Iris network, it joins an application cluster (e.g. database, webserver, proxy, memcache, etc). From that point onward, any member of the network can issue requests, broadcasts, etc. to the node by only specifying its semantic name (e.g. get me the reply to this request from a database). A distributed Iris application never touches network addresses and/or ports. On the other hand, ZeroMQ requires you to manually manage network details, which IMHO is too complex (yes, it can be done, yes, it has been done, but the barrier of entry for a small team is too high).
• Clusters as units: with Iris, an application cluster (e.g. databases) can have as many members as you see fit, and Iris will take care of load balancing between them. When you send a request to a cluster, Iris will route to one member it sees fit, without you having to know how many nodes there are in the specific app group, or where in the network these nodes reside. This is extremely powerful as I can scale my application up and down with zero added configuration, zero manual overhead. The new nodes will simply integrate into the existing system and start handling requests.
• Implicit security: all traffic within Iris is encrypted, and Iris is blazing fast in doing so. Every message that crosses the network link is unintelligible to packet sniffing, and the network is protected against all active attacks too. ZeroMQ had no security model until version 4, when they tried to implement it while remaining backward compatible with their existing model, which imposes certain limitations that you cannot overcome. Iris was designed with security in mind from day one, which is why it integrates so beautifully, seamlessly and performantly into the system.

To sum it up, Iris doesn't necessarily bring drastically new ideas into distributed systems, but rather it tries to remove as much complexity as possible, allowing devs to focus on their domain problem and not on networking. Existing systems are perfect if you have the necessary team and know-how to assemble and maintain it. Iris is more in line with the philosophy of cloud computing: empower small teams to achieve what previously required significant effort.

Beside the book mentioned earlier, you can also skim through my FOSDEM talk. It contains a few sample codes, a ray tracer teaser as well as the architectural design of RegionRank, a live service supported by Iris.

[karalabe]

Just a small followup, Iris tries to support the internals of backend services, so RESTful and/or HTTP gateways are beyond its scope. Also RPC is usually language specific and doesn't really concern the core networking layer.

Of course these are valid and valuable things to have, but Iris is by itself large enough without further broadening its scope. I'm aiming Iris to be a technology enabler, not a silver bullet solving all possible problems. I want Iris do to its core magic as simply, stably and speedily as possible, enabling others to build powerful things on top of it.

[thedrow]

Good enough. Maybe the comparison could go to the book in some form.

[karalabe]

That's a fair request :). I was/am considering adding a "Shootout" chapter to compare it with other similar systems. Hopefully I will get to it not too far from now, but working on Iris alone (whilst having to write a PhD + RegionRank as a use case), it does take time to attend to everything.

[thedrow]

@karalabe The project looks very interesting but it's not engaging enough. You can't expect people to contribute without open issues about new features to add, missing tests, missing documentation (btw see #20).

[karalabe]

Fair enough. I'll try and open up the things I planned as issues for all to see and comment and whatnot.

[stephenwithav]

Péter,

I hope to experiment with Iris this weekend on a few cloud servers of mine.

A use case: say I have six servers, each with a distinct public ip. By zero configuration, are you saying that I can just launch Iris on each server and the instances will find each other?

If the six servers are spread across three subnets, how will Iris handle that?

As you say, wiring the VMs together is not easy. I'm hoping that Iris will simplify that process so that scaling Go will be trivial.

Best,

Steven

On 4/2/14, Péter Szilágyi notifications@github.com wrote:

My goal with Iris was that whilst resource provisioning in clouds (e.g. rent a hundred VMs) is dead trivial, wiring those rented VMs together to collectively perform something useful is anything but. I wanted the simplicity of clouds available at software level, to have the whole network of nodes "just" work together, without me needing to manually configure, monitor and etc.

• Zero configuration: you simply start up an Iris node on each VM, and they will find each other and self organize into a P2P overlay (ZeroMQ and inherently all project built on top of it require manual configuration, and topology management; Surf also requires the address of an already existing node).

[karalabe]

Although Iris tries its best to self organize, crossing subnets is not something it supports or as a matter of fact can support in the general sense. If subnets are only partially available to each other through some gateway machines, the Iris overlay will not function correctly. If on the other hand the subnets can access each other freely, then machines belonging to both subnets could bridge them and allow successful convergence.

I'm guessing your use case is most probably the former (at least out of my GCE experience). A more generic use-case for that problem is spanning datacenters, which is called federation. It is a planned feature, one that I've thought about, but I still need a bit of pondering on how to do it so that the simplicity of Iris is not ruined.

[karalabe]

I'm closing this thread down. You're welcome to continue the discussion o the Iris mailing list :)

https://groups.google.com/forum/#!forum/project-iris

[karalabe]

Just a followup to Steven's question, hopefully the new chapter in the book of Iris will clarify the targeted environment a bit: http://iris.karalabe.com/book/run_forrest_run