Take a regular FIX implementation within a sell-side or buy-side. The previous post in this series here included a description of the environment.
Within that reference implementation was this item:- FIX engines communicate via some message oriented middleware to the order management system.
This post will look at that part. This blog has looked at middleware before here so this does not have to display my "War and Peace" tendencies...
So, in many implementations I have seen there are clusters of servers running middleware, clustered to provide scale and resilience.
The issue is that all of these middleware servers will:
- require datacentre rackspace (charge by the unit or rack)
- require cabling
- require management via NewRelic, Nagios, Splunk, ITRS etc.
- draw power
- require dual power supplies for redundancy
- require SSD or other fancy memory to keep performance up
- require periodic upgrades of the middleware version
- require periodic upgrades of the underlying OS
- require full regression tests of the application stack each time there is a middleware upgrade or upgrade of the underlying OS
While free and open source software is often great, a wise business manager looks at the total cost of ownership rather than simply the license costs.
This is why I believe that when examined holistically the answer is hardware based messaging. An interesting (albeit sponsored and somewhat old) case study is here.
I know of two publicly available hardware based middleware tools - Solace Systems and Tervela. There are others that are internal builds within vendors and some banks but since they are not publically available they cannot be considered here.
So - how do you save money by spending money on fancy hardware? Simple - you can use the hardware device to replace a software/hardware stack. Consider the TCO for a hardware messaging device stack that implements a nice set of APIs:
Tervela
- Java
- C
- C#
Solace Systems
- C
- Java
- JMS
- .Net
- JavaScript
- HTML5
- ObjectiveC
- Silverlight
- ActionScript
Then consider how many middleware layers can be decommissioned within your firm if you employ this sort of hardware based device. Not just the layer connecting the FIX engine to the OMS. Consider:
- web streaming for connected devices using node.js/COMET/ajax.
- OMS to back office messaging.
As always, establish the costs and benefits, risks and rewards of each option and I think it's clear that - at the right time - the switch to a hardware based middleware layer can be a winner.
And here's a picture:
