From The Founder and Senior Analyst of ZapThink

Ron Schmelzer

Subscribe to Ron Schmelzer: eMailAlertsEmail Alerts
Get Ron Schmelzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Virtualization Magazine, VMware Journal, Infrastructure On Demand, Cloudonomics Journal, Infrastructure 2.0 Journal, Datacenter Automation, CIO/CTO Update, New Year 2010

Blog Feed Post

A Fluid Network is the Result of Collaboration Not Virtualization

The benefits of automation and orchestration do not come solely from virtualization

vitameatavegaminVirtualization has benefits, there is no arguing that. But let’s not get carried away and attribute all the benefits associated with cloud computing and automation to one member of the “game changing” team: virtualization. I recently read one of the all-too-common end-of-year prediction blogs on virtualization and 2010 that managed to say with what I think was a straight face that virtualization of the network is what makes it “fluid”.

From: 2010 Virtualization Predictions - The Year the Network Becomes Fluid and Virtual

blockquote Virtualizing the network provides the similar benefits as server virtualization through abstraction and automation … The bottom line: In 2010, the network is going to become as fluid and dynamic as the data center is today.

The first problem with these statements is the separation of the network from the data center. The last time I checked the network was the core foundation upon which data centers are built, making them not only a part of the data center but an integral part of it. The second is implying that the automation from which a fluid network is derived is somehow achieved through virtualization. No. No, it isn’t. Both virtual and physical infrastructure require more than just being shoved into a virtual machine or automatically provisioned to enable the kind of benefits expected.


INFRASTRUCTURE 2.0: IT’S WHAT DATA CENTERS CRAVE

Infrastructure 2.0 is the enabling technology behind a fluid network,  no matter what the physical / virtual status of the infrastructure may be. Without the ability to integrate and then automate and include in data center orchestration network components it really doesn’t matter whether they’re virtual or not. Virtualization in and of itself provides little more  than abstraction and the ability to easily replicate (clone) itself. Even with the anticipated availability of VMware’s Redwood project, it is only the automation of the virtualization layer that appears to be addressed:

blockquote Presumably, VMware's Redwood would help partners like Savvis avoid these sorts of development efforts, especially as VMware evolves its platform over time. "There's an argument about how good and robust that [third-party] code is," the source said, "and how well it will work with future versions of vSphere right out of the box."

In particular, Redwood uses Lab Manager's network fencing technology to quarantine virtual environments "so there's no bleed-through," the source said, and VMware Orchestrator for automating the configuring and provisioning of a VMware cloud workload.

There’s little discussion of the inclusion of infrastructure – network and application network – components in the automation and orchestration, which makes sense given that there are today too many differences in API and methods of automating these components to presume VMware – or anyone else – will soon offer up a comprehensive solution.

The claim appears to be that virtualization magically enables networking components with the ability to configure themselves appropriately. At least that’s the way I read it, because in order for it to “reduce operational costs and increase security, manageability and scalability by abstracting and automating network services” in a volatile environment – such as public or private cloud computing – it would be necessary for the network components to adjust, add, and otherwise modify configuration in a way that is reflective of the underlying volatility inherent in the moving around of applications provisioned and released via virtualization. Too, the actual provisioning and subsequent configuration of infrastructure components will be highly specific to each cloud computing environment, and based on the unique processes required by each provider or organization. That’s not something that can come out of a box, off the shelf – unless organizations and providers are willing to have their processes prescribed by external vendors.


LAYER of ABSTRACTION = LAYER of OPAQUENESS

Yes, virtual infrastructure makes it easy to deploy a networking component anywhere you need it at the moment you need it, but it doesn’t do a thing to make sure it’s actually conductorconfigured to do what it’s supposed to do when it launches. The only way that happens is through automation, which is not peculiar to virtualization. That’s something that’s enabled through APIs and integration, both of the virtualization technology and the infrastructure.

In the case of network infrastructure, components already enabled with a dynamic control plane can be scripted and integrated into automation and orchestration solutions to achieve this; virtualization of that same infrastructure adds no additional capabilities in this area at all. The layer of virtualization (abstraction) actually adds a layer of opaqueness into the architecture; a layer through which components must still be managed and integrated into the orchestration that will drive cloud and dynamic data centers. In fact, if you take a network component that is not enabled with a dynamic control plane via an API then it is no more able to address this challenge than its hardware counterpart. It is the existence of the API and its utilization that makes a network “fluid”, not its deployment form factor. It is the intelligence, the leveraging of the dynamic control plane, the collaboration that makes a network – hardware or virtual based – fluid.

Yes, virtual machines and hypervisor technologies also have an API through which … the virtual container can be manipulated. It can be stopped, started, and managed but that’s the container, not what application or infrastructure might be running inside that container. The automation enabled by virtualization is strictly management of what is the equivalent of the data center operating environment fabric. The benefits that come from automation of the actual infrastructure components, the orchestration of operational processes that eliminates redundancies and the need for manual execution, comes from collaboration of infrastructure through integration based on standards-based control planes.

The network will become fluid – I absolutely agree – but that metamorphosis will not solely because of virtualization.

Follow me on Twitter View Lori's profile on SlideShare friendfeed icon_facebook

AddThis Feed Button Bookmark and Share

 

Related blogs & articles:

 

 

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.