Tervela Message Medium Blog

We announced the Tervela TMX-500 Message Switch last week at SIFMA to a great deal of fanfare.  Attendee response to the new offering was entirely positive, many echoing the word “wow.”  We had it running and opened up for all to see. Based on some questions at the show, I wanted to take a couple of minutes to share what was behind the announcement and illuminate our design philosophy.

Planning for the TMX-500 began in 2008, some time after the TMX-1000 was publicly available and in-production at top-tier financial services firms: investment banks, hedge funds, broker-dealers, etc.  We had a good deal of experience to work from.  It’s worth noting that we saw demand for a complementary, smaller message switch from Tervela, so now we offer both the TMX-500 and the TMX-1000.

We run a continual and disciplined product management process at Tervela, one that is very much market-driven.  We spend a great deal of time with customers (business leaders and technical architects), third-party thought leaders, standards groups, ISVs, systems integrators, and perhaps – most importantly – people who would never buy a hardware-accelerated messaging solution.   Over my career, I have found this last group to be a treasure trove of product requirements.  They also, ironically, become the largest purchasing group of the products they say they’d never buy.

So what were the drivers?  What did the market want? What did customers and prospects want?

They wanted hardware-accelerated messaging, but in a smaller form factor that gave them deployment options for workgroups, data centers, co-lo facilities, etc. We brought it down to 2U (1U = 1.75 inches).

They wanted deployment flexibility.  We can multi-home to diverse networks through 16 x 1 Gigabit Ethernet ports or trunk through 4 x 10 Gigabit Ethernet ports.

They wanted to scale linearly without pain.  We can connect 1 to 16 TMX-500s into a single unified fabric.

They wanted to reduce the data center footprint.  Our first TMX-500 customer order reduces 2+ racks of messaging servers by 92% (!) to 5U (2 x 2U TMX-500s + a 1U TPM management platform).

They wanted to cut power consumption, too. The TMX-500 tops off at 250 watts, but runs steady state in the 100s.  This is a big deal.  More on it in a subsequent post.

They wanted real economics.  We gave them great CapEx, OpEx and TCO with the TMX-500.  Software solutions can’t match it.

They wanted the Tervela differentiators: high-performance, low-latency, scalability, and a seamlessly integrated fabric.  We didn’t compromise.  In fact, we made them better.

They wanted insane reliability.  We went solid state, added more environmental sensors, variable-rate N+1 fans, redundant power, ECC protected memory, etc.

They wanted future-proofing.  The combination of programmable ASICs and Tervela’s operating system for messaging, TVOS, ensures future support without any compromise.

They wanted to beat their competition.  We gave them the TMX-500.

There’s much, much more.  Please let me know if you’d like additional details.

Regards,
=rob.ciampa

Tags: tmx-500 (2) sifma (2) tervela (1) 

Comments (0)

Now that we’ve recovered from SIFMA 2009, I wanted to share some thoughts from the floor.  For accuracy, it’s the 2009 Securities Industry and Financial Markets Association Technology Management Conference & Exhibit.  Whew.  Let’s stick with “SIFMA.”

First off, SIFMA 2009 was different from SIFMA 2008, which was different from all other previous ones as well.  That’s how tradeshows go:  each one has a different personality, much like the children in a family.  Fewer attendees?  Yes.  Third floor of the venue closed?  Yes.  But so what?  We knew this going in, adjusted our plan accordingly and had an outstanding event.  What does that mean?  We had twice the number of scoped project discussions on enterprise messaging systems than we had last year.  A 100% increase, not to mention the number of follow-on meetings.  We didn’t have many tire kickers or “tourists” as a press person remarked to me.  Pete Harris from A-Team Group expressed similar positive observations in his recent post.

Next, we didn’t go there half-cocked with a crap booth and no story to tell.  It’s just not our style.  We introduced the Tervela TMX-500 Message Switch, had the hottest booth at the show (literally or pun intended) and staffed it with our team members who do real-world messaging projects.  I’ll save the TMX-500 discussion for another post, but I was either part of or witness to some of the most poignant discussions on messaging philosophy and architecture that I’ve heard in some time.  That’s why we were there.  That’s why people attended.

Finally, what’s the scoop with this “Wicked Hot Message Sauce” theme?  Candidly, it came to me several months ago during an early, weekend morning caffeine infusion at Starbucks.  I was reflecting on a comment made by an IT executive last year about his desire to “spice up” his application performance.  The rest, of course, is obviously history.  I did take some grief from my New York colleagues about the word “wicked” and my inability to stray from my Boston roots.  Frankly, that wasn’t even in the equation.  I used it in the context of something more powerful than “freakin’.”  I’ll close, however, with some of my Bostonian vernacular:  check out Tervela's TMX-500; it’s wicked awesome.

P.S. To all the great attendees, press, analysts, friends, partners and vendors who stopped by our booth:  Thank you for making the show wonderful.

Cheers,
=rob.ciampa

Tags: sifma (2) securities industry and financial markets association (1) pete harris (2) tmx-500 (2) wicked hot messa (1) 

Comments (0)

But it worked in the lab... A deep and profound (please read it a couple of times) post by Kirk Wylie.  He claims that he's not trying to be down on best effort messaging, but he does have some valid points that we often hear from customers.

Here's a quote:

Best Effort = Development Win, Production Fail

 

Because the problem is that Best Effort systems seem much better than that in development. In development, you can run days without dropping a single message, no matter what size it is. In testing, you can run many test iterations without being able to force a message drop [2]. More importantly, you really can't force a message drop, at least not without implementing a lossy Decorator on top of the MOM interfaces. And that's a problem.

Best effort messaging is meant to be fast.  That's good.  But hardware (with some decent architecture) can make guaranteed messaging fast.  Check out our last post.  The reality is that there are many types and qualities of service when it comes to messaging.  Pick the one that makes the most sense for the applications you're running.  And be realistic.  To Kirk's point: a little bit of diligence in the lab will go a long way to avoiding surprises in production.

=rob.ciampa

Tags: best effort messaging (1) guaranteed messaging (2) kirk wylie (1) 

Comments (0)

Guaranteed messaging.  Guaranteed Delivery.  Durable Consumer.  Reliable.  Blocking.  Non-blocking.  Persistent.  Lots of descriptors attached to the concept of guaranteed messaging.

But what does guaranteed mean?  Where do the guarantees occur?  Is it really a guarantee or is it just statistical?  What price must I pay for a guarantee?  What’s my time window for assurance? How different is a guaranteed messaging flow from a best effort flow?  Are there different types of guarantees?

We’ve spent a good deal of time and R&D dollars on guaranteed messaging.  Though we’ve had for some time a guaranteed connected quality of service that seamless overcomes temporary operational issues, we needed something for major outages and debilitating breaks in continuity.  We opted, however, not to cobble something together that would perform like a sick dog and treat the term “guarantee” lightly.  Our base architecture was designed anticipating the need to have multiple qualities of services that were unified, seamless and fully functional.  Guaranteed messaging was not going to incur a tax.

Today we announced our “Real-Time Guaranteed Messaging Service” - but we claimed it was the “Industry’s First.”  Why?  Because it is both real-time and real-guaranteed.  Together for the first time.  What were our objectives?

• Give customers true assurance without the debilitating deficiencies of traditional guaranteed service
• Be the highest performing guaranteed messaging on the market
• Provide true guarantees, not statistical likelihoods
• Scale cleanly from workgroup to enterprise
• Leverage architectural differentiators that our competitors just can’t match

It’s a different market and information is far too important to implement guaranteed messaging the same old way.  It’s all about the architecture.  That's what drives business advantage.

=rob.ciampa

Tags: guaranteed messaging (2) quality of service (1) durable consumer (1) 

Comments (0)

In a previous post, I mentioned the Options Industry Conference 2009.  Given the importance of messaging to business performance, the conference organizers put together a panel on Friday, May 1, 2009 entitled: The Tech Arms Race (Messaging: The Key to Being Faster).  Barry Thompson, founder of Tervela will be speaking, so no doubt it will be pithy, relevant and opinionated.

Tervela is also at the show in Booth E160.  We'll have copies of our latest research and deployments of messaging in the options markets: Options Advantage Through Infrastructure Transformation - Driving Profitability and Market Leadership.  I'll be posting it to the Tervela site soon.

=rob.ciampa

Tags: options industry conference 2009 (2) messaging (4) 

Comments (0)

The Options Industry Conference 2009 begins today in Florida.  What I like about this event is that it's a great venue for looking at the business and technical aspects of the razor's edge in financial services: options processing.  One of our hedge fund customers summed it up best:

You can't approach options processing with an equities mentality.

I have corollary:

You can't approach contemporary data-intensive business challenges with a legacy messaging middleware mentality.

Some other thoughts:

New business demands and archaic messaging systems.  Massive growth in options market data, amplified by greater order processing and algorithmic demands for low-latency and fan-out are crippling messaging systems, resulting in lost data, information slippage and system failures.  These all equate to position and market exposure.

More complexity = more risk.  Disparate systems drive complexity and, ironically, impact other systems.  Problems in one area frequently affect other areas, making the tuning and debugging complex and dangerously time-consuming.  Because these systems are so tightly-coupled, recovery becomes non-deterministic and predictability goes away.

Adding more resources doesn’t solve problem.  In fact, it creates more problems with complexity, rack space, operations, and cost.  This is the old model: throw more systems at the problem; partition the symbols even more; add more routers and switches; and hope it improves.  The net result is more stuff to manage and more things to go wrong.

Manageability is not an option.  Lack of control and visibility is a legacy shortcoming of traditional messaging systems.  Not having the insight in the critical messaging function is an unacceptable excuse when a firm is out of the market.  You can’t manage what you can’t see.

=rob.ciampa

Tags: options industry conference 2009 (2) messaging (4) options processing (1) messaging middleware (1) 

Comments (0)

So here we are sitting on the dock, watching the sunset and reminiscing about the good old days of Lehman, Bear, and - geez - even Madoff.  We watch the tide go out and get lost in the moment.  In the old days, this would be a full page ad in some retirement magazine.  (Given the state of our 401(k)s, we'll probably have a walker next to us on the dock.) Suddenly, the wind changes direction and the tide starts coming in, awaking us from our respite.

Like the tide, the market is now coming back and firms are suddenly awakening and taking notice.  This time, however, it may be a rather high tide.  Many firms that we work with spent the past several months making some much needed architectural and infrastructure changes - fixing up the dock if we follow our coastal analogy.  Other organizations, well, find themselves a bit behind after wrestling with budget and all sorts of other organizational issues, some of which now seem to be abating.  They must be careful, though, not to find themselves caught off guard, sitting on a distant sandbar while the tide rushes in.  Perhaps it's time to look for a quick return to shore.

I'm not sure what prompted this beach imagery; perhaps it was the unseasonably warm weather in the Northeast these past few days.  I do, however, blame Melanie Rodier and her recent piece "Financial Firms Face Massive Market Data Infrastructure Challenges" in Wall Street & Technology for the tide analogy.  She couples her journalism with some recent research by Adam Honoré at Aite Group.  Here is a snippet:

Market data volumes are expected to continue to grow exponentially, further straining market data infrastructures, according to a new report from Aite Group.

 

If U.S. equities message volumes continue to grow at their current pace, they should average 1.2 billion messages per day by 2011, the Boston-based firm said.

 

Storing all Level 1 and Level 2 data for U.S. equities is approaching a requirement of three terabytes per month.

 

For all asset classes, across U.S. market data rates, data volumes nearly doubled on an annual basis over the last two years.

We'll shortly see if the tide hits the seawall.

=rob.ciampa

Tags: market data (4) melanie rodier (1) wall street & technology (3) adam honoré (1) aite group (1) 

Comments (0)

We recently made an announcement about our joining the Advanced Message Queuing Protocol (AMQP) working group.  For anyone who has worked with standards bodies, this may be akin to a B-grade soap opera sprinkled with politics, protagonists, antagonists and an ever-changing plot line.  I’m sure there will be some of that (though there are some great people involved), but our focus is on the end game: fundamentally changing middleware.  AMQP represents a movement in that direction.  Like comparable endeavors, this is and will be a continual process.  Expect more changes as companies adopt and AMQP is road tested, which, of course, is a normal part of the process.

We’ve made the case here many times against legacy messaging architectures, but it’s just as true with their queuing system alter-egos.  We also continue to argue that messaging has to go through the same critical transition to hardware as network systems did.  AMQP (no pun intended) is queued up for that.  The biggest challenge is not whether adoption will occur, but how quickly it will happen.  That’s an important variable.   Hyper-efficiency and blazing speed may well be the recipe for faster market adoption, but it’s going to take some hardware acceleration to bake it.

=rob.ciampa

Tags: amqp (1) queuing systems (1) middleware (2) 

Comments (0)

Recently, I had the opportunity to attend the quarterly Financial Information Forum (FIF) event entitled “Doing More with Less” at Thomson Reuters in Times Square in New York.  The session opened (in typical FIF fashion) with market data statistics, which were presented by Chris Perry of Thomson Reuters and Manisha Kimmel of FIF.  Recession aside, we we’re still seeing impressive market data growth.  (Can someone please tell the market we’re in a damn recession and stop producing so much data?  Kidding, our course.  We at Tervela thrive on this.)

The follow-on panel was moderated by the esteemed Tom Jordan, President & CEO, of Jordan & Jordan.  Practitioners in the hot seats, whom I compliment on their honesty, included:

• Brett Redfearn, Global Head of Liquidity & Algorithmic Trading, J.P. Morgan
• Madalena Sheehan, Executive Director, Global Wealth Management, Morgan Stanley
• Dan Weingarten, Senior Vice President and Co-Director of Global Sales and Marketing, Penson Worldwide

My takeaway was about efficiency: in how we operate, in how we process data, in how we work with our partners, in how we continue to make our customers happy. Though certainly an important tactic, I’d much rather be an organization that’s already up the efficiency curve.   As AIG and GM are proving, it’s not a great time to retool.  But we also heard how volatility and increasing volumes are having an adverse effect on trading systems.  The panelists described the unerasable link between business and technology.  They discussed their concerns about the risk of technical outages.  Think about the link:  technical outage = business outage. Obvious?  Of course, but just make sure your movement to efficiency doesn’t leave you vulnerable.

=rob.ciampa

Tags: financial information forum (2) fif (1) jordan & jordan (1) market data (4) efficiency (1) 

Comments (0)

The latest issue of Wall Street & Technology (January/February 2009 Issue) came late.  I thought I was dumped because I was honest on the subscription and didn’t say I was buying $3.2 billion of Complex Event Processors.  Regardless, the current issue features a special report on “The Modern IT Organization.”  The lead article and the supporting pieces are a very good read.  There is a good deal of ink on cloud computing, but my comments on that are for another day.  In the meantime, the intro quote was telling:

For the first time in recent memory, senior technology leaders’ No. 1 mandate is not to build technology to prepare for business growth.  Instead the top IT priority across Wall Street is to manage technology efficiently.

But…  having just read the 2008 Financial Information Forum year-in-review that showed the market data for EVERY asset class increasing, I have to wonder whether we’re setting ourselves up for a market data crisis.  Not sure the cloud computing junkies are going to give us a sunny day on that one.

=rob.ciampa

Tags: wall street & technology (3) it (1) cloud computing (1) market data (4) financial information forum (2) 

Comments (0)