A few questions

#1

I apologies in advance for the vast number of buzzword in this post…

Firstly Crossbar.io and autobahn look awesome and I can see great potential. So thank you for all the great work so far.

I am looking at how one would compose a large application from independent microservices.

To maintain flexibility I would like to be able to manage those components/microservices separately. i.e. start/stop and release new versions of a component without having to bring the whole application down.

With this in mind would the following work:

A single crossbar router instance running without any additional components (except possibly auth).

Then individual components written with Autobahn would connect to that router from arbitrary locations.

So for example I may use a cluster of CoreOS machines. Each component (including the router itself) would be packaged up in a docker container. The cluster would run one copy of Crossbar (until multi-node is released). Then each component would be set to run on a random machine in the cluster, it would then connect up to the instance of crossbar.

  • Can anyone see any big gotchas with this approach?
  • Is this a use case that the dev team envisioned when building crossbar/autobahn?
  • As a slight side question - if an event is published, is it lost if the router is restarted prior to delivery?

Thanks again,

Jon

0 Likes

#2

Hi Jon!

No problems with the buzzwords - we’re thinking about switching from “components” to “microservices” ourselves. :wink:

There is no real difference between the two, and should one moniker get people more interested than the other, then that’s a net gain.

Regarding your questions:

  • I don’t see any gotchas. The only knowledge your microservices need is the IP of the Crossbar instance, so you’re free to distribute as you like.

  • This is definitely a use case that Crossbar & WAMP are made for. The possibility to run components microservices from Crossbar is a comfort feature to make deployments easier, not in any way a requirement.

  • Crossbar currently does not have any kind of persistence mechanism across restarts.

Regards,

Alex

···

Am Dienstag, 9. Dezember 2014 02:13:30 UTC+1 schrieb Jonathan Moss:

I apologies in advance for the vast number of buzzword in this post…

Firstly Crossbar.io and autobahn look awesome and I can see great potential. So thank you for all the great work so far.

I am looking at how one would compose a large application from independent microservices.

To maintain flexibility I would like to be able to manage those components/microservices separately. i.e. start/stop and release new versions of a component without having to bring the whole application down.

With this in mind would the following work:

A single crossbar router instance running without any additional components (except possibly auth).

Then individual components written with Autobahn would connect to that router from arbitrary locations.

So for example I may use a cluster of CoreOS machines. Each component (including the router itself) would be packaged up in a docker container. The cluster would run one copy of Crossbar (until multi-node is released). Then each component would be set to run on a random machine in the cluster, it would then connect up to the instance of crossbar.

  • Can anyone see any big gotchas with this approach?
  • Is this a use case that the dev team envisioned when building crossbar/autobahn?
  • As a slight side question - if an event is published, is it lost if the router is restarted prior to delivery?

Thanks again,

Jon

0 Likes

#3

Hey Alex,

Much appreciated. I guess I should go write some code now instead of just thinking about it :slight_smile:

Regards,

Jon

···

On Tuesday, 9 December 2014 20:52:11 UTC+11, Alexander Gödde wrote:

Hi Jon!

No problems with the buzzwords - we’re thinking about switching from “components” to “microservices” ourselves. :wink:

There is no real difference between the two, and should one moniker get people more interested than the other, then that’s a net gain.

Regarding your questions:

  • I don’t see any gotchas. The only knowledge your microservices need is the IP of the Crossbar instance, so you’re free to distribute as you like.
  • This is definitely a use case that Crossbar & WAMP are made for. The possibility to run components microservices from Crossbar is a comfort feature to make deployments easier, not in any way a requirement.
  • Crossbar currently does not have any kind of persistence mechanism across restarts.

Regards,

Alex

Am Dienstag, 9. Dezember 2014 02:13:30 UTC+1 schrieb Jonathan Moss:

I apologies in advance for the vast number of buzzword in this post…

Firstly Crossbar.io and autobahn look awesome and I can see great potential. So thank you for all the great work so far.

I am looking at how one would compose a large application from independent microservices.

To maintain flexibility I would like to be able to manage those components/microservices separately. i.e. start/stop and release new versions of a component without having to bring the whole application down.

With this in mind would the following work:

A single crossbar router instance running without any additional components (except possibly auth).

Then individual components written with Autobahn would connect to that router from arbitrary locations.

So for example I may use a cluster of CoreOS machines. Each component (including the router itself) would be packaged up in a docker container. The cluster would run one copy of Crossbar (until multi-node is released). Then each component would be set to run on a random machine in the cluster, it would then connect up to the instance of crossbar.

  • Can anyone see any big gotchas with this approach?
  • Is this a use case that the dev team envisioned when building crossbar/autobahn?
  • As a slight side question - if an event is published, is it lost if the router is restarted prior to delivery?

Thanks again,

Jon

0 Likes