“Freeing SaaS from Cloud”: slides and notes from Cloud Connect keynote

I got invited to give a short keynote presentation during the Cloud Connect conference this week at the Santa Clara Convention Center (thanks Shlomo and Alistair). Here are the slides (as PPT and PDF). They are visual support for my bad jokes rather than a medium for the actual message. So here is an annotated version.

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.

In those contexts, you shouldn’t let yourself get too distracted by the “aaS” aspect of SaaS and focus on what it really is.

Which is… a web application (by which I include both HTML access for humans and programmatic access via APIs.). To illustrate this point, I summarized the content of this blog entry. No need to repeat it here. The bottom line is that any distinction between SaaS and POWA (Plain Old Web Applications) is at worst arbitrary and at best concerned with the business relationship between the provider and the consumer rather than  technical aspects of the application.

Which means that for most technical aspect of how SaaS is delivered, consumed and managed, what you should care about is that you are dealing with a Web application, not a Cloud service. To illustrate this, I put up the…

… guillotine slide. Which is probably the only thing people will remember from the presentation, based on the ample feedback I got about it. It probably didn’t hurt that I also made fun of my country of origin (you can never go wrong making fun of France), saying that the guillotine was our preferred way of solving any problem and also the last reliable piece of technology invented in France (no customer has ever come back to complain). Plus, enough people in the audience seemed to share my lassitude with the 3-layer Cloud stack to find its beheading cathartic.

Come to think about it, there are more similarities. The guillotine is to the axe what Cloud Computing is to traditional IT. So I may use it again in Cloud presentations.

Of course this beheading is a bit excessive. There are some aspects for which the IaaS/PaaS/SaaS continuum makes sense, e.g. around security and compliance. In areas related to multi-tenancy and the delegation of control to a third party, etc. To the extent that these concerns can be addressed consistently across the Cloud stack they should be.

But focusing on these “Cloud” aspects of SaaS is missing the forest for the tree.

A large part of the Cloud value proposition is increased flexibility. At the infrastructure level, being able to provision a server in minutes rather than days or weeks, being able to turn one off and instantly stop paying for it, are huge gains in flexibility. It doesn’t work quite that way at the application level. You rarely have 500 new employees joining overnight who need to have their email and CRM accounts provisioned. This is not to minimize the difficulties of deploying and scaling individual applications (any improvement is welcome on this). But those difficulties are not what is crippling the ability of IT to respond to business needs.

Rather, at the application level, the true measure of flexibility is the control you maintain on your business processes and their orchestration across applications. How empowered (or scared) you are to change them (either because you want to, e.g. entering a new business, or because you have to, e.g. a new law). How well your enterprise architecture has been defined and implemented. How much visibility you have into the transactions going through your business applications.

It’s about dealing with composite applications, whether or not its components are on-premise or “in the Cloud”. Even applications like Salesforce.com see a large number of invocations from their APIs rather than their HTML front-end. Which means that there are some business applications calling them (either other SaaS, custom applications or packaged applications with an integration to Salesforce). Which means that the actual business transactions go across a composite system and have to be managed as such, independently of the deployment model of each participating application.

[Side note: One joke that fell completely flat was that it was unlikely that the invocations of Salesforce  through the Web services APIs be the works of sales people telneting to port 80 and typing HTTP and SOAP headers. Maybe I spoke too quickly (as I often do), or the audience was less nerdy than I expected (though I recognized some high-ranking members of the nerd aristocracy). Or maybe they all got it but didn't laugh because I forgot to take encryption into account?]

At this point I launched into a very short summary of the benefits of SOA governance/management, real user experience monitoring, BTM and application-centric IT management in general. Which is very succinctly summarized on the slide by the “SOA” label on the receiving bucket. I would have needed another 10 minutes to do this subject justice. Maybe at Cloud Connect 2011? Alistair?

This picture of me giving the presentation at Cloud Connect is the work of Alex Dunne.

The guillotine picture is the work of Rusty Boxcars who didn’t just take the photo but apparently built the model (yes it’s a small-size model, look closely). Here it is in its original, unedited, glory. My edited version is available under the same CC license to anyone who wants to grab it.

14 Comments

Filed under Application Mgmt, Business Process, Cloud Computing, Conference, Everything, Governance, Mgmt integration, SaaS, Trade show, Utility computing

14 Responses to “Freeing SaaS from Cloud”: slides and notes from Cloud Connect keynote

  1. Pingback: William Vambenepe — Standards Disconnect at Cloud Connect

  2. While I appreciate the interest in separating SaaS from POWA, trying to exclude SaaS from the cloud computing stack effectively also excludes Google. Needless to say, that’s not right – just because Google focuses on the top of the stack rather than the bottom (like Amazon) or the middle (like Microsoft) does not make it any less a cloud player.

    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.

  3. I think I more or less agree with @samj on dispatching SaaS from the cloud. I do agree that some of the SaaS vendors may be closer to POWA than the cloud architecture, I don’t think we can completely take away the app stack. In fact, I know that the infrastructure of some of the SaaS vendors match closely with the so called private clouds and when we are ok with having private clouds as a part of the cloud ecosystem, I don’t see why we cannot have SaaS there. Having said that, I agree with you on the need to distinguish SaaS-washing from actual SaaS.

  4. CloudCEO

    Why are we still debating what is and isn’t cloud? Does it really make a difference? Imagine if all the effort we spend arguing over the definitions were, instead, spent on innovating?!

  5. I am not “trying to exclude SaaS from the Cloud”. My presentation had nothing to do with defining “Cloud” to include or exclude things. My point is only about pointing out what the important concerns and relevant tools are for different tasks. In the domain of SaaS, for most operational concerns (i.e. not sales and marketing), the “Cloud” (or on-demand) aspect of SaaS is often (not always) less important than the fact that the thing being delivered/consumed/managed is a Web application.

    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”.

  6. I agree with you (now that I have read your entry, oops, comment) :-)

  7. CloudCEO

    I didn’t read it. But I did stay awake for the presentation! :-)

  8. I agree that some of the Cloud concerns (“e.g. around security and compliance”) need to be solved all the way up and down the pile (it isn’t yet a true ‘stack’*).

    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.

  9. Well because it’s Friday… You can take the Man out of France, but not France out of the man. Glad to see you still look French(Just say no to Chinos!). Actually the joke may have fallen flat for the opposite reason, the audience didn’t understand there was any other way to access Salesforce.com.

    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…

  10. Pingback: Coté's People Over Process » Links for March 30th through March 31st

  11. Pingback: Coté's People Over Process » Links for March 30th through March 31st

  12. Pingback: William Vambenepe — The PaaS Lament: In the Cloud, application administrators should administrate applications

  13. Pingback: William Vambenepe — Reading IBM’s proposed standard for Cloud Architecture

  14. Pingback: » Will Clouds run on Clouds? Cloud Comedy, Cloud Tragedy