Sunday, October 11th 2009 | Ismael Ghalimi
In 1943, Thomas J. Watson, then President of International Business Machines (IBM), allegedly said “I think there is a world market for maybe five computers.” Today, industry pundits make similar flawed predictions, claiming that all the market needs is maybe five clouds: Amazon Web Services, Force.com, Google AppEngine, Microsoft Azure, and whatever IBM comes up with. However you define Cloud Computing, this revolutionary step in the 50 year-long evolution of distributed computing (kudos to Daryl Plummer) goes far beyond the few public clouds available today. And while simple principles of economy of scales will most likely limit the number of general purpose public clouds, most of the action will take place on private and virtual private clouds, served from private and virtual private networks.
The need for private and virtual private clouds is driven by a combination of factors, many of which were clearly outlined by Gartner’s Bruce Robertson in his recent article titled Top Five Cloud-Computing Adoption Inhibitors (Gartner account required). Bruce felt compelled to add a sixth one (Vendor Viability), and we took the liberty to add a couple others, while slightly altering their designations.
When using the services of a public cloud provider, your options for risks assessment are rather limited. While compliance to industry standards such as SAS 70 or the publishing of auditable availability metrics in a trust.salesforce.com fashion can provide some level of comfort, they are not sufficient for proper risk management. Deploying a private cloud in your own data-center, or in the data-center of a trusted third-party (such as your local telecommunications service provider), will give you a more complete picture of the risks inherent to cloud computing.
As the saying goes, real estate is about three things: Location, Location, Location. While this might be counter-intuitive for those of us confusing cloud computing with ethereal computing (a concept I just made up and which makes no sense at all), the location of clouds really does matter, be it when talking about meteorology or computing. The geographic location of the servers powering a cloud has direct implications on how it will perform, and whether it will comply to specific regulations or not. For example, desktop virtualization requires low latency, which itself requires geographic proximity. Similarly, most database-driven applications will work only if the application sits really close to the data. And if you’re a retail bank, the data you collect about a customer must remain in the customer’s home country, as stated by law in many jurisdictions around the World. While the largest public cloud providers will certainly deploy multiple Points of Presence (Salesforce.com now has servers in four regions: North America, EMEA, APAC, Japan), many local cloud providers will emerge in order to provide geographic proximity to customers in the World’s 195 countries (as of today).
An application developed with Force.com can only run on the Force.com public cloud. And while many public cloud providers like to talk about interoperability, their objectives are to lock customers up with a proprietary architecture, API, or programming language. The choice is clear: Bluepill, half a dozen public cloud reluctantly agreeing to half-baked interoperability standards. Redpill, millions of private and virtual private clouds built on top of a common infrastructure. With no hesitations, I take the redpill.
As a I write this article, it is becoming clear that Microsoft/Danger lost all the data stored by customers on their Sidekick smartphone. Contacts, calendar entries, to-do lists, and photos are gone, following a botched SAN upgrade undertaken without proper data backup. Data loss is a huge concern for consumers and corporate customers alike, and private clouds provide an answer to this. For consumers, the deployment of reverse backup solutions such as the Egnyte Local Cloud (Disclaimer: I sit on Egnyte’s Board and originated the idea for the ELC) provides a virtually failsafe solution, at a very low cost. For corporate customers, the use of a private cloud implementing proper data backup and disaster recovery policies will significantly reduce the risk of data loss.
Many security experts claim that most corporations cannot afford the legions of systems administrators employed by the like of Amazon or Google to secure their public clouds, then conclude that public clouds are inherently more secure than private ones. This is either naive, dishonest, or plainly stupid. First, currently-available public clouds are utterly primitive when it comes to security. For example, VPN access is both a novelty there (Amazon just released the Amazon Virtual Private Cloud), and the very best they can offer (forget about two-factor authentication with devices like RSA SecurID). Second, the security of most public clouds currently available has been successfully breached over the past few years, usually through Denial-of-Service attacks or phishing methods, and the pace at which such events occur does not seem to be slowing down. Third, and maybe most importantly, a small number of homogeneous public clouds creates massive single points of failure. In essence, if a significant amount of the World’s computing and storage needs are addressed by half a dozen public clouds, any vulnerability in the security infrastructure of any of these clouds will expose over 15% of the World’s IT assets to unimaginable risks. This basic architecture simply makes no sense at all, and in a weird twist goes against the Internet’s distributed architecture, which enabled cloud computing at the first place. If we want secure cloud computing, we want millions of private clouds, not just 5 or 6 public ones.
Data confidentiality is one of the most difficult things to guarantee in a cloud computing environment. There are several reasons for that: First, as public clouds grow, the number of people working for the cloud provider who actually have access to customer data (whether they are entitled to it or not) grows as well, thereby multiplying the number of potential sources for a confidentiality breach. Second, the needs for elasticity, performance, and fault-tolerance leads to massive data duplication and requires aggressive data caching, which in turn multiply the number of targets a data thief can go after. Third, end-to-end data encryption is not yet available. What this means is that while data can be encrypted when transiting between the end-user’s client and the cloud’s server, and can also be encrypted when stored on the cloud’s server, it must be decrypted on the cloud’s server when being processed for a query or a transaction, unless fully homomorphic encryption is used. But until such a technology becomes commonplace (which will take quite a few years), data confidentiality will be maximized by using a large number of private clouds managed by trusted parties.
Local regulations will most certainly be the strongest driver for the deployment of private clouds. Many vertical industries such as financial services and healthcare, as well as the overall public sector (for both national and local governments) mandate that certain classes of data be stored and processed locally, in some cases by local service providers. While the deployment of local Points of Presence by private cloud operators will address such requirements in some cases (as it did for Salesforce.com when signing Japan Post as a customer in Japan), it will not be sufficient in countless others, and the deployment of local private clouds will be necessary.
Service Level Agreement
Another powerful driver for the deployment of private clouds will be the need for specific Service Level Agreements that public cloud operators cannot address, either because they’re not compatible with their business models, or because they cannot be supported by their technical architectures. For example, most public clouds today deliver three nines uptime today (99.9%, or downtime less than 8h45m57s per year), and four nines is a distant dream for all of them (52m36s). All the while, many customers require five nines availability (5m16s), which requires a technical architecture and a set of procedures significantly different from the ones deployed by most public cloud operators. Another area of concern is related to data ownership, as stated by user agreements. While some providers are pretty clear about it (Salesforce.com among them), others remain dangerously ambiguous (Google for example), making their clouds unsuitable for a broad range of applications.
Last but not least, the need for overall control will be the one predicating the use of private clouds for most organizations. While this alternative form of cloud computing might not offer the same economics or the same level of elasticity as the ones delivered by their public counterparts, it will always provide the extra level of control that large organizations crave for, and large organizations are the ones that will drive the adoption of private cloud computing platforms in the years to come.
Postface: This post might leave you with the strange feeling that while you get a pretty good idea for what a public cloud might be (AWS, Force.com, Google AppEngine, etc.), the concept for a private cloud is a lot less obvious. If that is the case, please refer to this presentation, or read my next article, titled Defining Cloud Computing for Business Users?
Note: As promised, this post on Cloud Computing will be followed by many others…
Entry filed under: Cloud Computing