It has been suggested more than once, by folks normally considered rational, that in a cloud computing implementation everything - and I mean everything - should be virtualized. Even the infrastructure.

The hype surrounding virtualization has spread not just to applications and their virtual image deployment as a means to achieve dynamic horizontal scale but also to infrastructure, to routers and switches and security devices. Indeed, there are a good number of infrastructure vendors currently offering and others feverishly working on virtual appliance versions of hardware devices for deployment in cloud and virtual computing environments.

Part of the push behind this craze is the ability to use the integration and collaboration APIs available to manage virtualization products dynamically with infrastructure. Some of it is the desire for a truly elastic infrastructure. Need another switch? Add an image. Need another load balancer? Add an image. Need another DNS server? Add an image. In the network-as-virtual-images all this additional processing power is automatically added, dynamically via APIs that allow the provisioning and de-provisioning of services on-demand.

Indeed, it is these APIs and provisioning/de-provisioning capabilities that make the cloud and dynamic virtualized environments possible. Without them, there isn't much elasticity to the environments at all.


If we look back in time some of us can remember when routing, switching, load balancing and indeed all network infrastructure was provided via software daemons. Eventually these daemons migrated their way onto general hardware (appliances) and then onto purpose built hardware replete with ASICs and FPGAs and optimized hardware components designed not only for scale but for reliability, performance, and security. These devices are generally more reliable than general purpose servers providing the core hardware platforms on which applications and virtual images are deployed, and are capable of much higher performance and throughput than their software-based predecessors.

Now, part of the reason cloud computing is even possible today is the reliability of the network. We trust that the network and its infrastructure services will be available because as a rule they have become that stable. So the question becomes why would we desire a return to a less stable infrastructure by returning to essentially the days of yore? What part of the reliability, performance, and security offered by hardware implementations of core network and application network functionality are we willing to give up?

But we need the automation, the collaboration, the integration.

Agreed. We need those capabilities. But that capability can be provided without moving stable, high performance, secure network and network application functionality to virtual environments deployed on less secure, lower performance, less reliable general purpose hardware servers. We can achieve those capabilities through abstraction that decouples the implementation from the control planes required to collaborate, integrate, and automate the network and application network infrastructure.

The point of abstraction in the cloud is that you don't have to know or care about the underlying implementation. In the same way

SOA The Architecture Formally Known as SOA (TAFKAS) provided abstraction of interface (API) from implementation, so will the management APIs and interfaces provided for automation and provisioning/de-provisioning virtualized environments provide the same level of abstraction.

If the API through which you provision, de-provision, and otherwise manage network and network application infrastructure is essentially the same or similar to that of a virtual appliance, the underlying implementation should not matter. Whether it's hardware implementing that interface or a virtual solution implementing that interface becomes irrelevant because the interaction with that device - virtual or physical - is the same.

That's the power of abstraction and interfaces. That's the lessons learned from not just

SOA The Architecture Formally Known as SOA (TAFKAS) but from object-oriented theory, where hierarchical models are predicated upon the decomposition of objects and the abstraction of interface from implementation.


Consider the definition of abstraction offered by James Urquhart's in a recent post describing a Cloud Maturity Model:

Abstraction occurs when data centers decouple the workloads and payloads of their data center infrastructure from the physical infrastructure itself, and manage to the abstraction instead of the infrastructure.

Manage the abstraction, not the infrastructure. James' simple definition of this concept is spot on. The cloud and virtual infrastructures need to be managed, yes, but it is the abstraction that needs to be managed, not the physical implementation.

Managing the abstraction means never having to care about the physical implementation. Virtual, physical, it makes no never mind to the implementer nor the user what form the actual infrastructure takes.

Just because it is virtually possible to shove any kind of functionality into a virtual environment does not mean it should be done. The advantages gained by doing so in the application layers of the infrastructure are likely to be offset by the disadvantages if done so in the network and application network layers of the infrastructure. Reliability, security, performance. These requirements for cloud computing could easily be wiped out by moving what is stable network and application network functionality into virtualized images. 

We need to move for a model in which the network and application network infrastructure is abstracted and manageable via the same or similar APIs and control-planes that make possible the orchestrated, virtual data center (the automated cloud computing environment).

This means that network and application network infrastructure need to coordinate and collaborate with vendors like VMWare and Microsoft and each other on virtual cloud initiatives defining these control planes to ensure a common interface across all implementations, virtual or physical.

We need to maintain the reliability of network and application network infrastructure while advancing infrastructure to support this new dynamic model of computing. 

It doesn't mean we should take three steps back in time and move stable, high performing, secure network and application network functionality into virtual images (software) for the sake of achieving that dynamism.