So, you’ve read my last couple of Musings and you’ve decided you want to be the market leader in Web Edge Processors (WEPs) and you’ve come to me for advice on how to do it. 

My first question for you is “why?”  I’m hoping that your answer is you share my faith that, although the market is pretty small and fragmented right now, if someone gets this “right” the market will grow substantially (to a couple of billion dollars give or take some beer money) and the company that gets it right can take the lion’s share of this growth.

My next question, if you are a start-up or contemplating being one, is “when do you have to be back at the asylum?”   As we’ll see below, the challenges facing a start-up in this space are enormous. One will have to break all the time tested rules about what start-ups need to do to be successful. 

The issue is the myriad checklist feature requirements for a WEP that cut across a lot of category boundaries like traffic management, security, content serving, and network/systems management.  In the past, these areas have been served by lots of different vendors and lots and lots of different point products.  It is a daunting task to try to reduce the past proliferation of products down to one – or maybe two or three to be more practical.

But still, even though it will be difficult, I think it might be doable.  Here are my thoughts on the keys to success:

1.   Survey all of the point products cluttering web application delivery systems today (see Figure 1 of my previous Musing) and talk to a bunch of customers about what features they really use within each product category and their priority.  I’ve done this. It is quite an enlightening exercise and the answers are why I think there is a chance someone could actually build a useful WEP (in other words, only a small number of features are routinely used in each category). 

2.   Build a product with a base set of features that includes everything determined by the step above. 

3.   Simply integrating previously segregated features probably won’t grab customers’ attention.  Choose one general area where you go beyond the base set of features to provide best-of-breed differentiation. 

The area you choose can’t be load balancing – that’s a core function requirement for all WEPs.  It also can’t be table stakes items like SSL acceleration, Layer 3 or 7 access lists, stateful firewalling, Gzip-based compression, NIMDA attack prevention, SYN attack denial-of-service protection, cookie-based persistence, TCP connection pooling, usage stats and reports, key management, integrated logging, etc.  It also can’t be the squishy things nobody quite understands and probably doesn’t really work, such as intrusion detection, intrusion prevention, intruder detention (I just made this one up), or the ever popular QoS (a.k.a. service level management, differential services, platinum/gold/silver personalization). 

The area you choose to provide leading edge capability needs to be something that separates you from the pack.  Examples (but no longer good choices because others have done them) are ensuring the security of data-at-rest; elimination of 98% of the inefficiency of Web Server I/O via request aggregation;  offloading the back-end effort of creating dynamically generated content;  squeezing every bit out of application responses – or eliminating them altogether; executing application and content specific security rules; or accelerating and securing XML-based transactions, to name a few.

Choose wisely here. Most of your marketing energy and much of your R&D effort will be expended in this area.  It better matter.  You’ll build around this capability “moth-to-bright-light” core capability to be a full-featured WEP.  If your core capability is compelling enough, customers will forgive you a few shortcomings in other areas.   If you don’t think you can pull this off, consider a total focus on your capability and become a WAM vendor (see below). 

4.   Be software centric.  I like the idea of pre-loading software onto a hardware platform before shipping it to a customer (the so-called appliance strategy).  But don’t go nuts on the hardware aspects of this.  If you’ll notice, the ones who went after this with a hardware centric approach – Nexsi and Desana Systems come to mind – are no longer with us.  Ninety-nine percent of your R&D should be software development and QA.  Your manufacturing person should also have time to sweep the floors and run the NCAA basketball pool.  You should achieve performance and scale via a software architecture tuned for the task.  While you’ll likely run a general purpose OS in your box, you probably won’t ask it to do much.  In effect, you will create a purpose built OS layer above it that allocates resources, responds to events, sequence activities, and is partitioned and hardened from the bottoms up in both a performance and security sense to ensure that your WEP won’t be the weak link in your customers’ security strategy.  Given all this clever software work, a 1-4 CPU off-the-shelf Intel platform supplemented with off-the-shelf storage and possibly security acceleration or network processor PCI cards should do the trick.  If you need a real high-end platform, check out Rackserver as a partner.  Otherwise, Joe’s Computer and Body Shop should serve as a supplier just fine. You generally won’t need it, but if the scale of your solution is an issue, figure out a way in software to virtualize your own boxes so that N boxes provide N throughput.  If N is equal to 2, that’s your redundancy story.

Another reason to be software-oriented is the strong trend for WEP capability to be deployed as functions on a blade in a high density blade server, acting as the resource manager for the collection of applications and application delivery resources within the box.  Bottom line – staying software focused, commodity (i.e. Intel) CPU focused and (probably) Linux-oriented will give you plenty of flexibility to address a range of different deployment scenarios for WEP technology.

5.   Build a top-notch cross-functional team. I used to be quite adamant that traffic management was traffic management and security was security and never the twain shall meet.  I also used to be quite adamant that network-oriented and application-oriented products must be separate and distinct.  This view served me well for about two decades, and was based as much on my view of the end users ability to understand and value products that cut across these categories as it was the difficulty in building them.  But I no longer hold these views – at least as related to the WEP space.  HTTP, XML, multi-tiered application delivery architectures, and now Web Services have blurred the distinction between networks and applications.  Security is no longer effective if viewed as a separate overlay of networking and applications.  These concepts need to be merged and dealt with as intertwined components within unified solution architectures.  If traffic is encrypted, there can probably be only one trusted “bump in the wire” to de-crypt it, provide some significant WEP-like added value, and then perhaps re-crypt it and send it on its way.  For that reason and many more, security and traffic management and network management and systems management all seem intertwined now.  This makes for a difficult task, both for those developing technology and those using and deploying it.  But I think the world has come to this.  Deal with it.

6.   I’ll know someone has gotten this right when I look at a Data Center or an isolated web based application delivery system and I see application servers, database servers, a Layer 2 switch, and possibly a NAS box or two, but no web servers – just two or three WEPs at the front end. 

As I observe the software architectures and core functions implemented to provide application firewall services or on-the-fly content modification or Layer 7 load balancing or static content caching, it occurs to me that most of the functions of a web server are being replicated here.  When I look at the ability of one of our clients (Redline Networks) to handle 1000’s of TCP connections and HTTP daemons on garden variety hardware and eliminate all of the terrible inefficiencies of a standard Operating System trying to schedule resources for 1000’s of different processes, it occurs to me most of the functions of a web server are being replicated and at tremendously improved price/performance.   So I think the concept of web servers stacked up high at the front end of a web application delivery system will come to an end over the next 2-3 years, with WEPs subsuming their capability, at least for static content delivery.  That alone is enough to levitate the market opportunity into the low billions.

7.   The list of functions that are and will be desirable to run on a WEP is very long.  Plus, this isn’t a stable science.  New stuff is getting invented every day.  I think it goes beyond the resources and management capability of any company – start-up or not – to develop, test, and deliver all of these capabilities.  One of the most important components of the strategy of someone who competes well in the WEP space will be supporting a platform characteristic to their product.  By this I mean the product will be built in such a way that other applications can interface to it and leverage the core infrastructure elements of the WEP – combined data structures, coordinated feature/function sequencing, integrated management, etc.  

There may be a phase (and one could argue this is where we are today, exemplified by the F5 iControl architecture) where such integration can be loosely achieved between software running on different boxes.  But the ultimate would be for the applications to all co-reside on the same box so that core things like TCP termination, client management, SSL processing, HTTP parsing, etc. could be accomplished once in a single place and shared among the applications.

To achieve this, a WEP vendor needs to take the platform aspect of this seriously – as seriously as any feature development.  It’s not good enough to just load other applications onto the same box and somehow time share resources.  The platform needs to provide mechanisms for sharing core functions and to define function sequences and precedence; to provide isolation between functions to isolate failures and to limit the amount of resource any one function can take; and to provide instrumentation to help users tune resource usage policies.  Common user interface and license key practices are needed.  APIs need to be published and adhered to.  A simulator to aid ISV development and testing would also probably be essential.  On top of this, a program to support integration programs and to manage integrated field support is needed.

This is a lot of work.  The payoff is in becoming a magnet for ISV and technology partnerships. 

There are some vendors out there who are only platforms.  There are lessons to be learned from them by aspirant WEP vendors as to how to approach (or not approach) creating a platform and a vendor ecosystem around it.

Personally, I don’t believe the platform-only approach is a good business, but I do believe that the winning WEP vendors will have a strong platform component to their story. 

If this plays out the way I think and hope it will, vendors are going to have a new decision to make as they think about their role in the world.  Should I be a WEP and invest heavily in both the platform and feature aspects of that, or should I be a WEP Application Module (WAM) that plugs into WEPs to provide some discrete and deep value?   Many will choose the WEP route because it seems like the bigger idea.  And many who choose this path will fail, because it is a very hard route and in the end only a few can succeed.  But being a WAM is not a bad life.  The existence of WEPs will allow WAM vendors to focus on their core capability and deepen their value, rather than having their effort be diluted by having to think about hardware platforms, TCP stacks, SSL processing, key management, failover schemes, clustering techniques, etc.  With such focus, it should be possible to be a damn good WAM, ma’am.  And the market should reward such.  So it is entirely possible the most interesting and successful products to come out of this may be the WAMs, although the sorting out process can’t start until a couple of vendors step up to be WEPs.   Who of you out there will that be?