Corporate World Technology Choices – Last Mile Mesasging
The choices we make around the technology stack used in solving business solutions – what languages, what OS, what IDE, what framework, what architecture etc – are based on our (often limited) view of the world, coupled with what projects we have worked on before, “noise” on the street, and finally our bias view (a human characteristic) of technology. Technology bake-offs can sometimes assist in understanding the pro/cons prior to embarking on a full build of an application to solve a business problem. However, bake-offs can like many things, be bias unless kept in appropriate check. Web data push technology is one area where there appears to be a good degree of bake-offs run. This is possible due to the growth in this area of applications leveraging push data over the web – especially true in the Single Dealer Platform (SDP) space.
Node.js vs *choose your last mile messaging product* is a common debate these days. Drew provides a Socket.io benchmarking view and framework which offers some interesting data points. my-Channels.com Nirvana offers its own view on benchmarking. If you throw in Lightstreamer and a few other paid products, coupled with maybe Caucho Resin, you soon realise that you can’t compare published benchmark, and hence you are back to a bake-off.
So where am I going with this posting? Well, in a nutshell, make sure you understand the use cases prior to selecting your technology stack to solve your business problem. A combination of OS and paid product maybe the solution, but make sure you compare apples with apples. my-Channels.com for example offers some nice fail-over features, but you need to paid for the product. Node.js will possibly require you to write more code to cover the fail-over use case (maybe using Redis).
Hi Matt,
In my post “The Five Key Metrics of a High-Performance Comet Server” available at:
http://cometdaily.com/2011/01/17/the-five-key-metrics-of-a-high-performance-comet-server/
I tried to explain why several metrics are crucial for a push server. The proposed metrics are simple to understand and can be easily used for apple-to-apple comparisons from a performance perspective.
Based on such metrics I think benchmark comparisons are possible even for the published benchmarks.
Also, the comparison is more difficult if performance comparison is mixed with feature comparison.
You mention a fail-over feature and some extra-code to add to achieve it. I think this is more easy to say than to implement. While we at MigratoryData spent a lot of effort to implement a high-performance push server. The whole spectrum of fail-over we had to implement for Migratory Push Server — including clustering, load balancing, fault tolerance with no single point of failure, guaranteed message delivery, atomic broadcast publication to a cluster of push servers — is by far something very hard to implement, maybe it is as difficult as implementing high performance.