Infrastructure 2.0 Journal on Ulitzer

There are many good reasons to go down the virtual infrastructure road. The illusion that it’s cheaper than dedicated hardware solutions is not one of them.

I was reading an interesting predictive article on WAN optimization that contends that virtualized WAN optimization controllers (WOC) are, well, just better than sliced bread. One of the reasons why the author opined this way was presented as the great benefits of horizontal scalability (linear) in cloud computing environments.

Savings and scalability.  This approach ensures that there is no need for dedicated hardware to support WAN optimization, saving on CAPEX and OPEX. Cost savings will also be realized through virtual scalability.  As enterprises add more services or applications to be accessed by additional remote workers via the cloud, the virtualized WAN optimization model will be able to scale linearly.

The implication here is clear: WAN optimization via virtual solutions saves CAPEX and OPEX over dedicated hardware and additional savings are achieved through virtual scalability. But that’s ignoring that the initial investment cost is simply shifted from CAPEX to longer-term OPEX when scalability enters the picture. Not just scalability of the solution, but the impact of application and virtual infrastructure scalability on the solution as well.

Back in the old days we used to deploy all our infrastructure as software. As you needed more compute resources, you deployed bigger, beefier servers on which to deploy said solutions. That’s vertical scalability. Today we prefer the cloud computing model: horizontal scalability. Pay as you grow, compute resources on-demand. Whatever you want to call it the appeal is certainly in the perception that it’s easier and, perhaps more importantly, cheaper than traditional hardware-based scalability solutions. But it’s not accurate at all to equate this model with what is essentially “cheaper” scalability. The operational expenses associated with management, the cost of additional licenses, integration, and the hourly costs associated with the cloud computing environment in question all must be factored into the equation lest we fall prey to the hype that encircles cloud computing today.

One of the reasons you see cost savings in cloud computing is that the costs of the hardware – the physical servers – are shared. You only pay a “nominal” fee per hour for using that   hardware. The cost of that hardware is shared across hundreds of other customers, all seeking the same reduction in operating and capital expenditures. So far, so good. Sharing the physical hardware certainly does spread the cost around and results in a cheaper operating environment – at least for the customer.

But when you start virtualizing the infrastructure (as in virtual software equivalents) you generally don’t get to share the costs of the solution and you never share the costs of management. Most of the time you just share the same costs you do for any other generic virtual image: the underlying physical hardware. You’re also forced to scale horizontally based on the capacity constraints inherent in the virtual image. The provider and/or solution vendor sets the RAM/compute resources available for the virtual instance and if you need more resources when you’ve reached the largest configuration you’ll have to start scaling horizontally. Whether you want to or not. The second image incurs the same management costs as well as the hourly fees. Likely, too, you’re paying for the licensing because virtual versions of solutions aren’t free, after all, unless you’re leveraging open source solutions that are.

You don’t share those costs with anyone. They are yours, and yours alone. The buck passes from CAPEX to OPEX. CAPEX is reduced, yes, but OPEX? Not so much. Perhaps that’s better from an accounting point of view, but from a total cost perspective it doesn’t really change much.

You can, of course, choose the largest image and thus avoid horizontal scalability. But that is going to increase the costs of the solution overall. Consider the virtual equivalent of an application delivery controller delivered via Amazon EC2 on its largest (quadruple large) image is $4.80 / hour (based on pricing listed by Zeus Technologies for its virtual  solution on Amazon). It is unlikely you’ll have any hour in which that solution is not used. Assuming even one request handled per hour, every hour, every day you’re looking at more than $42000 per year

. Don’t forget, too, you may likely have additional charges for bandwidth – both ingress and egress. Not nearly as “inexpensive” as purported. You could start smaller, but that means it’s more likely you’ll need to “upgrade” midstream. This is far easier to do with a virtual infrastructure than with hardware, at least from a physical deployment perspective, but it is just as disruptive a process and may lead to jumping onto the horizontal scalability path earlier rather than later because it is so easy to simply “add another instance” when compared to “upgrade to a new image.” Consider, too, that deploying virtual infrastructure means it is not integrated with the rest of the environment. That may not sound bad, until you realize that automatic scalability means new instances of applications – and perhaps other infrastructure solutions - may be popping up that you need to manage via the infrastructure. How is the infrastructure going to know about it? Either you are manually managing this process or you are going to be doing some integration work. That’s yet another soft-cost of “scalability” that isn’t factored into the equation when comparing hardware to virtual infrastructure.

Contrast that to a model in which services are provided via shared hardware infrastructure solutions. The cost of the hardware is not nominal. But like the rest of the physical infrastructure its costs are shared across all customers. Providing traditional network and application network solutions as services is inherently better suited to a cloud computing environment in that it allows the management costs to be shared (the provider manages the solution, not the customer) and is completely on-demand. Scalability is not the concern of the customer and generally speaking the limitations on RAM/compute resources do not exist in the same way they exist in virtual solutions. Bandwidth in both scenarios can be limited or unlimited, depending on requirements and implementation. Integration should also be taken care of by virtue of the fact that it’s a part of the cloud computing environment and the provider likely wants to ensure that they are billed properly for services rendered.

The current method of deploying a virtual infrastructure actually breaks the “shared resources, shared costs” model of cloud computing and negates the cost savings associated with the elimination of CAPEX for the hardware with the OPEX costs of management, integration, licensing, and a more constrained operating environment that ultimately leads to the need to scale out sooner than would otherwise be required. Certainly a shared model could be implemented via virtualized software solutions, but this model has the same implementation roadblocks as hardware solutions that lead to non-implementation today. Virtual infrastructure shifts many of the management and maintenance-related burdens offloaded by a public cloud computing model back onto the organization and requires more vigilance and dedication to ensuring the overall architecture is operating as expected.

Today, virtualized infrastructure may be the only option for an organization to obtain the control and choice that is currently lacking in today’s cloud computing environments. Deploying hardware solutions and associated services requires an investment on the part of the provider and additional time and investment in developing the means by which customers can take advantage of the solution via services. While most providers invest in hardware solutions without pause, they rarely take the next step in integrating its offerings as services for customers. This means that if you need specific infrastructure components – application acceleration, WAN optimization, web application security – that you’ll likely need to go the virtual infrastructure route. That’s not all bad; this path leads to control and isolation of implementation and configuration, which can be a requirement for conforming to organizational security policies. Organizations having concerns about the impact of other customers sharing infrastructure resources (they already do, but a service-based model brings this to the fore) will almost certainly want to take advantage of the isolation afforded by a virtualized infrastructure implementation.

I’m not arguing against virtual infrastructure in theory or against the control and choice they offer customers. There are challenges with such implementations, mind you, but that’s not really the point today. I’m simply arguing against the “it’s cheaper” mantra that is patently false and fails to take into consideration all the variables in the equation and instead focuses only on the most tangible ones.

There are certainly benefits realized from both deployment models and it is up to the organization to decide which model is right for them. But don’t fall into the trap of thinking virtual infrastructure is a “cheaper” solution, because when you step back and take a look at the entire cost of a solution, that’s just not the case and in fact a services-enabled infrastructure may be a much more financially advantageous solution – except for the provider.

Which may be the real reason the only option you ever have is a virtual one.

• Virtualization Without the Sprawl