More on Cloud and the Environment

Obviously I've been on hiatus for a little while, mainly due to work obligations (I was Sessional Lecturer at McGill University and taught Managing e-Business to BComm and MBA students this fall in addition to my regular responsibilities). So, without further ado, I'll get on with my post.

This past fall, Jirka Danek, CTO of Public Works and Government Services Canada (PWGSC) addressed an audience regarding cloud computing, the environment, and how Canada can be a leader in this space. I've had several discussions around these points and I'm happy to see that they've been heard and are being promoted.

Essentially, Danek discussed several factors that could contribute to Canada's leadership in the cloud computing space, including:

• Cheap, green energy--Quebec has an extensive hydro-electric power generation infrastructure
• Favorable climate--by virtue of the cooler environmental temperatures, cooling costs would be lower
• Government is moving towards cloud adoption as a means of reducing its costs
• The US, one of the largest global markets, is geographically adjacent to Canada

One benefit that he neglected to mention is the trickle down effect that such an investment would have on Canada's economy; the jobs created and taxes collected would help give Canada an economic boost.

This merits the industry's attention. The cloud market will grow* to $40.5 billion by 2014 (IDC) and $121.1 billion (MarketsandMarkets) and, since the technology is evolving rapidly and doesn't seem to be a huge competitive differentiator at this time, the larger future economic profits will go to those who have leveraged the cost reducing advantages.

* There doesn't seem to be any consensus on the market size and growth among industry analysts. Evaluation is done using various estimating methods and include or exclude various segments.

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.

Bill You, Bill Me

@benkepes tweeted about Aria Cloud Revenue Adapter for VMware vCloud Director which led me to his article on GIGAOM on the topic.

I agree with much that Ben says in his article (including the fact that the industry is perceived as commoditized, the erosion of revenue by third party services layered over top, and how utility based billing is an emergent market segment) and think that he's right on the market's movement.

What I can not agree with his assessment that billing is a "non-core function". This really shouldn't be the case; billing is core to every business' operations. Why, then, should cloud service providers have to rely on third parties to provide them with a solution?

The way I see it, there are three options:
1) License a complete solution that you will leverage to provide your services,
2) License a billing solution and develop the cloud offering (or vice versa),
3) Build your own solutions.

Of course, this is a classic 'build-or-buy' scenario. It is true that buying is sometimes cheaper. However, relying on a third party's services is not without risk and costs. By some accounts and from personal experience, vendor/partner/contract management often accounts for perhaps 25% additional costs that are often not captured correctly or understood completely. Not to mention switching costs when a cheaper alternative comes along.

In the end, the decision is a financial one that considers the costs involved in the development of such a tool, and I understand that. The bottom line for me is that the billing tools should be built alongside the product offering. Many organizations could be eligible for R&D and/or HR tax credits to offset the additional expense. For those organizations that have been around a while (like VMware) it probably makes more financial sense to buy than to build. Those organizations who are new to the market should consider building while their operating costs are relatively low. (No, billing spreadsheets are NOT the answer.)

To paraphrase and echo Ben, using tools from a third party is fine if you have high margins, but these costs, however low they may be, will cut into profits faster for a lower margin product. Develop your own solution then sell it to those who can't or don't want to. See? There's a new revenue stream!

ROI Can be Higher in a Private Cloud

A random white paper I read used the words, "...increase infrastructure ROI..." when discussing virtualization of servers. These words are not typically used in the context of cloud based services because everyone is so preoccupied with the benefits of using the public cloud.

In public cloud parlance, ROI us usually used in a comparison of the costs to buy infrastructure vs. the cost of using resources on demand in the cloud. In private cloud vocab, ROI means just that: return on investment. So, how does an organization "increase" the ROI for capital assets? By virtualizing and adopting cloud best practices for automated provisioning and deprovisioning-in other words, creating a private cloud. If usage of the asset is increased, then the return on the initial investment can be increased as well.

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.

Fear Rogue Workloads!

"Enterprise IT is under pressure to transform from bottleneck to business enabler. The rise of public cloud services such as Amazon EC2 have provided a clear example of what enterprise IT is expected to become: A simple, self-service on-demand infrastructure provider. IT organizations that fail to make this transformation will watch in vain as rogue workloads follow the path of least resistance to the public cloud."

How's that for using fear as a marketing tool? That was the introductory paragraph for an invitation to join a webinar on transforming the IT organization into the purveyor of on-demand services.

Of course, they're right at a certain level. Anyone with a credit card can spin up an instance and have your data crunched, client information or sensitive documents stored off your secure network, or generally in an environment that has not been vetted according to your organization's security practice.

So, how then, does one go about transforming the IT organization into a 'business enabler'? It seems to me that this same question was posed a decade ago when IT budgets were running rampant and accounted for a significant chunk of an organizations expenses.

This particular situation has arisen not because IT is not a business enabler, but because of a perceived lack of flexibility, long delivery times for IT service requests, and expense policies that, while originally robust, now have loopholes that allow anyone with a credit card to acquire off net compute power.

Any potential solution should include the following:

1. Revise IT processes to increase flexibility in meeting user requests.
2. Review IT service metrics to determine delivery times and work to reduce them.
3. Refresh expense policies to take into account this new reality and educate employees about the new policies and how they will help reduce risk for the organization.

In general, this requires an update of the organization's governance structure to ensure that its processes are adequate to manage this new technology, whether it is a planned introduction or not.

Another way that IT can help resolve this problem is to partner with a cloud services provider or identify an approved vendor for future demand of cloud based services. Of course, this requires that the organization have a more mature level of understanding of what cloud based services can offer as well as the will to adopt these services before such a relationship can be created.

Employees under pressure to perform and meet goals will follow the path of least resistance to achieve them. Perhaps management should consider clarifying employees' roles in this context as well and in parallel to all other efforts.

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.

More on ROI and the Economics of Cloud Based Services

InformationWeek::Analytics issued a report earlier this month entitled, "Cloud ROI: Calculating Costs, Benefits, Returns," which compares the costs of acquiring hardware and the costs of utilizing cloud based services and the associated ROI. While the basic analysis of the costs makes sense, the comparison is flawed: the difference between the two is cost savings, not ROI.

The spreadsheet attached to the report is fairly straightforward. All costs involved in the acquisition of capital assets vs. leased assets (i.e., on demand) and the related costs are listed and compared. A present value calculation is performed to show the total cost of ownership over a number of years. It is evident that cloud based services are cheaper than acquiring capital assets for the same purpose. This forms the basis for the ROI calculation but the report never actually calculates the ROI; it gives the reader just enough information to be misinformed...

To make the numbers make more sense, the report needs to add a revenue stream. That revenue stream would allow the reader to find the breakeven point. And, if there was enough time, the report could go further and examine the impact of asset lifecycle and the replacement of capital assets versus using leased assets over time. In this case we would see the economic value of using assets on demand instead of acquiring them.

The one statement, from Lew Moorman, Chief Strategy Officer of Rackspace, with which I agree is that organizations need to evaluate how to make cloud based services fit into their IT service catalog rather than whether they can save money by migrating everything into the cloud. The latter discussion is probably not going to be very productive since not all services can be or should be moved into the cloud though, financially, it might make perfect sense. IT and Finance often butt heads.

In previous posts (here and here) I discussed ROI of Cloud Based Services and how it is often confused for cost savings, touching briefly on the concept of breakeven.

Cloud Security Alliance - Canada Chapter

I've decided that I'm going to start working on building the Cloud Security Alliance (CSA) - Canada Chapter. There seems to be interest so I thought I would write up a quick entry to see if anyone was interested in joining the Canadian chapter.

The CSA is a fledgling organization dedicated to "promote the use of best practices for providing security within Cloud Computing, and provide education on the uses of Cloud Computing to help secure all other forms of computing." As of this posting, there are 2 official chapters and 5 chapters in development. In addition, there are several working groups:
Group 1. Architecture and Framework
Group 2. Governance, Risk Management, Compliance, Audit, Physical, BCM, DR
Group 3. Legal and eDiscovery
Group 4. Portability & Interoperability and Application Security
Group 5. Identity and Access Mgt, Encryption & Key Mgt
Group 6. Data Center Operations and Incident Response
Group 7. Information Lifecycle Management & Storage
Group 8. Virtualization and Technology Compartmentalization
Editorial Group
Educational Working Group
Solution Provider Advisory Council

It's obvious to me that the questions of governance and security (issues important to me) are not going to go away by themselves. Nor should it be left solely to industry to develop competing views/models/tools - it's simply inefficient. It behooves us, the denizens of the industry, to help in those efforts.

Please let me know if you are interested in joining the CSA - Canada Chapter by sending your coordinates (name, company, title, email, phone) to pano(dot)xinos(at)gmail(dot)com.

[Edit: added working groups. --PX--]

Jurisdiction, or, I have to comply with whose laws?

Judith Hurwitz, of Hurwitz & Associates, has a slide in one of her presentations that refers to protecting data in the cloud and reads, "Government and Industry regulation must be adhered to regardless of the location of your applications and your information."

The first thing that popped into mind was the classic 70s cop show scene where the cops, all sporting mutton chops and polyester leisure suites, are arguing about ownership of the crime scene...

The next thing that popped into mind was how confusing this must be; organizations have to be aware of, and comply with, the laws and/or regulations that apply to their operations in the country where the application(s) and data sit as well as their own country's. There can be no other interpretation of the slide because we know that privacy laws in Europe can be tough and those in the US are different but yet there is an expectation of data privacy in both jurisdictions. The slide deck contains several examples ranging from specific country laws, co-mingling of data, secondary data use, and the next point, data transfer across borders.

What about data in transit? Is data subject to the laws and/or regulations of the jurisdictions through which it passes en route to/from the site hosting the application? There are restrictions on sending data out of some European countries unless the receiving end complies with European requirements on data security, but what of the countries in between? Data stored in Europe usually go through gateways to get to North America and then through a gateway into the US, Canada, or Mexico and vice-versa. I suppose that the argument can be made that data in transit over backbone infrastructure is not susceptible to attack. But then I recall a certain government agency that wanted to snoop Internet data streams not too long ago...

What of the end users' expectation of privacy? If these users are in yet another country, can the requirements of that country be imposed on the applications' owner? Can lawsuits be filed in this case?

The simplest and most efficient solution would be to comply with the common requirements and the most stringent requirements from each country in order to be compliant with all. Not sure if this is the answer but it seems that it could be. Then again, I'm no lawyer so I may be wrong here.

"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!

What, exactly, is ROI?

The acronym, ROI, means 'return on investment'. In other words, if I make $1.10 for every $1.00 spent on a project, my return on the $1.00 invested is 10%. Used in the context of cloud computing, this is incorrect.

When we talk about the economic benefit of cloud computing, we assess the difference between the total cost of ownership (TCO) of owning and operating the necessary infrastructure to make our applications available to customers and the TCO of of leasing that same infrastructure on demand. All else being equal, more than likely, the cost of owning and operating will be higher than leasing on demand. This is a cost saving proposition, not a ROI. In this case, we should be looking at the breakeven point--the point in time at which we have paid off the expense and get into the black.

What is usually missing from the evaluation of these cost savings is the sunk cost of application development: either way, those $ are going to be spent and are considered to be an investment. Aha! Now we're talking about investment. If TCO is (assumed) to be lower when leveraging a cloud environment, then it follows that the ROI will be higher.

Consider the following basic scenario:

Note that the OPEX is higher in the lease/on demand scenario. This is because most of the CAPEX that would have been incurred in an ownership scenario become OPEX in a lease/on demand scenario. So, when comparing the ownership and lease/on demand scenarios, the economic benefit, or return on the initial development investment, would be greater in a cloud based scenario. If we had considered an pre-existing application and its displacement to the cloud, then we would have been discussing a cost savings, and not a ROI.

Organizational Governance and Cloud Based Services

InformationWeek published a story on their site about how IT departments are 'losing ground' on cloud computing. The premise is that individuals in the organization are adopting cloud services with or without IT's knowledge and/or approval.

The article suggests that this is a security issue which, at the end of the day, it is. But, security is a part of information and organizational governance and, as such, this should be treated as a governance issue. If IT can't control usage of cloud services by the organization, is this a failure of IT or the organization? I can understand why someone would just use a credit card to get what they needed done sooner than later. However, this is no excuse for ignoring organizational business practice and compliance policies. In some organizations this would be grounds for dismissal.

Granted, IT departments can be slow. How, then, can IT help resolve this problem? How can IT be part of the solution? Clearly, employees need to be sensitized to the risks and issues surrounding their use of cloud based services in the organization and who better to do so than IT? Of course, this should not be taken to mean that IT should scare the bejeesus about of them, rather this should be an ooprtunity for IT to move closer to the employees and the business by seriously considering cloud based services and their impact on the organization, good or bad.

A great quote from the article: "Hello: it's 2010 and do you know where your data resides?"

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!

Inaugural post

Well, here it is. My platform. To sum up, I’ve been following cloud computing for a long time now and have decided to start posting my thoughts on this revolutionary technology. Yes, I used the word ‘revolutionary’. I could have also called it a ‘paradigm shift’ or ‘game changing technology’ because this is exactly what it is and will be.

In this blog I will concentrate on the business issues surrounding cloud computing leaving the technical and standards issues to other, more qualified, individuals; afterall, it’s been a long time since I’ve done anything technical… I hope to make this blog informative and critical and will try to post at least once a week. If you feel that I’ve strayed from these goals, please feel free to drop me a line.