Check out our Message Medium blog to find out what’s going on in the hardware-accelerated, low-latency messaging world.
February 26, 2009 at 1:30 pm
Hardware-accelerated messaging is now in fashion! It’s the new black!
I’m impressed by the recent rash of announcements on hardware-accelerated messaging, FPGAs, etc. I decided to let the noise settle down before I chimed in, so now is a good time to look under the covers of this very intriguing topic.
As the innovators in this market, Tervela would like to share a dirty little secret about hardware-accelerated messaging: it’s all about the ARCHITECTURE you accelerate. Unfortunately, architectural deficiencies in performance abound in message-oriented middleware, queuing systems, ESBs, EAI, etc. It’s even in networking. In doubt? Ask any competent IT architect about requisite data flows and handshakes necessary to post a single event. Ask a network engineer about the joy of IP multicast management in an environment where it’s actually used by applications, not just routing protocols.
The point is this: you want to hardware accelerate the right architecture. Applying hardware to legacy frameworks is questionable as a strategic play; even in the short-term it’s tenuous at best. And, importantly, not all hardware is created equal. At Tervela, we’ve taken our architecture, our hardware and our software very seriously. Given recent news, though, let’s talk about hardware.
Tervela was started to overcome critical inefficiencies in legacy middleware and networking paradigms. We introduced an architecture that represented a fusion of middleware and networking, yet had the flexibility to work with both legacy and emerging applications.
- We separate the data path from the control path to ensure predictable, consistent, high-performance and low-latency messaging. Control information does not interfere with data.
- A separate data path allows Tervela message switches to readily connect into a resilient message network without sacrificing performance.
- Our data path is implemented entirely in hardware with no need to “go up and down the stack” or suffer an operating system context change.
- Being “network aware” and realizing that underlying network conditions are critical to performance, the Tervela messaging platform dynamically adjusts processing in response to network circumstances and consumption patterns.
- Tervela incorporates different types of hardware depending on the processing requirements. Concurrent with the operations to be performed, we employ different types of hardware within the flow. Not all hardware is created equal; we use both FPGAs and high-performance programmable ASICs where it makes sense and delivers optimum performance.
- Our hardware is programmable, ensuring both performance and functional flexibility.
- In addition to our own hardware, we also utilize advanced, virtualized, multi-processing systems to address the diverse computational needs of our customers.
- We designed our own hardware, employ best-of-breed silicon and are currently finishing our third-generation messaging architecture.
We are thrilled to have other companies join us in the hardware-accelerated messaging space. For Tervela, it’s all about the architecture, which allows us to quickly and transparently ride the ever-improving hardware innovation curve without having to reinvent our approach. Given that we’ve been doing this for five years, we thought we’d provide some closing insight:
- FPGAs are a means to an end, not an end in itself. Putting legacy protocols in FPGAs might not be the optimal way to maximize messaging performance.
- If a legacy protocol is inherently inefficient, putting it in hardware doesn’t make it any more efficient.
- If the legacy application is heavyweight, it will remain so. Rethinking messaging is critical for emerging, high-performance applications.
- The right architecture is about flexibility and the future.
- Designing for performance is nice, but manageability and serviceability are non-negotiable.
=rob.ciampa
June 27, 2008 at 11:45 am
OK, we were a bit unorthodox in our approach at SIFMA. When you’re dealing with 7,000 attendees and 300 vendors, you have to be. Perhaps our booth felt like the Haight-Ashbury district of San Francisco in 1967, but we have a big issue with “the establishment” – the messaging establishment. What we’re calling into question is the architecture of legacy messaging systems, message-oriented middleware, etc. Are we stuck with messaging frameworks that are about as contemporary as the tie-dye VW bus? In doubt? Ask a messaging architect about the last outage with a software-based messaging solution. The new revolution is about hardware, architecture and rethinking messaging. It’s time for the message network.
=rob.ciampa
Skip navigation
