Entries by Shawn McAllister

How can I integrate Solace with my IBM Environment?

Businessman writing complex organisation structure on screenIn addition to supporting high performance applications like trading platforms, online gaming systems and real-time big data environments, many of our customers use our message routers to make enterprise messaging available “as a service” to scores of applications throughout their business. Doing so helps them reduce the cost and complexity of their infrastructure while making it more robust and easier to manage. More of these clients have been asking one particular question lately: “I like this messaging as a service platform, but what about my existing IBM infrastructure – how can you help me with that?” Good question!

I’ve also been engaged with several clients who want to upgrade their messaging fabric as part of moving their ESB to open source products like Mule ESB and JBOSS Fuse, or add Big Data analytics to their architecture. These clients had similar questions as to how to integrate their existing IBM WebSphere infrastructure with these new systems.… Read the rest

Introducing Solace 3500 Series and SolOS 7.0 — Many Big Steps Forward

3500-series-blog-post-featured-picToday is an exciting day for us at Solace, and for our customers. This morning we announced a huge step in the evolution of our products with so many improvements – most of which would be big news on their own – that I don’t know where to start. There’s something big for everybody in this release, from architects to developers to your CIO!

It was tough, but I picked my four favorite features to talk about today:

  • Less is more. First off is our new 3500 series message routers, the Solace 3560 and Solace 3530, next-generation versions of our Solace 3260 and Solace 3230, respectively. The Solace 3560 provides the same performance as our old top-of-the-line 3260 chassis in half the space (2 rack units vs. 4), effectively doubling throughput per rack unit. For customers who have lots of message routers and those who use them in colocation centers, this shrinkage is very welcome.

Read the rest

Investment Banking and the Middle Office Shock Absorber

Equities trading is the poster child for applications that demand the distribution of lots of data with extremely high performance – latency in the low microseconds, reaching for nanoseconds, and with as little “jitter” as possible even through unpredictable bursts of trading activity. But when it’s time to send order and trade data to the middle office systems responsible for non-real-time functions such as risk management, OATS reporting, etc., the prime directive shifts from speed to certainty. Every single message must be delivered to lots of recipients, many of them slow consumers, without putting “back pressure” on high-speed front office trading applications. This is why equities trading and OMS systems need a shock absorber.

Ever since algorithmic/electronic trading revolutionized capital markets, the “need for speed” has driven the development of networking technologies like cut-through Ethernet switches and 10 GE NICs that support kernel bypass, and encouraged techniques like running multiple apps on multicore servers with overclocked cores.… Read the rest

Is It Time to Rejuvenate Your FX Trading Infrastructure?

A common theme I hear from many senior IT people who run FX trading platforms is how the priority of rejuvenating their FX infrastructure is increasing. Why now? All of the big investment banks and FX ECNs have operated electronic FX trading platforms for some time now — since back when much of the trading demand from their clients wasn’t electronic, which meant latency requirements weren’t that stringent and peak volumes weren’t as high as they are today. There were also fewer sources of liquidity, less sophisticated trading capabilities, a lot less regulation to worry about, and corporate risk officers pretty much left them alone.

Many of these platforms used (and still use) several different types of messaging systems to do what they needed: multicast for price distribution, software brokers for persistence, and web streaming software if they wanted to offer a single dealer platform (SDP). So the infrastructure started off complex, which doesn’t help application architectures stay simple, and we all know that over time architectures grow more complex until there is a dedicated effort to simplify.… Read the rest

Why Horizontally Scaling Message Brokers isn’t All it’s Cracked up to Be

When it comes to increasing the capacity of IT systems you can either scale “vertically” by increasing the power or storage of a given device or piece of software, or “horizontally’ by adding new devices or instances of that software.

interbroker-comms-diagramOne of the biggest problems with increasing the capacity of a software-based messaging platform by adding brokers is the communication that inevitably needs to happen between brokers. When clients or applications connected to one broker need to communicate with an application that’s connected to another broker, you end up sacrificing some of each broker’s capacity to that inter-broker traffic, leaving less available for client communications. In fact, this problem increases exponentially as you add more brokers, so the return you get by adding each new broker is less and less.

focused-overload-diagramThe next challenge that IT personnel face when horizontally scaling software-based message brokers is that of capacity planning. With discrete message brokers serving unique sets of clients and instances of applications, each broker must meet the demands placed on it by clients and applications alike with its own available capacity.… Read the rest