Providing Insight Into the Cloud Computing Security, Privacy and Related Threats

Cloud Security Journal

Subscribe to Cloud Security Journal : eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Cloud Security Journal : homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

As discussed last week, cloud storage solutions differ in many ways. They can be defined by their pricing model (usage-based or capitalized), their location (on-site or off-site), the granularity of scalability (per-file, standard unit, or per-system), and whether or not they are multi-tenant. But one of the less-discussed but much more technically-challenging differentiators lies in the access method: Some cloud storage systems use a web protocol-based API for access, while others use conventional storage protocols like NFS or SMB. Today we will discuss the implications of which access protocol is used.

API Access: The Heart of the Cloud

One hallmark of cloud computing is its programmability: Developers can use standard Internet protocols like HTTP to both access and control resources programmatically. This incredibly powerful concept promises to revolutionize IT in the long run as applications directly leverage this flexible and scalable infrastructure. API-based storage access, for example, allows an application to directly request, configure, and deploy storage on the fly without manual intervention. It also opens the door to methods of content distribution and networked collaboration that we have not yet seen. The needs of the application, not the limitations of the interface, dictate how objects on a cloud storage system are shared, organized, and accessed.

But cloud storage APIs have some drawbacks as well. Since they are optimized for unpredictable Internet communications, storage APIs reestablish connection and state for each object access, making them "chatty" like SMB and unlike the streamlined block protocols like Fibre Channel. Cloud storage systems also include extra information, like metadata and management actions, not found in local storage connections. But the biggest stumbling block is the unfamiliarity of the various APIs: Applications must be specially-written to access this kind of cloud storage.

This has led to a whole set of storage gateways, easing the transition to cloud storage. Nirvanix, which uses an API for storage access, includes CloudNAS, a local gateway which allows conventional applications to access the system without rewriting. Third-party "data movers" are also integrating cloud API access to lower this barrier and allow more systems to take advantage of cloud storage.

Conventional NAS Protocols: NFS and SMB

Before there was enterprise storage there was NAS: Network-attached storage protocols hook into the basic file I/O systems of a client operating system, redirecting access across a network to a file server. The myriad of early proprietary protocols gave way by the mid-1990's to two: SMB (on Windows) and NFS (on UNIX). Today's computers generally support both protocols, with SMB and NFS clients and servers available across every server operating system, but the old affinity remains. Windows systems normally rely on SMB, while UNIX and VMware hosts rely on NFS. Macs support both, along with the Apple-only AFP.

NAS protocols are not altogether common in cloud storage, but many offerings do include them. Enterprise buyers of EMC's Atmos array, for example, get SMB and NFS, and many in-house Atmos deployments focus on NAS, ignoring the Atmos API altogether. Atmos-based service providers do not offer these protocols, however.

Blocks in the Cloud?

Although block storage access via Fibre Channel or iSCSI is popular in enterprise storage, it presents unique challenges for cloud storage providers. Block protocols based on SCSI or ATA are poorly matched to the realities of IP-based wide-area networks. They access tiny blocks of capacity (thus the name), demanding extremely low latency (quick turnaround for access requests). Block storage will not likely make the jump to Internet-based public cloud services.

One can imagine bridging block-to-cloud locally, though. A gateway application could easily encapsulate block storage requests in cloud storage objects, and this would work fine as long as the rate of access or network latency was low. Emulex is said to be developing a block-to-cloud bridge, for example, but the realities of the Internet will likely limit its use to locally-connected clouds.

A Bridge to the Cloud

In the long run, API-based access is likely to win the day when it comes to cloud storage. The compelling value of cloud computing arrives when the programmability of cloud APIs transforms IT applications. More and more enterprise applications are adding cloud computing and storage links natively, and these will present unique opportunities for IT pros beyond the current benefits of scalability and cost savings. The question is not whether to use a cloud storage API or not, but what to use until your applications are ready. Until this day comes, bridging applications will allow API-driven resources to be used by just about any current application.

Read the original blog entry...

More Stories By Stephen Foskett

Stephen Foskett has provided vendor-independent end user consulting on storage topics for over 10 years. He has been a storage columnist and has authored numerous articles for industry publications. Stephen is a popular presenter at industry events and recently received Microsoft’s MVP award for contributions to the enterprise storage community. As the director of consulting for Nirvanix, Foskett provides strategic consulting to assist Fortune 500 companies in developing strategies for service-based tiered and cloud storage. He holds a bachelor of science in Society/Technology Studies, from Worcester Polytechnic Institute.