Fear and Loathing in the Cloud

by Greg Roody

One question about the introduction of new and potentially game changing technologies is how much ”change” is required on the part of those wishing to deploy it.

Storage Clouds are a recent example, but examples go back to the dawn of open storage when you had to redesign your data center just to deploy something new, and that frequently meant doing a lot of work that wasn’t really your job.  You wound up doing things like dogging vendors to update device drivers, or playing phone tag with multiple support centers to get their products to work together.

In the case of Cloud Storage, it seems to be acceptable to require all applications to make API calls to a specific vendors Cloud Storage solution.  And this applies to Public as well as Private Cloud storage providers.  Even assuming a “common” API gains universal acceptance in our lifetime, it is still an API, and you will still need to program your applications to it.

You are asked to program the cloud just to be able to conduct business; a tax on innovation.  Sure, there are vendors that provide native access to Cloud Storage through an application such as backup or a volume manager. But these are still costly because you have only one choice of providers, one use case or operating system, and you must do it on their terms.

Beware applications bearing gifts…

Moreover, it takes the control over critical company assets – your intellectual property, personally identifiable information, and other restricted data sources – and puts them in the hands of application administrators (or *gasp* – end users) rather than corporate IT governance resources.

It’s your data. It’s your cloud.  It should be under your control.

The simplest response is to ban the use of the cloud as potential security leakage points.  All you need to do is look at the policies of large corporations when it comes to cloud products like Mozy or Carbonite for end users; most ban and block their use.

This is because users, rather than administrators, maintain control of the data – even after they are no longer employees.  The thought of attempting eDiscovery on dozens or thousands of disparate data pools is enough to scare any Corporate Governance leader to ban these uses.

A better way. . .

The key to successful data center change is to do it in a way that is non-disruptive to end users.  For example, VMware has no negative impact on the Guest OS’s in a VI or to the admins that support them.  What changes are the efficiencies to manage, provision, and protect application servers and their clients.  The changes are to infrastructure, not business applications, and that can be managed and controlled centrally.

Likewise with Cloud Storage.  Instead of writing to vendor specific API calls, the application servers should merely be presented with storage resources over a standard data center protocol like iSCSI.  No application or server changes should be required, other than changing or adding a standard storage mount point.

The clients shouldn’t know or care that they are using storage in the Cloud as opposed to physical disk sitting on data center floor tiles.  It should look, feel and taste like local storage and should offer local storage performance, security and functionality.  Where the storage resides should be up to the storage administrator, following standard policies and practices.

Non-disruptively Provisioning the Data Center is possible and essential

Functionality that is critical in this case for virtual arrays providing Cloud Storage is what has become standard in physical storage array’s;

  • thin provisioning
  • compression,
  • encryption,
  • zero footprint snapshots,
  • de-dupe
  • instant provisioning and timely reporting
  • Elastic storage capacity
  • Minimal capital investment

Further, the virtual storage array should talk to multiple Cloud Service Providers, simultaneously, allowing free transfer of data between them if needed.  Finally, it should itself be capable of being resident in the cloud.

Your Data Center is virtualized.  Your storage is virtualized.  Your cloud storage array should also be virtualized and capable of running anywhere, even on cloud computing platforms like Amazon EC2.

And like all data center storage – physical or virtual, the provisioning and control should rest in the hands of the Storage (or IT/VMware) administrator – not the end user or a distant system admin or application owner.  Yes, there is a case for self provisioning, but that needs to be done within the context of a controlled infrastructure, not completely ad-hoc and without any governance.

So when you consider Cloud Storage deployment options, consider whether you are deploying one solution that covers your whole enterprise, or whether you will have to touch and change each application environment one by one.


Tags: , ,


Leave a Reply