Incomplete Thought: Cloud Workloads – Really?
Over the last few weeks I’ve listened intently to many Cloud Computing discussions and presentations. I’ve read many blogs. I’ve listened to many podcasts.
There’s a residual theme surfacing and I have repeatedly observed a certain word creeping into the colloquy: workloads.
“Balancing workloads,” “distributing workloads,” “managing workloads,” “dynamic workloads…” it just keeps coming up.
I have a question:
Can someone please kindly define “workload” for me within the context of what the Cloud offers TODAY and how it relates to a typical large enterprise?
The reason I ask is that these conversations suggest we’ve reached some capability maturity wherein one can actually quantify Cloud workloads the way one might in a Grid or HPC context. I mean this beyond the simple scope of something like simple network load-balancing. I qualify this within the context of how an enterprise with a set of applications and information would ask it were they considering moving to the Cloud: “We don’t have ‘workloads,’ we have applications.’
I dare say that from a provider perspective you’d have different definitions also: Providers of SaaS would look at things differently than that of PaaS and IaaS. In fact, the further down the stack you go from SaaS to IaaS, I’d suggest the definitions get less and less granular as for the most part the packaging of an application/information gets more coarse from the provider’s perspective: a VM is a good example. Is THAT a workload or is it the processes, apps and data within it? See what I mean?
The way “workloads” are being bandied about, it seems to suggest that TODAY using “Cloud,” one is able to enable and trust autonomics and governance capabilities for any and all elements of compute, network and storage. It also implies that the points of integration are well defined and that the applications and data are separated. Nice theory, wrong Universe.
To me, we’re certainly not there in the enterprise space — in fact we’ve skipped over this critical step (Real Time Infrastructure/Adaptive Enterprise, etc.) in the hopes that we’ll mythicaly achieve this in the Cloud. I won’t bother to poke the bear with the arguments related to portability and interoperability.
(Ab)using this term and suggesting that we’re anywhere near being able to do anything with “workloads” when we can barely even get our arms around applications and service definition in the Cloud is laughable.
It’s writing checks the Cloud can’t cash.
Maybe it’s just me, but discussing “workloads” is another exercise in Shark Jumping today.
/Hoff
"Workload" is whatever the sales guy wants it to be. Just like the cloud.
I preface this by stating that I work at VMware, but from where I sit, the term "workload" has been around for several years. I can't speak for our pale-hearted competitors, but we use it as shorthand when referring to the application and operating system onboard a virtual machine. Sometimes the term also includes the VM itself, but in the strictest sense, it is *supposed* to refer to the contents and not the package. I suppose it could also include data, but that is usually irrelevant to enterprises that employ shared storage. Perhaps "payload" is a better term?
Anyway, I would argue that "service" is a much more convoluted term.