May 31, 2010

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--]

May 27, 2010

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.

May 25, 2010

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

May 19, 2010

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!

May 17, 2010

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.

May 14, 2010

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

May 13, 2010

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.

May 11, 2010

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.

May 7, 2010

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!

May 5, 2010

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.