We’re bringing sexy (to the) back (office)
For the last few decades, from the early days of Gordon Gekko and Liar’s Poker to today’s focus on hedge funds and high frequency trading, the sex appeal has clearly centered around the front office. The press loves to write about it and we love to read about it. Every trade is like the proverbial iceberg, though — the trading decision is what everyone sees, but the majority of work happens in the murky waters below the surface where the considerably less sexy mid-and-back-office operations occur.
Last week Greg MacSweeney wrote a good article in Wall Street and Technology highlighting the back office as a new battleground for efficiency. After years of chasing zero latency for the front-office, the back office is comparatively archaic and badly in need of updating.
Read more
Working on basic sharing skills
In a blog post this week, Lori MacVittie talks about, among other things, the reluctance of different groups towards sharing infrastructure. From her post:
Some pieces of infrastructure – particularly those that are part of the network – are so critical (and so very underappreciated) – that they simply cannot be exposed to the kind of risk that comes from “sharing” resources in any model.
I can’t say her never ever kind of experience matches with what we have seen with hardware middleware. When it comes to sharing, our customers fall into two main camps:
- Those that re-buy gear for each major business unit because of concerns over traffic from one interfering with another. This is how they have always deployed software, and they’re not ready to do it differently in hardware. It has more to do with CYA than technology, which is consistent with Lori’s point.
- Those that are blending market data for many asset classes (across departments), and/or a combination of market data, order routing and risk management in the same infrastructure. Generally the motivation is reducing costs, but it can also reduce risks when the shared environment is both faster and more stable than the standalone software it replaces.
When people start to think of hardware middleware infrastructure as similar to their IP network infrastructure (which they almost always share across divisions and applications), many of the walls put up during the software era come down pretty quickly. The biggest reason people hesitate to share is, as Lori points out, fear of figuring out what happened when there is a problem or outage. The reality is that hardware infrastructure provides more visibility, not less, since stats tracking and logging are done in parallel without impacting performance. This level of visibility (which they are NOT getting in software) is key to establishing confidence that consolidating middleware does not increase risk.
I agree with Lori that many firms are not ready to hand over critical functions to the cloud where what is happening is truly smushy, but when the firm owns the specialized hardware, and can confidently manage traffic flow, sharing infrastructure is increasingly happening today.
The world’s only hardware Market Data Factory
Today Solace announced a partnership with BCC Group International, headquartered in Frankfurt, Germany. BCC has selected Solace’s message routing technology to power their Market Data Factory, a powerful solution that offers their customers greater independence from market data suppliers and lowers risk. As part of the agreement, BCC will also resell Solace equipment to European customers of their Market Data Factory.
We are delighted to add BCC Group to our growing list of partners.
An emergency response demo that was a real train wreck
Standards body meetings aren’t usually all that exciting, but last week’s National Information Exchange Model (NIEM) Training Event and OASIS Emergency Management Interop was an exception. The centerpiece of the Interop was a demo designed to show how NIEM, Common Alerting Protocol (CAP) and Emergency Data Exchange Language (EDXL) standards could help a dozen government agencies share information and coordinate activities in a set of simulated emergency situations. The three scenarios were a train crash/chemical spill, a tornado warning, and an Amber Alert. Not your typical dry standards body fare!
Read more
Trading microseconds for nanoseconds
The co-location of market data systems near or inside exchanges is becoming big business. The ultra-low latency high frequency trading systems that you find in these facilities are niche applications to be sure, but what a niche! NYSE Euronext recently committed to build a 400,000 square foot co-location facility in New Jersey. That’s a big investment to make in something NYSE Euronext CEO Steve Rubinow describes as being for “only the most obsessive traders.”
How obsessive? Architects building these systems measure latency in microseconds, and the best applications exhibit just tens of microseconds of end-to-end latency. Shaving microseconds is like dropping weight before your prize fight weigh-in—whatever it takes, get it down.
To help these latency obsessed traders develop even faster trading systems, Solace has extended its Unified Messaging API to include a shared-memory transport based on inter-process communication (IPC). This capability lets two applications share information using Solace’s API with less than 700 nanoseconds of average latency in a shared memory environment. Yes, I said nano — billionths of a second. Remember the famous Tabb Report on The Value of a Millisecond? There are a million nanoseconds in a millisecond. 700 nanoseconds is a scant seven-tenths of a microsecond.
To be clear, IPC is a highly-specialized technique that only certain systems can leverage because it occurs within the confines of a single server. For example, when the components of a high-frequency trading system (feed handler, algo, risk assessment, order execution) have been consolidated onto a high-powered multi-core server within a collocation facility. Today these applications run on many machines and share data using low latency messaging (like Solace’s). Shared memory transport among applications running on a single server eliminates the few microseconds associated with network hops and additional time lags associated with copying memory around between applications. And since IPC is now available as part of the same API customers already use for ultra low latency and other kinds of messaging, applications get the speed they need without giving up the familiar API or the flexibility to redeploy in a networked scenario as needed.
As always, we’re not publishing some mysterious single number with no detail on what it means. A white paper describing the environment and parameters of the tests is available for download on our website so customers can dig into the facts and even reproduce the results using their own systems and data. In fact, we did all the testing a quad-core 3GHz Intel Xeon E5450 server because not everyone has the latest Intel Nehalem.
HFT architects have generally been exempt from corporate technology standards because the stakes are so high they can justify whatever makes them faster. With Solace, HFT no longer needs to be an exception. The same messaging API that is speeding up back office and front office networked trading can be used to speed up collocated HFT trading as well.
Giddyup, JMS!
Think of the lowly workhorse, toiling away while his cousin the thoroughbred races to fame. Much like that workhorse, Java Message Service has been relegated to the less sexy applications in the middle- and back-office (such as routine communications between applications and databases, especially in SOA environments) while the high-profile applications where volume and/or performance are critical (such as low latency market data systems on Wall Street, and event networks in many other industries) are handled with specialized, proprietary messaging solutions.
Many people have JMS pigeon-holed as being just for these relatively simple, low-volume tasks because while it’s very easy to set up, its performance is relatively limited. You can always scale JMS by splitting the workload across dozens or hundreds of servers, but that introduces major architectural complexity, administrative nightmares and high TCO. That simple JMS deployment is no longer so simple.
Solace recently announced a new version of its JMS broker that has the horsepower to support enterprise-scale applications in a purpose-built appliance that’s easy to deploy and has a small footprint in the datacenter. Each Solace message router (just 4 rack units high) supports 100,000 persistent JMS messages per second, and 11M non-persistent JMS messages per second (for example 5.5M in and 5.5M out, or 3M in and 8M out in a pub/sub configuration). Best of all, each Solace message router can handle high volumes of persistent and non-persistent messages simultaneously.
Throughput of 11M messages per second allows JMS to be considered for some of the largest event networks in the world with a single fault-tolerant pair of Solace routers. This will dramatically reduce the effort it takes to architect and operate large JMS networks. This kind of volume is useful when you have a very high powered application, as described above, but also when you need to connect thousands of applications that each have a moderate amount of information to send. At these kinds of volumes, thousands of clients could each consume thousands of messages/second and still have headroom on the router.
It’s time for the workhorse to get some time on the track.
Solace and Sun collaborate to simplify financial networks
Many people think Sun Microsystems is in limbo—stuck between the company they were and what they’ll become as part of Oracle. Competitors have suggested that Sun has stopped innovating and that it’s time to move to another platform. But as a close partner of Sun’s, I can assure you that the picture inside Sun is very different. Their best minds are still generating great ideas, solving customer problems and pushing the boundary with innovative new technology. Some of you may have seen Oracle’s recent ad in the Wall Street Journal (and many other places) declaring that they are looking forward to taking on IBM head on in the hardware business.
Solace signed a partnership with Sun shortly before the Oracle acquisition was announced in the spring. Sun’s technology assets and Solace’s high-performance JMS solution have generated interest with Sun customers since we began working together more than a year ago. Sun is a powerhouse in the data center of many of the country’s largest, most demanding companies, including most of the major banks. For our part, Solace is reshaping what has traditionally been software-based middleware into a hardware asset more like a network appliance than a server.
The combination of these two strengths is the basis of a new prototype appliance we demonstrated in the Sun booth at the SIBOS show in Hong Kong September 14-18. This new Sun financial network appliance combines the massive throughput and easy management of Solace’s messaging technology with Sun’s hardware and software to build a flexible solution for integration between back office banking systems and leading payment networks. Integration with payment systems is a notoriously complicated thing to get right, and the turnkey approach of this appliance can make connectivity faster, easier and more profitable for participants of banking inter-networks.
The appliance is based on the Sun Netra x4450 chassis, a powerful virtualization server that’s designed for telco-grade reliability in a low-power 4U form factor. It includes Solace’s JMS broker and middleware functionality with appliance-style turnkey administration. Finally, it includes Sun’s Secure Network Layer software as well as the Sun Integrator platform for easy integration of banking assets.
In related news, Solace announced a new version of our JMS protocol that’s used for this appliance, and is also available directly from Solace. It sets new standards for JMS performance with support for 100,000 persistent and 11 million non-persistent messages per second.
We look forward to a long and successful relationship with Sun (and eventually Oracle).
News on news: products, partnership & standards
This has been a busy news week for us, as we released information about two exciting product developments and a project that we’ve been hard at work on with Sun Microsystems. For good measure, we were included in a fourth announcement issued by OASIS. Below is a summary of the four pieces of news. Watch this space, because we’ll be posting more information about all of this news over the next few days.
- The release of new benchmark data showing our JMS broker to be the world’s fastest.
- The addition of shared memory IPC transport to our Unified Messaging Platform API that brings performance into the world of nanoseconds.
- A announcement with our partner Sun to demonstrate an appliance for inter-bank connectivity.
Finally, OASIS (the Organization for the Advancement of Structured Information Standards) just announced that we’ll be participating in a joint demonstration at the upcoming Emergency Interoperability Summit in Baltimore.
The Inevitable Convergence of Middleware into the Network
Today in New York our CEO Craig Betts co-keynoted the High Performance on Wall Street conference with Andy Bechtolsheim and a representative of Barclays Capital. The theme was something we talk about a lot at Solace: the convergence of middleware and the network. The need to effectively route an increasingly massive volume of data at high speed is defining competitive advantage in more and more situations. The only way we’ll ever address this trend is by making the intelligent routing of messages a robust and readily-accessible service of the network, just like the routing of IP packets. We can only shove so many servers into the increasing number of holes in the dike before the water pours through.
Craig talked about the 4 key business drivers of IT innovation today (the need for speed, the need to save, the desire to be more environmentally sensitive and the need to stay productive through M&A activity) and how they all lead down this path of convergence. Mr. Bechtolsheim dove a little deeper into the specifics of network architecture and operations to illustrate the point that raw computing power isn’t the way to crack this nut. Finally, Barclays Capitals’ head of middleware talked about the business value of consistent, predictable performance which drove them to select a (ok, our…) hardware-based middleware platform.
From business drivers, to nuts and bolts, to the bottom line, the presentation made it clear that the migration from old-fashioned software-based infrastructure to hardware is a fundamental corner we must turn.
Datamonitor report on messaging
Rik Turner of Datamonitor has released a very thorough report on the messaging space, keying in on the hardware vs software approaches. He does a nice job of representing the position of many vendors and summarizing their offerings. In the report, Rik covers network processors, FPGAs, RDMA/LDMA, TCP accelerators, OS context switches and more.
I don’t agree with all of his opinions, but IMO it’s a far more meaty, solid piece of work than most analyst reports.