Apps versus ops in the cloud

Although software as a service is perhaps the most visible face of cloud computing, it is only loosely related to how that term applies to computing infrastructures.

Gordon Haff
Gordon Haff is Red Hat's cloud evangelist although the opinions expressed here are strictly his own. He's focused on enterprise IT, especially cloud computing. However, Gordon writes about a wide range of topics whether they relate to the way too many hours he spends traveling or his longtime interest in photography.
Gordon Haff
2 min read

I'm often called on to explain cloud computing to people who aren't in the tech industry. It's hard. Sure there's some ambiguity in the term but that's not really my issue. It's also the case that some of the attributes associated with cloud computing like scalable, self-service, and so forth aren't necessarily that easy to put in layman's terms, at least without a lot of words and background. But that's not my core problem either.

Rather, I've come to think that my biggest stumbling block is this: When I talk about Google or an online application like Mint as an example of software as a service (SaaS), I'm not actually talking at all about what cloud infrastructure companies do and sell. So when I offer up a hosted e-mail or project management scenario, I'm basically doing nothing to illustrate what an IBM, an HP, a Red Hat, or even an Amazon Web Services has on offer.

Oracle's William Vambenepe articulates this nicely in his blog posting "Freeing SaaS from Cloud" when he writes:

I used this first slide (a compilation of representations of the 3-layer Cloud stack) to poke some fun at this ubiquitous model of the Cloud architecture. Like all models, it's neither true nor false. It's just more or less useful to tackle a given task. While this 3-layer stack can be relevant in the context of discussing economic aspects of Cloud Computing (e.g. Opex vs. Capex in an on-demand world), it is useless and even misleading in the context of some more actionable topics for SaaS: chiefly, how you deliver such services, how you consume them and how you manage them.

The three-layer stack to which Vambenepe refers has infrastructure as a service (IaaS), such as utility computing cycles and storage, at its foundation. On top of that is platform as a service, which adds higher-level functions such as automatic scaling. And then comes SaaS. The implication is that each layer builds on the one below. This can be the case and, indeed, there are numerous examples of cloud infrastructures morphing into something that looks more like a platform.

But especially in the case of SaaS, there is no inherent relationship between the infrastructure and the software services and applications running on it. Sure, cloud computing virtues such as flexibility and efficiency are ultimately in service of applications. However, many canonical Web applications don't run on computing platforms that conform to a strict definition of cloud infrastructure. For example, high-scale Web applications tend to be based on large, distributed, non-virtualized clusters--sometimes called a "grid."

Don't take this as an argument that SaaS isn't cloud or some similar definitional twaddle. Rather, take it as an illustration that, however useful "cloud" may be as shorthand for computing.next, it's pointless to talk about the evolution of application delivery (which SaaS largely is) and the evolution of infrastructure deployment and management (which IaaS largely is) as if they were a singular thing.