Polyglot is a distributed web framework for multiple programming languages
github.com
github.com
Alrighty then. Someone has never scaled RabbitMQ vs. a basic HTTP service. If raw scalability is what you're looking for w/ a polyglot backend, an edge service that accepts HTTP and turns those requests into Thrift structs (or similar) to RPC to various polyglot services might be better for you. This is the model most use.
However, I'm unsure how this'll be more 'performant' than picking the right technology from the start and architecting wisely. Generally, the more performant you want something to be the simpler you build it and only compromise where necessary. Thrift/RabbitMQ are definitely complexity compromises.
Complexity is the bane of scalability.
Additionally, if you needed pure scalability, you generally have purpose-built services for each "responder" which is load balanced over. Pretty similar to this, minus the message queue.
I imagine having a message queue in the middle of your HTTP response path could lead to some nasty latency spikes too. Much better to drop a request with a 503 than have the next N spin for minutes while workers chug through it. Especially if you're taking in 10K req/s.
Last thought: The benchmarks are lacking detail, could use a more thorough job.
It's not clear exactly what functionality Polyglot provides beyond, say, raw RabbitMQ, but if it can find a way to encode best practices in a service-oriented architecture it could be a handy tool for developers going through this process for the first time.
A request is turned into a JSON message pumped into a queue with a signature declaring the type of message it contains, service discovery reads from the queue and allocates a service to handle it, shuffling it onto another queue (and if necessary spinning up the service). The service picks up the queued item, processes it and hands it back where the new message may be the response (in which case it gets handed back) or another service call (in which case discover the handler and assign it to a queue).
It's SOA based on messaging and a basic pipeline. Except they don't call it that.
Thankfully the applications in question do not have low response time as a core criteria.
That way you can leverage any existing language frameworks and run them as standard HTTP responders. No need to work with a queue (and add it to the stack).
You can still limit the HTTP methods each proxy responds to as well [2].
[1]: http://nginx.com/resources/admin-guide/reverse-proxy/
[2]: http://stackoverflow.com/questions/8591600/nginx-proxy-pass-...
The rest of the web works on "push" too; pull in this case would only help if you don't care that a request could take a long time (seconds) to resolve.
I didn't see mention of it, but what happens if a message is not responded to? How does Polyglot handle time outs?
These are not common/generic use cases but would be useful under particular circumstances.
* I could be wrong with (3) -- I'm not very experienced in reverse proxies.
It wasn't quite dynamic (it required an engineer to set new values for how many workers you wanted..) but we could do this via a GUI.
For (1) what do you do with the persistence? A web request, in general, is not important after a few seconds.
For (2) how does Polyglot accept multiple responders for a single request, and how would it join the responses?
The implementation today is as a task queue which removes the request from the queue once a responder acknowledges, but it could be a pub-sub model, where a number of independent responders can work on the same message in parallel, and only 1 responder need to return a response. In this case, persisting in the queue is useful.
An alternative is to chain the responders where one responder can leave a message in the queue for another responder, and the final responder returns the response.
Polyglot is still experimental though, and the current implementation is a prototype.
It's basically a reverse proxy that speaks to upstream application servers using a custom protocol over ZeroMQ instead of HTTP over TCP? Why is this better than just using HTTP?
Does anyone here use Mongrel2? Do you like it?
> Why is this better than just using HTTP?
In SOA most of your services aren't going to be exposed publicly. HTTP is a great protocol for public facing servers, but HTTP is a very clunky protocol. For private services, it's a pretty big benefit (performance, scalability and ease of parsing) to skip HTTP and use something else. ZeroMQ gives you several messaging patterns that you would never get from HTTP.
Persistence? Makes no sense for web traffic. Even if the message is persisted to disk, it's useful for a few minutes at most before the user gives up and closes the tab.
Language-independence? You don't need a message queue for that. You can do that with regular HTTP.
Scaling and load balancing? Ditto.
Especially in the Java world, where Jackson + Afterburner is fast enough for most cases. Protobufs/Thrift will smoke it in most performance tests, true enough, but when you're waiting on a database or algorithm to run, what's JSON serialization?
There's certainly benefits at extreme scale, but not enough to justify the loss of tooling that comes with it until necessary.
At least in Ruby world, we steal Mongrel's parser over and over and over and over. Seems like it might be easier to not have to do that, and just use Mongrel2 with a 0MQ library. I haven't actually done this, though...
ZeroMQ is an improvement over plain HTTP primarily because you can use fewer internal pipes by interleaving requests and responses over the same sockets.
We even created a HTTP over ZeroMQ spec to help standardize this approach: http://rfc.zeromq.org/spec:33
To be honest I've not actually benchmarked anything comparing the throughput of an efficient fd poller to multiplexed pipe. It just feels nice to avoid the problem, considering what kind of effort can go into those pollers.
Some discussion from Zed about fd polling: https://web.archive.org/web/20120225022154/http://sheddingbi...
Message queue based load balancing.
Also dynamic load balancing without restarting any daemons.
...wait, what? I don't see how this solves anything. It's like asking American schoolchildren to learn English, Russian, and Chinese before doing math. Makes no sense.
So this may be a nice learning exercise.
With Polyglot are there standard SDKs for responders or acceptors?
I think we should relate this to that ocaml mirageos thing and the idea of a common knowledge representation for program generation. I think pattern with queue has a fairly close correspondence with some common OOP patterns.
We are repeating the same patterns over and over in different contexts for different applications. I think that we have semantic representations and programming languages that if we created a good common dictionary and referenced that rather than restating everything I different forms then we could get much better code reuse.
"2. Message queue
"3. Responder"
So, a SOA?
My first thought when I read the article was "Did he just reinvent the wheel?"
It's in Go so that's kind of neat.
Mine used a node proxy instead of a message queue, but same basic idea. It makes scaling and changing languages so much easier.
Really, the trick is having a standard message protocol that everything abides by. Once you have that, building a proxy and frameworks around it is pretty trivial. I chose something similar to JSON-RPC and for what I wanted/needed it worked well.
It never saw any kind of scale, but it was a fun project.
However this is a bit like a reverse proxy that load balances many different web apps. You could have different applications written in different languages serving requests to the same url.
Furthermore I don't see anything here that load balancers haven't done since the '90s. Maybe I'm missing something but maybe that's why everybody is puzzled.
RabbitMQ is a "batteries included" solution. ZeroMQ is a roll your own sort of library. If you just want a message queue use RabbitMQ. If you want to build your own message queue system (with complex or specific requirements) use ZeroMQ.