The notion of a workload is central to Cloud Computing, but a clear definition of this fundamental concept is more elusive than you might think. Essentially, a workload is a discrete capability or amount of work you’d like to run on a Cloud instance. For example, serving up a Web site or running a Hadoop node are classic examples of workloads. So far so good — but there’s more to this story.

First, a workload is an abstraction that implies portability. Serving up a Web site is one thing, but specifying a particular version of WordPress running on a particular LAMP stack, containing a specific collection of pages and corresponding data, requiring a certain processor and RAM footprint may provide the deployer with the information they need to run the workload, but is too low-level a description to provide for portability from on-premise to Cloud, or from one Cloud to another. Instead, a workload would be an abstract description of the capability or amount of work that could conceivably run in different physical environments that have unique configurations suitable to the underlying resources in play.

Second, the notion that a workload is a single discrete capability or amount of work shortchanges many types of workloads that you may come across in a real-world context: namely, distributed application workloads. For example, your workload may consist of Java Server Pages running in a servlet engine on a Web server, some JavaBeans running on an application server, and a supporting database running on a database server. You can think of each of these three capabilities as separate workloads, but then a single application would potentially consist of a variety of different workloads, defeating much of the purpose of the workload abstraction.

The best way to think about a Cloud workload, therefore, is all the individual capabilities and units of work that make up a discrete application. Allowing distributed apps to be single workloads brings the workload discussion closer to the business. After all, the business doesn’t care about the various pieces that make up a distributed app. They just want the whole kit and caboodle to do what it’s supposed to do, whether it’s on premise or in one Cloud or another.