Cardinality of routers and realms

#1

One advantage that I can see to having multiple realms per router is if
transports are configured on a router by router basis. So if you had 100
realms, you could easily deploy them all under a common transport or set

Exactly. And the overhead in CB of running another realm is minimal. You can run 10s of thousands realms. Think: multi-tenancy. You can't configure those realms using a static node config, but you will be able to script/API control CB to fire up those realms. You will be able to have a "meta App component", which fires up realms when tenants (of your app) sign up. etc etc.

We already did the hard groundwork in CB .. the bits are there. Need to connect the dots. But as these are all quite new and advanced concepts, we (the CB community) need to make sure to gradually introduce those things to let users grok those concepts.

E.g. the idea, that _CB_ itsef has a meta API (I am not talking about WAMP meta API - which CB also has), which is also WAMP, and where CB talks to uplink management CB - on another level - might come as a surprise to some. It's like a "self hosting compiler" - or recursive WAMP. CB has passed that stage early this year. It's just that we are not yet talking much about it.

of transports. Where in a 1:1 type of relationship you would need to
configure 100 different routers/transports. The same would be true of
application components and any other resources owned by a router. So
from a resource and configuration standpoint this makes sense. If
you desired a 1:1 type of relationship you can still have that as well.

Yep. And you can also mix that.

E.g. you could have a dedicated router process with only a single realm, where you give that process appropriate RAM resources (cgroups) to "guarantee" a certain QoS. And then you can have another router process that runs 1000 "best-efforts" realms.

Cheers,
/Tobias

···

Am 10.09.2015 um 17:46 schrieb David Chappelle:

0 Likes

#2

One advantage that I can see to having multiple realms per router is if

transports are configured on a router by router basis. So if you had 100

realms, you could easily deploy them all under a common transport or set

Exactly. And the overhead in CB of running another realm is minimal. You
can run 10s of thousands realms. Think: multi-tenancy. You can’t
configure those realms using a static node config, but you will be able
to script/API control CB to fire up those realms. You will be able to
have a “meta App component”, which fires up realms when tenants (of your
app) sign up. etc etc.

We already did the hard groundwork in CB … the bits are there. Need to
connect the dots. But as these are all quite new and advanced concepts,
we (the CB community) need to make sure to gradually introduce those
things to let users grok those concepts.

E.g. the idea, that CB itsef has a meta API (I am not talking about
WAMP meta API - which CB also has), which is also WAMP, and where CB
talks to uplink management CB - on another level - might come as a
surprise to some. It’s like a “self hosting compiler” - or recursive
WAMP. CB has passed that stage early this year. It’s just that we are
not yet talking much about it.

of transports. Where in a 1:1 type of relationship you would need to

configure 100 different routers/transports. The same would be true of

application components and any other resources owned by a router. So

from a resource and configuration standpoint this makes sense. If

you desired a 1:1 type of relationship you can still have that as well.

Yep. And you can also mix that.

E.g. you could have a dedicated router process with only a single realm,
where you give that process appropriate RAM resources (cgroups) to
“guarantee” a certain QoS. And then you can have another router process
that runs 1000 “best-efforts” realms.

Thanks to both of you for elaborating. It makes a lot of sense.

When I first saw the approach taken by Dave with Bonefish, I kind of liked the simplicity of it. In a way, it felt “pure” that there was a 1:1 mapping between router processes and realms. And the programmer in me also saw that this probably simplified the implementation, like Dave mentioned.

Reading your words though Tobias, Crossbar’s model makes perfect sense, in the context of its ambition of being “more than just a WAMP router” so to speak.

I’m sure you can build sophisticated multi-tenant solutions around a 1:1 router. The approach taken by Crossbar is just different in that it’s “batteries included”.

Cheers,
Elvis

···

On Thursday, September 10, 2015 at 6:56:06 PM UTC+2, Tobias Oberstein wrote:

Am 10.09.2015 um 17:46 schrieb David Chappelle:

Cheers,

/Tobias

0 Likes