“A Workload Elasticity Profile is a measure of the patterns of resource usage by an application(s) over a period of time.”
The Workload Elasticity Profile is often most critical in customers mind. It determines the financial benefits of cloud deployment and directly corresponds to the business model of the service provider. The result of a Workload Elasticity Profile model is the ability to develop a Return on Investment (ROI) analysis.
Seasonal – periods of higher workload focused around events that occur throughout the year. It is often the case that these events include periods of workload increases that are not uniform in length and very often unpredictable in volume because they are driven by external forces (economy, popularity etc..). Some examples of this type of workloads include; retail (xmas, thanksgiving, valentines), schools, tax, travel, employee benefits election, sporting events (olympics, X-games,..) and many more…
Batch - a generally resource (often compute) intensive workload that occurs over a fixed period in time or on-demand as needed. Performance is generally measured by total execution time (speed or consistency). Workloads include; payroll, billing, ratings, HPC, order processing, backup, etc..
Complex – is most often a common application and data set that is serving the needs of multiple business units. The patterns of usage are overlaid, creating completely random workload profile. Some of these include, end user on-demand reports, analytics, news events, marketing,…
Growth – predictable growth is not really a challenge, but when that approximated to exponential, and/or “hockey stick” growth, that becomes a greater challenge. The organizational process of deploying a new asset takes too long to meet demand. Workloads that match this pattern are often companies that have high growth strategies, including; social networking, open source downloads, iPhone games and a raft of other “new economy” businesses
Transient - this pattern is characterized by the reduction of the workload to zero. It is a workload which only exists for a period of time and then is no longer needed. It may again be needed in the future. The most classic workload associated with this would be Development, QA, Train and Test environments. Disaster Recovery environments might also be included in this category.
There are a couple of additional workloads that don’t necessarily conform to elasticity. They do however factor into the cost calculation.
Non-conforming – I considered removing this one as it is not really a elasticity issue. But it is very closely connected to the pricing model of the public cloud. It is basically a workload that requires a special infrastructure. This would incur major additional expense to integrate into the operations and support for a enterprise.
Micro - if the most basic building block of your internal infrastructure is a magnitude larger than the planned workload, then it could be more effective to ruin a smaller instance in the cloud. This type of workload is often related to a new project that is looking for adoption.
These show some basic profiles, but there is significant more complexity in the actual analysis of workloads. Some of these include;
- rarely does data exist for a full year, so data substitution is required
- business’s often do not know the demand cycles for this substitution
- workloads are often combined causing hidden patterns
- patterns at one layer of infrastructure are not always matched in other layers
- workload are often measured in averages
- existing workloads are not optimized
Once you have successfully modeled the workload elasticity pattern using real or manufactured data, you can then compare against service portfolio of cloud providers to determine which is the most optimal. A similar process can be used for private clouds, with a caveat, you need enough workloads to enable the resource pooling required to support elasticity. Workloads need to be able to share resources or you end up with underutilized infrastructure anyway.
In the next blog post I will dig into the financials of cloud architecture evaluation. Follow www.twitter.com/thearmadagroup for notification of blog posts.
Contributed by: Brad Vaughan