Topics


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 Virtualization Gone Wild: Infrastructure as virtual appliances
posted on Monday, January 12, 2009 4:29 AM

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.

JUST BECAUSE YOU CAN ...

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.

MANAGE THE ABSTRACTION, NOT THE 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.

Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share

Reblog this post [with Zemanta]


Email This
  del.icio.us
      

Feedback


1/12/2009 5:34 AM
Gravatar I would never go so far as to claim to be rational, despite the title of my blog, but I can only assume (perhaps foolishly) that you *might* have been referring to me?

If so, I need to make something a little more clear: my discussions on virtualizing things like load balancers, etc., were, quite obviously, tongue in cheek and used to play devil's advocate in discussing the matter. It's happening...in many forms, and will continue to, despite protest.

What you describe above in your post, in all it's sordid glory, is the content of my Four Horsemen of the Virtualization (Security) Apocalypse preso...

In case you weren't referring to me, ignore this post ;)

/Hoff
Christofer Hoff

1/12/2009 5:47 AM
Gravatar @Christofer

Amazingly, I wasn't thinking of you this time. But I'm glad you came out and reminded me that your presentation does a great job of digging into the deep recesses of virtual architectures and exposing the issues with it, particularly on the security side of the world.

Folks should definitely check it out, it's a thought provoking and scary (in the exposure of issues) presentation.

Four Horsemen of the Virtualization (Security) Apocalypse


Lori MacVittie

1/12/2009 10:55 AM
Gravatar I'm just amazed you made it through that without pointing out that a single hardware failure could drop multiple switches, firewalls, and load balancers in a purely virtualized environment ;-).

Wasn't a fan of this back when I saw the first virtualized firewall at Interop what? 2004? Firewalls at least have a purpose in segregating VMs, but still thought if you're paying for a hardware one, why pay for a software one?

Don.
Don

1/13/2009 10:23 AM
Gravatar Lori,

but isn't traffic manager (or ADC if you listen to Gartner) just another piece of application when it comes to it? Long gone are the times where appliance was a simple load balancer, now we require from traffic manager to do part of the application role by examining the traffic and make intelligent decisions. Isn't that why F5 came up with its variant of scripting language to manipulate requests and responses as they pass through the appliance? To provide value added service or in essence extension of the application being load balanced.

So if we look at this and the emergence of cloud computing, why wouldn't someone (customer or cloud service provider) look at traffic managers as a service and look forward to streamline and incorporate it into their cloud environment? From the cloud service provider perspective, it is much cheaper to stack bunch of general purpose boxes vs. having to carry general purpose boxes and legacy special hardware (such as BigIP in case of F5). Why would could provider look at CapEx and inventory of legacy hardware vs. OpEx of virtual traffic managers that they can turn on on demand? They provide same functionality (or more as they can add dynamic provisioning), better performance per $ spent, and no upfront cost. What it is not to like by virtualizing this aspect of service as well?

How does one sacrifice reliability by virtualizing? Virtual traffic managers can run in high availability pairs (or in better instances even as multiple active-active clustered traffic managers).

How does one sacrifice security by virtualizing? We know that in the past appliances (such as BigIP) had identified security holes. Thus it seems no better or worse then virtual appliances.

How does one sacrifice performance by virtualizing? With active-active clustering of traffic managers one can practically linearly scale in virtual environment providing throughput several factors larger then the largest active-passive pair of the fastest hardware appliance in the market today.

So what is left? Lower cost, higher throughput, better scalability, quicker provisioning. Practically no CapEx or stocking up the hardware.

I can't see how could providers would go any other way than with virtual appliances. It is the only reasonable way.

I understand that F5 is coming from legacy hardware side, however things move. Not so long ago we were all making fun of Web 2.0, didn't we? Now we are making fun of cloud/virtualization. I think 6-12 months down the road when F5 might come up with software solution we'll see different post from Lori. Watch this space for praise of software then.
Izzy

1/13/2009 11:46 AM
Gravatar @Izzy

You misinterpret my view of cloud/virtualization. First, I think cloud/virtualization is excellent. It's a natural (and logical) extension of SOA and I think the core concepts are sound as well as viable. That virtualization is the catalyst that finally enabled this type of on-demand application infrastructure is excellent, and virtualization combined with application deployment is a perfect solution to the problem of resource management for scalability in many situations.

I also believe that virtual appliances (hardware solutions turned into virtual images) is a good idea for testing, proof of concepts, training, developer integration, and architectural tests. I do not see it necessary or a good idea in production for most network and application network functionality because it doesn't make sense there for a number of reasons, reliability and security being two of them.

As far as the CapEx and "practically no stocking up the hardware", come on. You still have to have the hardware to run virtual appliances on. Deploying many virtual appliances on a single beefy piece of hardware certainly sounds appealing from a cost perspective, but reliability goes out the window - if that one piece of hardware goes down, a large piece of your core infrastructure just died.

So how do you solve that? You buy another piece of hardware and duplicate the functionality. And another, and another. You're buying hardware one way or another.

Right tool for the job. I just don't see virtual appliances as a good solution for network/application network functionality. For application deployment? Absolutely.

Lori MacVittie

1/13/2009 2:01 PM
Gravatar Lory, care to show any evidence on lack of reliability and security in comparison to legacy hardware appliance? Because if you can't it is all FUD in order to protect your hardware investment.

I also see that you've dropped the performance as one of your reasons (from obvious reasons that it is simply not true).

As far as hardware is concerned. If we go into cloud computing we are not talking about couple of generic CPU hardware boxes, we are talking about tens or hundreds of them. So reliability is there. Let's say you have 10 physical boxes that each can run several virtual traffic managers. Now you have 9+1 redundancy factor vs. 1+1 in case of legacy Vipron. (Unless F5 managed to go beyond active-backup solution and can cluster many traffic managers as one traffic management cluster?)

Security? Last time I've checked many legacy solutions (including BigIP) had security warnings issued. Doesn't F5 BigIP (many different product lines!) have fairly recent security warning issued on Security Focus just few days ago?

Here is the list of vulnerable releases:

F5 WANJet 5.0.2
F5 WANJet 5.0
F5 FirePass 6.0.2
F5 FirePass 6.0.1
F5 FirePass 5.5.2
F5 FirePass 6.0
F5 FirePass 5.5
F5 Enterprise Manager 1.4.1
F5 Enterprise Manager 1.6
F5 Enterprise Manager 1.2
F5 BigIP 9.6.1
F5 BigIP 9.4.5
F5 BigIP 9.4.3
F5 BigIP 9.3.1
F5 BigIP 4.6.4
F5 BigIP 4.6.3
F5 BigIP 4.6.2
F5 BigIP 4.6.1
F5 BigIP 4.6
F5 BigIP 4.5.14
F5 BigIP 4.5.13
F5 BigIP 4.5.12
F5 BigIP 4.5.11
F5 BigIP 4.5.10
F5 BigIP 4.5.9
F5 BigIP 4.5.6
F5 BigIP 4.5
F5 BigIP 9.6
F5 BigIP 9.4
F5 BigIP 9.3
F5 BigIP 8.0
F5 3-DNS 4.6.4
F5 3-DNS 4.6.3
F5 3-DNS 4.6.2
F5 3-DNS 4.6.1
F5 3-DNS 4.6
F5 3-DNS 4.5.14
F5 3-DNS 4.5.13
F5 3-DNS 4.5.12
F5 3-DNS 4.5.11
F5 3-DNS 4.5

How does this compare to probably one of rare (if not only) competitors in virtual/cloud space (Zeus) that has exactly 0 vulnerabilities listed in their traffic management software on Security Focus?

I mean you are entitled to your opinion but facts do speak for themselves, don't you think?
Izzy

1/20/2009 1:36 AM
Gravatar Hi Lori,

nice article but I have a few issues with it.

I can see why you'd want to put down software appliances, but the huge advantage to them is the ability to 'ride moores law'. At the end of the day any algorithm is software, whether it's burnt to an ASIC or not.

Similarly, being able to run virtualized gives your traffic manager the abliity to 'burst' up to more memory, throughput etc.

More and more institutions have virtualised infrastructure now,
so adding the cost of that to your CapEx for virtual applicances is as unfair as adding the cost of a datacenter to your figures for LTMs :)
The difference is that the resources allocated to the software traffic manager can be scaled up or down easily, whereas putting it in a box with hard walls takes away that flexibility.
Dick Davies
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 7 and 3 and type the answer here: