The Cloud Value Chain

Consumers of cloud computing have clamored for a more unified approach to the services they use, be it IaaS, SaaS, PaaS or some other cloud based service. The knee jerk response is to federate services. While the approach is sound, allows seamless access across services and would in theory provide some modicum of security, this does not necessarily mean that they are provided by the same cloud services provider (CSP) leaving the consumer to manage relationships and SLAs with multiple CSPs. One possible solution is for CSPs to be a one-stop-shop that allows customers to create value by building up the stack, so to speak.

Pause------------------------------------------

Before we get any further, let's keep in mind the classic pyramid diagram of cloud computing:

OK, it's a cheesy graphic, but we all understand that software (SaaS) is built on programming platforms (PaaS) which are run on infrastructure (IaaS). Clearly the graphic is not drawn to proportions because the SaaS market has outstripped the IaaS market. An inverted pyramid wouldn't cut it either because PaaS is a smaller market than IaaS. (Maybe an hourglass shape... But I digress.) A variant would be a more Application Service Provider (ASP) model where software is installed on an IaaS-based instance and offered for the use of customers. This latter variation is not strictly speaking SaaS but is a reasonable hand drawn facsimile.

Unpause----------------------------------------

Let's say one such CSP has launched a cloud computing service that offers these services to customers (say IaaS, PaaS, and SaaS to keep it simple and avoid getting into any sticky discussions about cloudwashing).

So now we have a stack based on software created by software vendors or by the open source community on which value can be created. CSPs add value by tying the three service models together and offering them transparently to customers; CSP customers add value by using the tools to write apps and programs that their customers in turn use. Hence a cloud value chain. This, of course, does not take into account value added by cloud brokers or aggregators.

The interesting bit is what happens when the app is written and then launched. The current typical development cycle sees a dev team working to create an app and then making the architecture fit the app. This is backwards and I have lived it firsthand through cloud RFPs. This is because there is a gap in the knowledge and understanding of cloud computing among developers and their management. Schools generally don't teach students to write programs with cloud computing in mind. They teach them to write stand alone apps and programs that can be run on individual servers or, more often than not, in VMware-based virtual machines--AKA, the application service provider model.

The ASP model is inefficient because it relies on individual servers (whether virtual--no this is not cloud computing--or physical) to deliver the service and defeats the purpose of cloud computing: the flexibility to acquire only those resources necessary to meet demand.

In a perfect world, customers would acquire a SaaS seat via some self-service portal; the app or program would automatically create an instance or partition for that customer; and the app or program would be written on a PaaS to make it somewhat self-aware: that is, capable of making use of APIs to scale IaaS according to demand without mucking about with middleware. This raises the ugly spectre of vendor lock-in, but then, if you like the service, it meets your needs, and is flexible as you need it to be, why would you move?

Can we talk about SaaS for just a sec?

Don't know about you, but I've been inundated by emails, banner ads, sponsored links, LinkedIn group updates, tweets, and Facebook ads all announcing that some product is now available in a SaaS format. Yes, even by word-of-mouth. It occurred to me that many of these companies may not even know what the as-a-service moniker even means.

I recently sat in on a cloud-101 type presentation by Dan Koffler and, in his presentation, he discussed the interrelationship between IaaS, PaaS, and SaaS. To sum it up, IaaS supports both PaaS and SaaS implementations, and PaaS supports SaaS implementations. This brings up an interesting point: does SaaS conform to the NIST standard definition of cloud computing? Here's an excerpt of the NIST definition:

Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure 2.

 The footnote at the end of that sentence reads:

2 A cloud infrastructure is the collection of hardware and software that enables the five essential characteristics of cloud computing.

And, as we all know, one of the essential characteristics is "Rapid elasticity". The fact that the upper service model(s) are served by the lower one(s) indicates that any true SaaS implementation would necessarily be elastic. This is the true test of whether a product is SaaS or an ASP (application service provider) implementation where the software is simply hosted on a server.

So, the next time a vendor pitches you on a SaaS product, ask them this question: "Does the product's resources (i.e., compute power, RAM, storage) scale automatically as my organization reaches predetermined usage thresholds (e.g., % utilization of resources or number of users)? Or do I have to call you to increase these resources?" If the answer is "Yes," and "No," in that order, it's a true SaaS implementation. If the answer is "No," and "Yes," it's ASP and you should definitely ask what the SLA is on the vendor completing the request.

Whatever the answer, I assure you that the answer to this question will be telling. Whether the sales rep knows the answer or not will interesting in and of itself.

Two years on and SaaS is still around!

I came across an interview I read a while back (August, 2008) in which Harry Debes, CEO of Lawson, claimed that SaaS was a passng fad that would pass like its previous incarnations, "service bureaux" and "application service provider".

Well, here we are, two years later, and SaaS has picked up steam. The main strength of SaaS is the huge savings on CAPEX that Debes neglects to mention in his interview. It's true that, on the surface, SaaS appears to be a form of software license financing; a monthly charge per user that includes licensing and support/maintenance instead of an upfront license fee and annual maintenance fees.

That said, there are benefits for both the customer and vendor. The customer, obviously, benefits from the reduced investment in infrastructure required to run software on premises. The vendor, however, can leverage the same environment for multiple customers which increases the utilization rate of the infrastructure but lowers the monthly cost to its customers (or pockets the extra margin).

Organizations use SFDC because it works and it's relatively cheaper than installing servers and DBs to run a CRM application on premises. If it were not available in a SaaS format, would it be as popular? Possibly. But if it didn't work that well, would it be as successful as either a SaaS or on premise offering? Probably not. The market has a way of weeding out bad software.

Theoretically, all software that is offered on premises and as a service has a tipping point at which the decision to build or buy is made. This is why, regardless of what Harry Debes or Larry Elllison say, organizations need to evaluate the costs of each option, the total cost of ownership, and make an informed decision based on that information and not the hype.

To Charge, or Not To Charge: That, Is The Question

An acquaintance of mine recently commented to me that "...startups that offer freemium services are doomed to fail..." Google defines freemium as follows: "Freemium is a business model that works by offering basic Web services, or a basic downloadable digital product, for free, while charging a premium for advanced or special features." This would seem to settle the discussion, but the argument that was made was that the vendor is basically giving away the product. We see this today in various cloud service providers and especially so in SaaS providers.

Ultimately, this is true: a company with no revenue is not likely to succeed. However, a company with no customers is equally unlikely to do very well. The idea behind the freemium model is that users of the free product a) see the value of the product and decide to buy the premium version so that they are supported (freemium users may not be entitled to vendor support); or b) need access to some feature that is locked and only available in a paid subscription.

Logical, no? To an extent. Success as a vendor in this case is measured in the conversions of freemium users to paying subscribers. This metric, depending on the vendor's business plan, should be used to decide how aggressively the vendor should pursue users in order to try upselling the premium version.

The bottom line is this: customers will use a product for free, but for how long before they move on; vendors should upsell their customers and entangle them as soon as possible to avoid high freemium churn rates and to increase the conversion rate. The trick is finding the feature balance between the free product and the premium product.

City of San Diego Reported to Outsource IT Services

GovTech reported that the City of San Diego is ready to outsource some IT services including help desk functions, laptop, desktop, and database server management.

Within the article, the City reportedly consolidated five email systems into one. Oddly, there is no mention of migrating any services into the cloud as various city and state governments have already. It would seem that migrating to a SaaS model, such as Google Apps, would generate a cost savings by simply reducing removing  license fees/maintenance contracts and person-hours required to maintain on-premises servers and productivity apps on upwards of 10,000 desktops and laptops.

That said, the article doesn't mention whether the City's licenses are up for renewal nor the asset lifecycle. So, it is entirely possible that such a migration is being considered. We may yet see an announcement to that effect in the near future.

"Cash-Starved Governments Look to Cut IT Maintenance Fees"

Interesting article at Government Technology about government organizations trying to cut costs by reducing maintenance fees. Not that this is real news since many "cash-starved" organizations are trying to cut costs. It makes you wonder how this will play out. Maintenance fees can range anywhere from 18% to 24% of net costs with the typical rate set at 20%. If vendors give in, their revenue streams suffer and they have to make up the difference elsewhere by increasing services costs or product pricing to satisfy shareholders.

On the other hand, cloud based services do not have maintenance surcharges (they're built in to the pricing model). The States of Oregon and Arizona have adopted Google Apps in their education system and the City of Los Angeles was actively debating it last year as well. But does SaaS serve government as well as on premise hardware and software?

Well, it all depends on your governance model. Cloud providers are feverishly working on securing their offerings in order to attract customers. However, it begs the question: can clouds be as secure as your own network? I suppose it is possible, but your network is secured according to your own governance and security policies. Unless the provider agrees to secure the environment according to your policies, it may not be sufficient. Add to that the fact that availability and SLAs suffer with multiple providers (99.99% telco uptime, 99.5% cloud provider uptime = 99.49% effective uptime guarantee) and we see why governance is a major issue facing cloud adopters, not the least of which is governments.

That said, it would be surprising if security and governance concerns would not be resolved. It seems to me that those organizations that would benefit most from cloud will modify their governance policies accordingly and cloud providers will improve their offerings so that the two will meet at some compromising middle ground. Is this the beginning of the end for maintenance contracts? I don't think so, but I bet they're going to change as cloud gains traction...

More on Cost Savings and ROI

I recently came across the following Google ad on a UK web site.

(The ad, admittedly, was much more fun to watch on the site, with spinning dials and all...)

It was also a link to a calculator to estimate the cost savings that an organization could realize by migrating their users from the traditional MS Office suite (Outlook, Word, Excel, PowerPoint, etc.) to Google Apps provided over the web (Gmail, Docs, Spreadsheet, Presentation, etc.). (This link brings you to the international version of the calculator.) The site allows visitors to calculate their potential savings on a 3 year engagement based on the number of users served, the hourly cost of the IT manager's time, and some basic assumptions on hardware and license costs. By itself, this is a compelling argument to switch to SaaS.

The interesting thing about this ad, is that Google called it the 'cost savings' and not the 'ROI' of switching to Google Apps. The calculator does the calculations and then shows the costs of both MS and Google scenarios and the difference in TCO between the two. If one is lower than the other, there is a cost savings for switching to the solution with the lower TCO.

Kudos to Google for getting it right!

Cloud and Environmentalism

I recently read a blog post by Reuven Cohen regarding the environmental impact of cloud computing. As an answer to his question regarding cloud's impact on the environment, we can safely say that, all else being equal, making use of cloud computing in an existing data center has a smaller environmental impact (i.e., CO2 emissions) than building a brand new data center in which to house your server and applications (whether it would be a private cloud or not). However, my statement requires some explanation: when I say 'cloud' I mean making use of resources in the cloud (IaaS, PaaS, SaaS, storage).

Greenpeace, however, does not distinguish between 'cloud computing' and everything on the Internet in its report entitled, "Make IT Green: Cloud Computing and its Contribution to Climate Change". In their defence, they do identify growing (indirect) use of cloud resources by consumers of social media applications (Facebook), storage (Flikr), SaaS (Google Apps), etc. However the analysis includes all network infrastructure required to operate the Internet (!) as well as the specific cloud infrastructure used to provide these services.

On the other hand, the point that Greenpeace is trying to make is that the growth of usage of cloud based services will require the buildout of additional capacity in square footage, infrastructure, and power consumption. The building of the facilities and infrastructure is a sunk carbon cost (which might be subject to energetic efficiencies in and of itself) but the generation of power required by such a facility is variable and forecast to increase over the foreseeable future.

Adapted from, "Make IT Green: Cloud Comuting and its Contribution to Climate Change", Greenpeace International, March, 2010.

Such power generation is largely by coal fired and nuclear plants. Therein lies the problem. Interestingly, while CO2 emissions associated to power consumption increases across the board for the various regions between 2007 and 2020, their relative percentage decreases for all except one, China, whose emissions by far exceed those of the other regions largely due to its reliance on coal for power generation.

The bottom line in Greenpeace's report is that our use of cloud based services will inevitably increase over the coming years and that the carbon footprint of the organizations that provide us these services will inevitably get bigger. By making use of these services, we become polluters by proxy. It behooves us to apply pressure to those organizations that provide us these services, and to lobby our local, state/provincial, and federal governments to take notice of this issue; they are the ones who can force real change by enacting legislation.

The case has been made that cloud based services can deliver economic benefits to organizations, but those benefits, and the overall economic growth that can result, should be leveraged to find a more sustainable way of delivering these services.

Cloud Computing: Nomenclature Issues

The nomenclature for cloud computing, or the model for services consumed on a utility basis, has drawn much criticism and caused much confusion.

For those of you who are not aware, cloud computing draws its name from the fact that IT resources are "in the cloud", meaning that they are somewhere on the Internet, off your network. (A stylized cloud is often used to represent the Internet in architecture diagrams.) The most common term for cloud computing is the "as-a-Service" suffix: infrastructure (IaaS), platform (PaaS), software (SaaS), and storage (such as Amazon's S3). Clearly, IaaS and PaaS are derived directly from the hardware and development platforms and provide users with instances of the underlying resources on demand while storage is the use of storage media as a resource. SaaS, however, poses a problem: is software "cloud computing"? SaaS splits the community into two distinct camps: yes, SaaS is cloud computing because it is available in the cloud; no, SaaS is not cloud computing because you are subscribing to software on a monthly basis (unlike the utility model for IaaS and PaaS).

The NIST defines cloud computing as follows:
"Cloud computing is a model for enabling convenient, on demand network access to a shared pool of configurable computing resources (e.g., networks, servers, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models."

This definition leaves a bit of room for interpretation. Because of this, I propose alternate terms: "Cloud Based Services", "Services in the Cloud", or "Cloud Services". Each of these terms indicate that the services are consumed (be they IaaS, PaaS, SaaS, or storage) are located or based in the cloud and do not confuse the issue of SaaS being a compute resource per se.

While the terms "Cloud Based Services", "Services in the Cloud", and "Cloud Services" are not revolutionary, they clarify the concept and are inclusive of the various forms of cloud computing.

A private cloud, by any other name, is a private cloud

In March, Tom Fisher, of SuccessFactors, was a guest speaker at Cloud Connect in Santa Clara. During his chat with M.R. Rangaswami, of Sand hill Group, he stated unequivocally that private cloud computing was simply a data center and that SaaS was cloud computing.

The problem with that statement is that it isn't completely wrong. Many organizations have a data center footprint and house servers on which they install software that is used throughout the organization; this is an application provided as a service, or, if we stretch a bit, SaaS (it's a stretch in my mind because there is no notion of multi-tenancy). Logically, then, if SaaS is cloud computing, and it is software that is installed on a server that is housed in the organization's data center, the organization is making use of a private cloud. To use Tom's analogy, "If it walks like a duck, it quacks like a duck, it's a duck." But I digress...

Back to the issue at hand. By itself, server virtualization is not cloud computing. However, if the organization were to automate the rapid provisioning and de-provisioning of the virtual resources using whatever home-grown, open source, or COTS middleware, then the organization is leveraging cloud computing on its own infrastructure--a private cloud. Server virtualization allows the organization to more efficiently utilize its servers' capacity whereas cloud computing increases the organization's agility, ability to rapidly test and deploy services to meet varying demand needs, and reduce its appetite for capital. Whether the infrastructure is around the world or in the organization's own data center is irrelevant.

Quack, quack!