Technical Article The Conflation of Pay-as-you-Grow Hardware with On-Demand February 22, 2012 by Lori MacVittie 3341 article acceleration application delivery availability cloud design hardware infrastructure load balancing management network on-demand performance scalability tmos us v11 video virtualization 0 #cloud Today’s post is brought to you by the Law of Diminishing Returns The conflation of “pay-as-you-grow” with “on-demand” tends to cause confusion in the realm of networking and hardware. This is because of the way in which networking vendors have attempted to address the demand of organizations to pay only for what you use and to expand on-demand. The premise is that costs grow proportionally with capacity. In cloud computing organizations achieve this. As more capacity (resources from hardware) are necessary, they are provisioned an paid for. On-demand scale. The costs per transaction (or user) remain consistent with growth because there is a direct relationship between an increase in capacity (hardware resources such as memory and CPU) and capacity. Networking vendors have attempted to simulate this capability through licensing based restrictions, allowing customers to initially provision resources at a much lower cost per transaction. The fallacy in this scheme is that, unlike cloud computing, no additional capacity (hardware resources) are ever provisioned. It is only the artificial limitation on the use of that capacity that is lifted at a price during the “growth” stage. Regardless of form-factor, this has a profound impact on the cost-per-transaction (or user) and, it turns out, on the scalability of performance. The difference between the two models is significant. A “pay-as-you-grow” licensing-based model is like having a great kitchen that is segmented. You can only use a portion of it initially. If you need to use more because you’re giving a dinner party, you can pay for anther segment. The capabilities of the kitchen don’t change, just how much of you can use. Conversely, an on-demand model such as is offered by cloud lets you start out with a standard-sized kitchen, and if you need more room you tack on another kitchen, increasing not only size, but capability. If you’ve ever cooked for a large number of people, you know that one oven is likely not enough, but that’s what you get with “pay-as-you-grow” – one oven with initially limited access to it. The on-demand model gives you two. Or three, or as many as you need to make dinner for your guests. SCALE of PERFORMANCE While appearing more cost effective at the outset, “pay-as-you-grow” strategies do not always provide for the scalability of all performance metrics. This is because licensing restrictions do not impact the underlying hardware capacity, and it is the hardware capacity and load that is always the most constraining factor for performance. As utilization of hardware increases, capacity degrades, albeit in some cases more slowly than others. The end result is that scale-by-license produces increasingly diminishing returns on performance. This is true whether we’re considering layer 4 throughput or layer 7 requests per second, two common key performance metrics for application delivery solutions. The reason for this is simple – you aren’t increasing the underlying speed or capacity, you’re only the load that can be handled by the device. That means the overall utilization is higher, and it is nearly a priori knowledge in networking that as utilization (load) increases, performance and capacity degrade. The result is uneven scalability as you progress through the “upgrade” of licenses. You’re still paying the same amount per increase, but each increase nets you less capacity and slower performance than the upgrade before. Conversely, a true on-demand model, based on the same premises as cloud computing, scales more linearly. Upgrading four times nets you four times the performance at four times the cost, because the resources available also increase four times. Cost and performance scale equally with a platform-based model. Licensing-based models do not, nay they cannot, because they aren’t scaling out resources, they’re only scaling out what portion of the resources you have access to. It’s a subtle difference but one that has a significant impact on capacity and performance. ECONOMY of SCALE As has been noted, as utilization of hardware increases, capacity degrades. When we start looking at the total costs when compared to the scaling value received, it becomes apparent that the pay-as-you-grow model produces increasing costs per transaction while the platform-based model produces decreasing costs per transaction. This is simply a matter of math. If each upgrade in a pay-as-you-grow model increases the overall cost by 1/4, but returns increasingly smaller performance and capacity gains, you end up with a higher cost per transaction. Conversely, a more linear on-demand approach actually ends up producing slightly lower or consistent costs per transaction. The economy of scale is important as it’s a fairly common financial metric used to evaluate infrastructure as it directly translates into business costs and can be used to adjust pricing and facilitate estimated expenses. This disparity is not one that is often considered up front, as it is usually the up-front, capital investment that is most important to the initial decision. This oversight, however, almost always proves to be problematic as it is rarely the case that an organization does not need additional capacity and performance, and thus the long-term costs of Pay-as-you-Grow result in a much poorer return on investment in terms of performance than a Platform-based scalability model. DISRUPTION and CapEx The arguments against a platform-based model generally consist of disruptiveness of upgrades and initial costs. Disruption is a valid concern and it is almost always true that hardware-based devices require a certain amount of disruption to upgrade. The lifting of an artificially imposed limitation on the amount of existing hardware that can be utilized, conversely, does not. This is where the cloud computing on-demand (i.e. throw more (virtual) hardware at the problem) usually diverges from the on-demand model used to scale out networking hardware, such as an application delivery controller. The introduction of virtual application delivery controllers and the ability to seamlessly scale out in a model similar to cloud computing eliminates the disruption-based argument. There do exist models and technology which closely models a cloud computing on-demand scalability strategy that are as non-disruptive as scaling out via a licensing-based model. This leaves the initial cost argument, which generally boils down to a CapEx versus OpEx argument. You are going to pay over the long run, the question is whether you pay up front or over time and what the return on those investments will ultimately be. Just don’t let the conflation of cloud computing’s on-demand with pay-as-you-grow licensing-based models obscure what those real costs will be. IT as a Service: A Stateless Infrastructure Architecture Model If a Network Can’t Go Virtual Then Virtual Must Come to the Network You Can’t Have IT as a Service Until IT Has Infrastructure as a Service Desktop VDI May Be Ready for Prime Time but Is the Network? The Cloud API is Pseudo-Consolidation of Infrastructure The Pythagorean Theorem of Operational Risk At the Intersection of Cloud and Control… The Battle of Economy of Scale versus Control and Flexibility last modified: February 22, 2012 0 Comment(s): You must be logged in to post comments.