Back in the olden days, before most of you had written your first line of code, responded to your first alert notification, installed your first management tool, or perhaps even taken your first breath of life; there existed a powerful technology called mainframe computing.  Mainframes were powerful application processors that could run a large company’s payroll and inventory management systems. Mainframes could model orbit trajectories for Apollo space missions.  They could run complex econometrics analyses, which led to the conclusion that to make money in the stock market one needs to buy low and sell high.  In a lot of different ways, mainframe computing changed our way of life. The advent of mainframe computing really ushered in the information technology revolution that has picked up steam ever since. 

But as powerful as mainframes were (and are) at application processing, they were not so good at getting stuff in and out of the mainframe and dealing with individual users who were trying to access a slice of the mainframes resources.  In other words, they weren’t so good at I/O.  Rather than letting I/O functions bog the mainframe down, the engineers of the day decided to augment it with a device that would sit between the users and the mainframe, managing user needs and making them transparent to the mainframe functions.  This device was called the Front End Processor (FEP), which supplemented mainframe computing to usher in the concept of networked computing. 

“Interesting ancient history,” you may be saying.  But technology is a funny thing.  One likes to think that it continually evolves, moving ever upward, but in reality it spirals upward, and in doing so, you often get back to the same point you thought you had left behind, but at a new level of capability.

Today, a small computer built with state-of-the-art PC technology can do what mainframes did in the past.  Servers built with PC technology can run a large company’s payroll and inventory management systems. They can model orbit trajectories for the space shuttle and communications satellites.  They can run updated complex econometrics analyses, which lead to the conclusion that to make money in the stock market one needs to buy low and sell high and avoid pre-exercising options to hold stock for a future long term gain when the stock market is at an all-time bubble. 

And you want networked computing?  Well, connect these servers to an IP network that in turn is connected to your intranet and the Internet.  You can’t get more networked than that, and it continues to expand. 

But guess what?  As powerful as today’s servers are at application processing, they still suck at getting stuff in and out of them and dealing with the variations of users trying to use a slice of the server resources.  The same server that can run a huge database application in relative isolation often struggles to achieve I/O throughput of 5-10 Mbps if asked to service thousands or even only hundreds of networked users simultaneously.  In short, they are not so good at I/O. 

Many of the engineers of today are dealing with this issue by augmenting servers with new devices that sit between the users and the server to provide various value-added functions.  Over the past few years, many of these functions have been delivered to the market piecemeal, in the form of different boxes or software products.  Some of the pieces include server load balancers and content switches, SSL accelerators, static content caches, dynamic content accelerators, compression engines, content modifiers, application firewalls, XML accelerators, and single sign-on authentication proxies.   Some of these devices don’t really improve the server efficiency, but allow you to cluster more of them to create a larger ‘virtual server.’  Others off-load functions from the server, freeing up more resources for application processing, but with the same inefficiencies in the I/O.  A small number actually directly address the I/O inefficiency issue. 

Although all of this technology is compelling, I think it’s fair to say few if any of the vendors and products in these spaces are really thriving.  The closest thing to an exception would be in the Server Load Balancing (aka Content switching) space, but even that market, as important as it is to web-based application delivery and as talked about as it is, is only roughly a $500M market. The market sizes for all of the rest of the device types mentioned above are far less than that, and as a result you have a lot of vendors struggling to achieve annual revenues in the $10-30M range.  Even if they achieve that goal, it is generally not enough revenue to support a sustained business with high on-going R&D costs.  

If the technology is compelling, why is business success so elusive?  I think it is because most of the products shipped today aren’t really products – they’re features.  To achieve a complete solution today, end users must figure out how to deploy several products to meet their overall need.  The candidate products often have overlapping feature sets and sometimes have conflicting physical topology and failover requirements.  In short, it is often impossible to figure out how to put product A, product B, and product C together to create an overall solution.  The result is that often none of these products get bought and deployed because at the end of the day you can always continue to run all these functions on your servers and just buy (and manage) more servers front ended by a cheap server load balancer. 

As the products in the various sub-spaces mature, vendors are adding features that cut across the sub-space definitions, creating even more feature overlap and confusion in the short term.  But in the long run, I think this is the path that leads to success in the market.  If customers saw a solution that would meet all of their present and perceived future needs, they would rally around such a product as a single point of administration for the delivery of a complex and situation-unique set of features related to the interaction of applications and services with large numbers of network users.  Such a platform would become the design focal point for delivering TCP, HTTP, and XML-based services, providing a convenient barrier between the optimizations desired by servers and the often conflicting optimization desired by clients.  Taking it a step further, solutions such as these would also provide the launching and control point for a variety of web services – allowing application development to largely be isolated from networked application deployment.  I think you can see that, if this is the future and these platforms take on such an important role, a lot of the stuff delivered into the market so far is just enabling features or necessary infrastructure within such a solution.  No wonder they haven’t taken off. 

As clarity about the collection of features required for a unified solution starts to emerge, I think what the market is really doing is driving the definition of a new device type that I call the Web Edge Processor (WEP).  Once established, WEPs will become “best practice” and sit in front of every server or collection of servers providing networked applications.

The overall market for WEPs is actually greater than the constituent sub-component markets combined because the market for the sub-components has been suppressed by the fact that they don’t represent a solution.  I’ve analyzed this.  The market for WEPs is in the low single digit billions of dollars.  Combine that with the fact that markets like to identify two or three leading vendors with products and it is pretty clear to me that a couple of WEP vendors with multi-hundred million dollar annual revenue run rates will emerge. 

But who will those vendors be?  This is a tough market for start-ups to compete well in, because the solution requires such a wide range of features.  It is difficult to develop and support all of those features, much less be best-of-breed.  On the other hand, it’s difficult for larger companies to justify the development expense required to create a WEP, because the experience with all of the constituent component-products has been generally negative and therefore it is a large leap of faith to believe that there is still gold at the end of the WEP rainbow. 

Still, I think the concept of a WEP will emerge.  I believe the vendors who are the most likely candidates exist today, are in the early-to-mid stages of their corporate development, and can take things to the next step and rise up out of the noise if they make the right moves.  There is a gorilla in this space that has the least work to do and that everyone has to respect, and it’s not Cisco (although Cisco does cast a pretty large shadow onto this market).

In next month’s Musing I’ll get more specific about what I think it is going to take to be successful in this market space, the vendors who I believe are the most likely aspirants to the throne, and what I think each of them needs to accomplish to get there.  Stay tuned. 

(volume 6, number 3)