Generation 2's Winner: The Teknekron Information Bus Story

I worked with the technology's second generation. My company took on the challenge of delivering market prices from multiple sources to hundreds of traders in a trading room, enabling new apps based on real-time calculation. The solution had to scale to maybe 2,000 traders, which is laughably small by the standards of the real-time Web. But you did not want to face a roomful of furious traders if your system was down for three minutes or delayed prices by 15 seconds. The reliability and latency requirements were very stringent.

The company that emerged as leader, Teknekron, coined the term "Information Bus." It did very well by coining the term, because it established Teknekron as a market leader; it followed the "get mindshare first, and then go for market share" strategy. Vivek Ranadive, the visionary founder and CEO, describes in his 1999 book "The Power Of Now" how the term came to him. He was schooled as a hardware engineer and was appalled by how much more chaotic (i.e. error- and delay-prone) software projects were compared to hardware projects. Looking at why, he realized that the concept of a "bus," which is the device that all hardware components connect to, could be applied to software.

Ranadive understood that real-time, event-driven systems would not be limited to financial trading, and he executed brilliantly on that insight. He sold Teknekron to Reuters, the company's main rival in trading systems, but retained the right to use the technology outside of financial markets. That offshoot became TIBCO (The Information Bus Company), which at the time of writing is a publicly traded company valued at $1.6 billion, with annual revenue of over $600 million.

But TIBCO did not leverage its position to dominate the third generation. Another company tried that and blew a lot of money in the attempt.

KnowNow: Lessons of a Blow-Out

KnowNow worked through $50 million in funding before throwing in the towel in July 2008. It was going to update the message bus to the Web using RSS. It was still an enterprise play.

It had a strong management team, top-tier VC (Kleiner Perkins), and strong technology. Why did it fail? Three big reasons stand out:

• Generation 3 is a tougher technical challenge. Generation 2's state of technology was perfect for local area networks using Ethernet, where the user device was always connected and where we measured users by the thousands. With generation 3, we are dealing with millions of users who are offline some of the time, and the network bandwidth available for messages is not under their control. In other words, it is one big bear of a technical challenge!
• Companies are reluctant to invest millions of dollars in closed software when open standards clearly always win on the Web. Companies can instead experiment very cheaply using consumer-centric RSS tools and open source.
• KnowHow was early. The hype on real-time enterprise did not last long enough, and it hit the trough of disillusionment.

Contenders for the Real-Time Web Message Bus

We have probably missed a few, so please tell us about them in the comments. These are very different types of solutions, but they are working towards a similar objective. First, we will list them and then attempt a bit of categorization:

• Gnip: an independent venture whose monetization model relies on it being a hub that different sites can connect to.
• Tornado (FriendFeed's Python-based Web server technology, which was open sourced by Facebook): this uses PubSubHubbub.
• RSS Cloud: promoted by Dave Winer, with WordPress as a marquee partner.
• PubSubHubbub: promoted by Google (and FriendFeed/Facebook), with SixApart as a marquee partner.
• XMPP The technology with which IM clients interoperate. Being used by Yammer, Present.ly, and Drop.io.
• Twitter.
• Facebook.
• TIB: an enterprise solution from TIBCO.
• MQ: an enterprise solution from IBM.
• Sonic: an enterprise solution from Progress Software.

Here are the categories they fall into:

1. Enterprise
   TIB, MQ, and Sonic all fall into this category, and there are more. They will find it hard to make the transition to the real-time Web for two reasons. The first is technical. Connecting millions of users over a low bandwidth network via HTTP is very different from connecting a few thousand users over a corporate network. The second is commercial: they monetize by selling licensing fees to enterprises. But that is not the primary way in which the real-time Web will be monetized. Still, these are big profitable companies with the right tech chops, so they cannot be dismissed.
2. Open source and open standards
   Tornado, RSS Cloud, PubSubHubbub, and XMPP fall into this category. They have differing purposes but also a lot of overlap. XMPP is low level and not affiliated with any big company. RSS Cloud and PubSubHubbub are most similar to each other. Tornado is a Web server. But they all face the issue that an open standard takes a long time to evolve and consolidate into a winner. Before that happens, we will likely see more entrants, making the choice even more confusing for developers. So, developers may hedge their bets and go for commercial/de facto standards.
3. Commercial hub
   Gnip is the purest example of this. It aims to get traction by being simpler to implement than the open-source/open-standards offerings. It is a bold strategy from a strong team of entrepreneurs and investors. For something as big as this - basic plumbing for the Web - it feels like a bit too much reliance on one company.
4. Traffic plays
   Twitter and Facebook are the major players here. They might become de facto standards because the biggest issue is traffic. Developers will build where there is traffic as long as two conditions are met:
   • It works technically (i.e. latency at scale). Twitter has some credibility issues here.
   • It is open and transparent - i.e. anyone can connect without fear of the game changing on them. Facebook has some credibility issues here.

The Technical Challenges

First, we have to address the question of "What does real time mean?"

In each generation, the gurus of the previous generation get sniffy about the definition of real time ("What do you mean one second is real time? We measure in micro-seconds!").

It depends on the usage case and technical possibilities. Real time within a single processor is obviously faster than real time over a LAN, which is faster than real time over HTTP for the whole Web.

Real time, practically speaking, means "orders of magnitude faster than how data has been delivered in the past, and faster than most people think they need today." So, RSS Cloud is faster than RSS, and Twitter search is faster than Google search, and IM is faster than email.

In generation 2, the thinking evolved through three approaches:

1. Polling. It soon became obvious that this would not scale.
2. Broadcast, which put too much load on the client.
3. Multicast, which became PubSub.

Most current Web HTTP-based real-time systems are still in the polling phase (i.e. subscribers poll publishers to see if they have an update), which clearly won't scale. The newer approaches fundamentally enable a publisher to say, "I will tell you, the subscriber, when I have an update, so you don't need to poll me." It's a geek's way of saying "Don't call us. We'll call you."

For a good technical primer on how this works and a discussion of the differences between RSS Cloud and PubSubHubbub (mercifully shortened to PuSH), check out this post.

Sticking My Neck Out to Guess the Winner

Twitter. Why? It has the traffic and is open and transparent enough to win confidence. But two big problems remain:

1. It has to reveal its business model. Only then will partners feel confident that they understand its strategic direction.
2. It has to prove it can get good latency at scale. Its early history of fail whales makes people justifiably skeptical.

The winner will likely be the platform that hosts the killer app. Most platforms get traction through a killer app. In the second generation of real time, that killer app was market data for financial traders. What will it be in the third generation? We will explore this in a future post.

What to Name This Generation?

"Message/Information Bus" worked for generation 2. It took a key concept from generation 1 - the hardware bus - and applied it to a local area network.

That does not work so well for generation 3, the real-time Web. For now, we talk about a Web-wide real-time message bus because there is no better alternative.

The new term may have something to do with "status," because the status update is a central concept in social media. Perhaps something like "StatusFabric" or "StatusNet" or "StatusWeb" will emerge.