Workload Analysis in Cloud Computing

Not all workloads are the same, and not all Clouds are the same!

Different applications have different set of requirements and characteristics.  Some Clouds (i.e. GAE or Heroku) are natural fits for certain class of workloads (i.e. WebApps) whereas for other types of workloads (i.e. batch), other Cloud services (i.e. AWS) are more appropriate.  In some cases, the business operation and/or legal requirements may require a completely different deployment (i.e. private Cloud). In a previous post, I referred to workload analysis in the context of approach to Cloud adoption. In this post, I thought to share some ideas about it.

The aim of Workload Analysis in Cloud Computing is to look at different aspects or characteristics of an enterprise application to determine the feasibility of moving or porting the application to the Cloud.  This analysis also provides input to implementation approach, Cloud service selection, and an initial business value assessment (i.e. cost reduction, IT simplification)…

The following proposes some guidelines in workload classification & characterization:

Workload Category: At a high-level, there are two kinds of applications in the enterprise:

1. Custom Applications – This class of applications are developed and maintained by the enterprise.  The enterprise has control over its design, technology selection, implementation,  infrastructure requirements, maintenance, and overall portfolio roadmap. 
2. Packaged Apps – For this class of application, the respective vendor is in control of its implementation, packaging, release, supported configurations, product plans, etc.

In the case of Custom Apps, If an enterprise is considering to deploy an application to the Cloud to achieve cost reduction or simplifying IT by delegating the infrastructure operation/maintenance to an IaaS, there is flexibility from simply taking the application pretty much as is to the Cloud –> re-factoring the application to leverage Cloud services (i.e. RDS).  In the former, the potential is substantial savings in infrastructure cost and business value in terms of new hardware & software purchase avoidance –> potential for much better SLAs and a lot more cost savings by reducing or totally eliminating the burden of additional FTEs (i.e. Database Administrators).

For Packaged Apps, the enterprise may or may not be able to move the solution to the Cloud due to licensing restrictions, technical infrastructure requirements, complex integration issues with other back-ends, etc… [it is good to check the packaged vendor for any existing or future plans for SaaS offering…]

Next, there are a set of general characteristics or attributes to consider when analyzing the applications:

• Workload Type: In general, there are two types of workloads: Batch or Online.  It is important to consider this differentiation for the following reasons:
• There are different resource requirements and considerations. As an example, batch workloads may require specific capacity in terms of storage and compute resources (i.e. vCPU, memory) to finish the job in a timely fashion whereas for online workloads network bandwidth may be more critical…
• There are differences in programming models.  As an example, some batch jobs may be implemented over a framework like Hadoop whereas for some online workloads a PaaS like Force.com may be the best choice. 
• Workload Frequency:  Sometimes, a workload may run at month-end or every quarter.  I like to note this attribute in the analysis for investment cost / benefit analysis.
• Workload Cost: It is important to capture the total cost of workload including hardware, software, application maintenance and support, etc.  I think it would be even more useful to develop a cost allocation model reflecting percentages in infrastructure, software, application development, support and maintenance, etc…  This information is useful in Cloud service selection.
• etc…

So, in summary, it is good practice to develop a consistent approach/process for analyzing workloads in Cloud Computing adoption.  This analysis has a range of use from business case justification to Cloud service selection. 

Also, as described in previous post, there are several sources of information to aid in workload analysis (i.e. Project Portfolio Repository, any existing server/application consolidation or decommissioning analyses, issues log or problem management database, etc). 

Finally, I highly recommend an excellent presentation that David Chou posted on his blog on patterns of moving to the Cloud…