One of the areas I really enjoy wallowing in is now commonly referred to as Internet Traffic Management, otherwise known as “a wide-ranging bunch of techniques for making web sites and web application delivery better, which aren’t routing, don’t have books written and university courses taught about them, and for whom the definition changes daily as vendors determine whether it is cool or not cool to be considered part of the ITM crowd.”  How could you not love a market segment in which every vendor whose main features are for balancing traffic among web servers vehemently claim, “we are not a Server Load Balancer"?  What’s not to like about a collection of products generally referred to as “Web Accelerators,” half of who actually slow down web traffic either by design or by accident?  It’s a wild and wooly world, and I really, really, like it.

Back when I first got involved in ITM, before it was even called ITM, in the pre-historic days of 1996 through 1998, it was all about making web sites reliable and scalable.  Reliability was of obvious value.  Scalability was deemed to be critical because everyone thought they’d be the next eBay or Yahoo.  Therefore, early ITM products truly were load-balancing centric – providing the ability to create vast farms of web servers, caches, firewalls, etc., to meet growing traffic demands.  At one time this was a very dynamic and confusing market, with lots of viable entrants.  That was the situation in 1998, when Dave Logan and I decided to publish some tutorial materials to help people understand the technology and the choices that various vendors had to offer to them.  Shortly after we published the third version of the reports, the Server Load Balancing space got (temporarily) more stable as Nortel Networks acquired Alteon Websystems and Cisco bought ArrowPoint.  This created a triumvirate – Nortel, Cisco, and F5 Networks dominated that space.  As a result, we moved on to other things.  Since then, F5 has continued to innovate and flourish, while Nortel and Cisco have spent a lot of energy digesting their acquisitions.  The remnants today are about what you’d expect from a digestive process.

In the mean time, some bureaucrat somewhere remembered that this is a capitalist society and overrode the fun button, so that web sites are now under pressure to make a profit.  As a result, ITM products today are (appropriately) more focused on efficiency than on scale.  Efficiency means fewer servers, fewer caches, less bandwidth, reduced operations costs, etc., to serve the customers at the desired levels of performance.  In other words, what can you do for me to make my site cheaper to run, and can I get economic payback within months, not years? 

The good news is there are a lot of products and services out there promising efficiency.  The bad news is it is a very confusing prospect to sort through the choices and determine which ones really work and apply to you.  You have some products oriented towards pre-caching expected responses at the client to provide instantaneous response times; others compress traffic both to get it to the client faster and to reduce site bandwidth requirements; some others provide caching within the network or at the origin site to off-load your servers and/or to deliver responses faster; while still others off-load some functions that may bog down your servers – SSL or XML being the most prevalent examples, and some simply make your servers and caches faster and more efficient so maybe you don’t need to worry as much about off-load.  There are products oriented toward giving users the ability to leverage various ITM techniques for end-to-end secured traffic, eliminating the need to choose between security and ITM, and other products allow you to effectively use multiple ISPs to connect users to your site.  And, as if this isn’t confusing enough, hardly any product does any one of these things, but usually two or three, creating an overlapping multi-dimensional Ven diagram of choices for the end user.

I’m convinced that as powerful as some of these products are, the uptake in the user community has been significantly dampened because of confusing messages, product overlaps, exaggerated vendor claims, and (in some cases) dysfunctional products.

This is similar to the situation when Logan and I first decided to publish some clarifying materials about ITM.  So, we’ve decided to do it again, this time with help from Dave Danielson and Roy Harvey.  We’re going to devote most of Q2 to researching and writing two updated reports on Internet Traffic Management, one from the point of view of end users trying to figure out what the various choices are and how to figure out what applies to them, and one from the point of view of the financial community, trying to figure out who to bet on.  And these bets are important.  Although business has slowed down recently, the webification of applications is continuing to move forward, and ITM functions are a critical make/break factor in whether they work well or not.  There is a lot of money to be made or lost here.  The game has hardly begun. 

I’m sure you are saying to yourself, “this seems like a heck of a lot of work, but extremely valuable, how can I help?”  I’m glad you asked. 

If you are an end user or consumer of such technologies, please contact us because we would like to talk to you.  We’d like to find out what your site requirements are, what ITM tools you use or have used in the past, what you like and dislike about the products and services you’ve used, what new capabilities you have your eyes on, what your present thoughts are about them, how you will evaluate them, etc.  We want you to get as much out of these conversations as we do, so feel free to pepper us with questions about the various vendors and their products, and how we feel about them.

If you are a vendor in this space, we’d like to spend a half-day or so with you to make sure we understand what your products do and where you are heading.  In addition, if you see the value in what we are doing in terms of market conditioning and education, we’d also like to ask you to seriously consider sponsoring us to help subsidize the creation of these reports.  The last time around, we made end users buy our reports, as we didn’t ask for industry sponsorship.  We realize in retrospect that this approach reduced the distribution of the information.  This time, we’d like to make the user-oriented report free and make it almost as available to people as AOL registration CDs are.  We’re looking for 8-12 sponsors and have just started the process of searching for them.  A sponsor prospectus is available on our web site.  As of the writing of this Musing, we have three sponsors signed up.  So act quickly if you want to be a part of this effort.  Logan needs his beer money.

(volume 5, number 2)

Send email to info@acuitive.com with questions or comments about this web site.
Copyright ©1997-2002 Acuitive, Inc.  All Rights Reserved