I’m do though think you perhaps mis-state the case for deploying 500-new name-your-software-here users frequently, and the similar business requirements. Rather than think of this as new users, think of it as a way to meet service levels while actually keeping fewer servers around and driving them as hard as you can. If you are not meeting your Outlook service levels and there’s some unused capacity on other servers, rather than just allocate new users that come online to the new servers, move 500 exiusting users…

However, I disagree where you suggest that a particular SaaS application’s ‘cloudiness’ is unimportant or, at least, less important than qualities you call out such as orchestration, visibility, and process dynamism. It might be true where the business has successfully implemented a SOA providing a dizzying array of benefits both long term and short… but for all the other businesses in the world (where SOA is a pipe-dream, or nightmare) the cloud qualities AND so-called plain old web application benefits can be hugely beneficial.

Some of those cloud benefits (eg “huge gains in flexibility”) are what would make a big difference to an enterprise today, rather than worrying about the orchestration of tomorrow. You could even argue that for many purposes something like rapid deployment is more important at the SaaS layer than at IAAS (not everyone needs to be able to deploy a thousand CPU’s in minutes).

Also, to an extent you’ve highlighted the tension between the different layers in the I-P-S-aaS triumvirate – for a proponent of one layer the success of any other layer suggests their own specific layer is less important (PaaS suggests IaaS should be abstracted out of consideration, for instance).

Or, that is my reading of your post (and perhaps it would make greater sense to have seen your presentation). I’ve never quite followed the SaaS/POWA axe-grinding, either, so perhaps that is clouding my vision (so many puns, so little time ).

* I’d argue that the common pyramid model of I-P-SaaS erroneously suggests some measure (more to less, low to high, etc) of relative differences (quantity, quality, cost, etc) between the layers. But on the other hand, it really isn’t a true stack whereby the layer above clearly and always depends on the layer below.

The key operational challenges for SaaS are the key operational challenges of any composite application that implements a business process. Visibility challenges, performance challenges, governance challenges. Whether or not some of the apps traversed by the transactions are run by a third party.

I am not saying that SaaS is not Cloud, I am saying that the 3-layer Cloud stack is not Cloud. It’s just one limited view of Cloud.

I’ll take a portion of the blame for the misunderstanding because of the title of the post. “Freeing SaaS from Cloud” really was meant to say “freeing SaaS from the Cloud-centric delivery/consumption/management model”. But there’s a reason why the comment form is at the bottom of the post. You’re supposed to have read the entry, not just the title, by the time you get to it.

So, +1 to the comment from “CloudCEO”.

I would in fact argue exactly the opposite – that it’s the infrastructure layer that could be dispatched… after all, in its current form it’s basically trying to emulate legacy systems in a virtual environment. Platforms are very interesting, but from a user’s point of view it’s the actual applications that deliver the most value.