By deploying multiple point solutions when one would suffice

I know it doesn't rhyme but honestly, between the number of words that rhyme with "weave" and the meter it was nearly impossible for my sleep deprived brain to come up with one that made sense. Feel free to come up with one and add it via the comments or mail me.

Now it's time for a little story:

In the beginning OSI created a model.

Now the network was formless and empty, darkness was over the optical connections, and the spirit of the OSI was hovering over the web.

And the OSI said, "Let there be a reference model for networking," and there was a model. The OSI saw that reference models were good, and thus they separated the layers of networking. The OSI called the network layer "IP", and the transport layer they called "TCP". And there was IP, and there was TCP.

And the OSI said, "Let there be another layer above TCP to separate the applications from the network." So the OSI made another layer and separated the transport layer from the applications above it. And it was so. OSI called the new layer "application".

Okay, you get the picture. The point is that the OSI model has been the foundation for computing and networking models for a long, long time and remains today an integral part of the technology vernacular.

Unfortunately, as the web and technology have advanced, we have continued to separate not just the layers of the OSI model into products, but we further segregate those products within our infrastructure. We have routers and switches, load balancers, SSL accelerators, web and application accelerators, firewalls, application firewalls, and secure remote access devices. We tend to architect our networks and solutions into a nearly one-to-one match against the OSI model: seven layers in the model, seven convoluted layers of products.

The problem with deploying multiple point solutions, each designed to solve a specific problem associated with one of the layers in the OSI model, is that you can't deploy just one; you need at least two to reduce the possibility of introducing a single point of failure into your infrastructure. That secondary (backup) device introduces even more complexity into an already complex network architecture.

Hence you end up with a "tangled web" of network devices and interconnected products, all requiring management, upgrades, power, and configuration updates. These tasks all add up to an increased cost of ownership as well as potentially delaying deployment of new applications due to the number of tasks that must be coordinated in order to successfully - and securely - complete an implementation.

The Benefits of a Unified Approach

To reduce the cost and time associated with maintaining a healthy, secure application delivery network it is often beneficial to consolidate - or unify - as many functions as is possible onto one box, provided that security, performance, and reliability are not compromised by such consolidation. An application delivery controller offers just this - a unified platform upon which the functions necessary to provide secure, fast, and reliable delivery of applications can be deployed. In some cases the unified platform means that multiple functions can be deployed on the same device, in others that unification may still require a separate device, but ancillary functions such as management and upgrades can be accomplished via the same mechanism as other devices that take advantage of that unified platform.

The benefits of such an approach boil down to three basic categories: management, performance, and architecture.

Reduced Cost of Management

Whether you're deploying many functions on a single, unified platform or many functions on multiple instances of that unified platform you're reducing the overall cost of management - and thus TCO (Tota Cost of Ownership) - of the solution. A unified platform approach reduces the costs involved in training and management of the device(s), as it is generally the case that all products use a similar GUI or CLI through which they can be managed. Also often available is a separate, centralized management solution from which all products taking advantage of the unified platform can be managed, upgraded, and monitored.

Taking advantage of a unified platform, especially when functions like load-balancing, SSL acceleration, and web application acceleration are consolidated, can also reduce the overall costs associated with power and cooling as there are fewer devices deployed which generate heat and consume power.

Better Performance

One of the long-held tenets of networking and performance is to "only crack the packet once" if possible. Deploying multiple solutions often requires that each device "crack" the packet in order to perform its duties. This is particularly true of devices that act upon applications such as those providing acceleration, transformation, and routing. Each device that must inspect the data introduces additional latency that can ultimately add up to more delay than users are willing to experience. By reducing the number of "hops" in the application delivery network, application performance can be improved.

Simplified Network Architecture

Finally, reducing the number of devices required to support a secure, reliable, and fast application delivery network simplifies the architecture. This simplification makes it easier to manage and has the added benefit of making it easier to diagram. :-) Simplifying the network architecture also (and perhaps most importantly) makes troubleshooting faster and easier, as there are fewer points along the delivery path at which the error might have occured. The quicker the problem is found, the less downtime users experience, which is good for everyone.

A unified application delivery platform isn't necessarily about a single device upon which all delivery functions are deployed, but it is about a unified platform that can decrease the number of point solutions necessary and provide a single, management platform through which all pieces of the delivery infrastructure can be centrally managed and monitored. It's about reducing the number of points at which a problem can occur, and thus improving the reliability and performance of applications.

Imbibing: Mountain Dew