To answer the question first need to understand elasticity in the cloud. A simple definition is the ability to “scale-up” & “scale down” capacity automatically based on demand, and only pay for what is provisioned.
The issue is not the technology you implement. The technology that powers the public cloud is the same technology available to power the private cloud at every level in the stack. You can create a private cloud using all the same building blocks. The biggest issues is; Can you take advantage of this ?
Let’s think about the problem from two perspectives;
- Tactical - where time frame is measured in minutes and hours
- Strategic - time is measured in years and multiples of years
Tactical ElasticityThis is the most common problem space when people design private clouds. Creating a platform that auto-scales can be a technical challenge but if you are thinking about it this way, your going about it the wrong way. The first problem you should be solving is;
“Can your application scale?”
If you throw more infrastructure underneath it, will it respond with the ability to support more workload with the same level of performance? Will it do this automagically, or will it require modification (reconfig, recoding) at the application level to allow this to happen? At the utopian end of the scale you have a nice, horizontally scalable application that is designed based on infrastructure building blocks, providing “infinite scalability” (cough). It doesn’t have to be utopian though.
Mainframes & GridsElastic scaling based on older school technologies from mainframe (PR/SM, LPAR) and mid-range vendors (Domains, vPAR, nPAR, Containers) have done ostensibly the same thing with little modification to the application by dynamically configuring the resources from one domain to another. There are limitations to this method because it usually only works within a smaller pool of resources contained in a single or smaller number of racks/frames.
Grids are another architectural solution to this problem. They are essentially designed to provide the horizontal scalability at a operating system level in comparison to a classic cloud which requires that capability at the application layer.
Horizontal, in-box vertical and GRID all have limitations. The sensitivity to these limitations depends on the type of processing or I/O requirements, but they will always be evident at massive scale.
The next challenge is; “Do you have multiple complementary workloads?”
Many people have it wrong when they talk about the clouds dependency on multi-tenancy. Multi-tenancy (MT) is a proxy concept for complementary workloads. If you have multiple tenants with similar workloads then you have correlated peaks which result in low efficiency for capacity. You need complementary workloads for public or private clouds for tactical elasticity to work.
A complementary workload is where peaks in one workload correspond to troughs in other workloads. At a minimum, alternating peaks are critical to resource effiiciency. The more uncorrelated the workloads, the more benefit from elasticity.
Strategic ElasticityWhere the variable of time expands to between one and five years, then matching supply and demand is based on several different factors. The first is;
“What’s you gross average workload profile?”
The profile of your business volume is a key indicator for benefits from elasticity. It’s obvious that aggressively growing companies will get most benefit of elasticity. This is true tactically, but also strategically. The growing workloads allows for the constant consumption of capacity, giving the greatest flexibility. As this growth curve approximates to a flat line, the ability to provide elasticity becomes less and the efficiency of the infrastructure decreases. Therefore, gross workload explains the demand for capacity and its benefit from elasticity. For strategic elasticity, supply is dependent on the question;
“How dynamic is your asset lifecycle?”
As the normal volume of business ebbs and flows, the amount of physical infrastructure required to process the same workload changes. This creates a complex supply/demand curve that has a large dependency on the ways assets are acquired, and more importantly disposed. If your cycles of business approach a 1-2 year cycle, then your asset lifecycle needs to approximate the same timeframe. The financials of asset lifecycle should no longer be based solely on an asset depreciation schedule. Years of TCO calculation have already told us that sweet spot of asset disposal is based on the convergence of asset residual value, efficiency (power, cpu, space), vendor maintenance, support/management and licensing.
Elasticity QuotientHow much tactical or strategic elasticity is enough for a private cloud to be effective? The Armada Group uses an ‘elasticity quotient’ as part of its Cloud Evaluation Framework, Workload Analysis to determine the ROI of cloud deployment. It calculates the efficiency of matching supply and demand in comparison to a baseline of traditional capacity management. A positive number represents a benefit over traditional methods and negative number shows that the elasticity profile does not work.
SummaryTo have rapid elasticity (large +ve elastic quotient) in a private cloud you need:
- Ability to scale in the application
- Complementary workloads
- Faster asset lifecycle
- +ve gross average workload growth
(For the private cloud haters: Public clouds have the same problems, but at larger scale they can be less sensitive to some of the variables. Should another bubble burst, supply and demand could very well be out of sync for them as well, with even more serious consequences).
Contributed by: Brad Vaughan