Clustered Event Bus vs HTTP microservices

[ad...@cs.miami.edu]

It seems that vert.x has two primary features to expose micro services over jvms on different servers: [1] Clustered Event Bus or [2] HTTP rest-type services. I know vert.x is not opinionated, but I was wondering if there are any thoughts (or docs) to suggest when one type of micro service is better than another? 

Here is what I have so far

HTTP pros:

1. simple to set up, no extra config necessary

2. Easier to introp with non vert.x consumers.

3. Out of the box security with ssl

4. Perhaps a less chatty protocol? (not sure about this)

Clustered Event Bus pros:

1. a more unified style across services

2. do not need to know in advance “where” the service is (as opposed to a URL), instead just pub/sub

3. The event bus has a pretty high fun factor – actually pretty important for programmers :)

Any thing else I might have missed?

Another idea is to always use the event bus to access a service, but a local handler will keep track of where and what type of service it really is – and route to either a local service on the event bus or to a http service. This can be all abstracted away, and would seem to the end programmer that everything is going off the event bus. Perhaps this is already a feature?

[Clement Escoffier]

Hi,

Message-based interaction (on the event bus) and REST are two ways to transport messages and so to interact. You characterization is quite complete. Let me add a couple of points.

SockJS Bridge

If you have to implement some “realtime-web stuff”, there is a bridge that let your browser interacts with the event bus. It can receive messages, but also send messages. It’s a bit like having the browser as a member of the cluster. SockJS degrades automatically to meet the browser features, so no need to deal with the browser fragmentation.

Service proxies

You can expose services on the event bus, and consume them. It implements a RPC protocol. Yes, RPC is not hype or sexy, but it has several advantages here: 

* Contract - the service is defined using a Java interface, and the client uses this interface. So, it’s easy to use, and introduce a kind of type safety.

* SockJS proxy - based on the sockJS bridge mentioned above, we also generate clients that let your browser consumes event bus services. 

REST

REST requires to have modeled your domain as a set of resources, with atomic actions. It is not always possible (easily), and may require convoluted ways when you need to orchestrate several actions. However, REST over HTTP is:

* Independent of the platform - it can be consumed from anything. While the event bus has also this possibility, you would need to build clients for the event bus. 

* Well-understood by anyone - it’s so common that everyone understand what it means

I don’t think that one is better than the other one. It really depends on your application, and actually I believe that (large) application would mix both to always use the most appropriate one. That said, there are other interaction styles that may be useful too such as data-flow (pipe and filter, batch, streams), data repository and so on. 

Clement

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/8e14ad23-d71c-410a-a384-7e7e3323cb6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Arnaud Estève]

I'd clearly go with service-proxies (thus the event-bus).

This way you're designing micro-services by contract and developpers don't even need to know if the implementation of the micro-service they're using (the class implementing the interface to speak "code") is accessed locally or through the event-bus, whether it's there on the local machine or on a distant computer across the cluster. All they need to know is that the service is async.

That's the best way you can scale, splitting your whole architecture across a cluster.

REST will still be there if you need to expose your service say, to 3rd-party companies/developpers. And still, you can expose the EventBus primitives through a REST wrapper (which should really be a thin wrapper essentially designed to control access).

Service-proxies are a major feature of vert.x for me. That's a very nice implementation of the word "micro-services".

[dekst]

vertx1                                 vertx2

verticle1.1                          verticle

handler1  handler2             publish
     |                |                         |
--------------------------------------------------

vert.x2 publish a message,  handler1 and handler2 will consume the message.

If we duplicate verticle1.1 (setInstances(2)) on the same machine, does it mean that we have 4 handlers that will process the message?

If we duplicate vertx1 on another machine, does it mean the message will be processed on the two machines?

How to use the clustered event bus for micro-services? When vertx2 publish a message, it shall be consumed by only one pair of (handler1, handler2), like a load balancer only routes a request to one server. 

[Potter Dai]

You should use send instead of publish. Then vertx will automatically pick up a vertx worker for you.

[dekst]

Thanks, PTD!

Then it means there are rare cases that we use pub/sub because we usually need to scale up.