Recently in Cloud Management Category

According to a recent Gartner press release, 20% of businesses will own no IT assets by 2012:

Several interrelated trends are driving the movement toward decreased IT hardware assets, such as virtualization, cloud-enabled services, and employees running personal desktops and notebook systems on corporate networks.

The need for computing hardware, either in a data center or on an employee’s desk, will not go away. However, if the ownership of hardware shifts to third parties, then there will be major shifts throughout every facet of the IT hardware industry. For example, enterprise IT budgets will either be shrunk or reallocated to more-strategic projects; enterprise IT staff will either be reduced or reskilled to meet new requirements, and/or hardware distribution will have to change radically to meet the requirements of the new IT hardware buying points.

This is a bold statement. If we believe Gartner, it means that we are at the beginning of an explosion in cloud-based services managed by trusted providers on behalf of the enterprise. Of course not all businesses will choose this path, but a substantial number of industries can and will. As I blogged about earlier, the message from the CFO office is clear. We will see adoption rates rise dramatically as the benefits of cloud services become more obvious to business leaders.

A second point of interest is the prediction that by 2012, India-centric IT services companies will represent 20 percent of the leading cloud aggregators in the market (through cloud service offerings).

Here’s the take-away:

Gartner is seeing India-centric IT services companies leveraging established market positions and levels of trust to explore nonlinear revenue growth models (which are not directly correlated to labor-based growth) and working on interesting research and development (R&D) efforts, especially in the area of cloud computing. The collective work from India-centric vendors represents an important segment of the market’s cloud aggregators, which will offer cloud-enabled outsourcing options (also known as cloud services).

We are witnessing examples of what GE innovation consultant Vijay Govindarajan calls reverse innovation in IT. Natarajan Chandrasekaran, the CEO of Tata Consultancy Services notes:

I’ve seen the new cloud-based computing models for applications and processes gaining currency in emerging markets. Rural cooperative banks and small and medium businesses in India are actually far ahead of their western counterparts in adopting these models. In fact, companies from emerging markets, buoyed by strong domestic revenues and revival in growth, have been making adjustments to their global strategies and fine-tuning their investments in order to be part of the recovery process in the west and build on their global expansion plans.

As the enterprise embraces the cloud, they’ll need a maturity model to help them on their journey. My next post will explore what the maturity model for cloud storage looks like. 

A recent report by Forrester's Andrew Reichman titled Business Users Are Not Ready For Cloud Storage: Current And Planned Adoption Of Storage-As-A-Service Is Minimal For Now paints a picture for cloud storage adoption, that at first blush, is not encouraging.

He states:

In Forrester's Enterprise And SMB Hardware Survey, North America And Europe, Q3 2009 survey, we asked businesses about their interest in "hosted storage capacity" offerings. Interest was minimal at best. Forty-three percent of all respondents said that they were simply not interested, and another 43% said that they were interested but had no plans to move forward.

While it could be argued that as a cloud storage supplier, I am necessarily bullish about the ultimate prospects, I believe the data is actually quite good and clearly represents what we are experiencing in the marketplace.  Now, Mezeo is engaged with many service providers, as well as the early adopters in the enterprise space as they begin their evaluations.

When I look at enterprise cloud-storage adoption based on Everett Rogers' diffusion curve I see a pretty clear view of the typical market place approach to adoption of disruptive technologies:    

For new, emerging, and potentially disruptive technologies, we should look for what the next practices are, i.e. the practices of the innovators and early adopters. The survey reflects the typical technology adoption cycle and re enforces what we are experiencing in the market place.

11% of companies are taking the plunge - these are the early adopters and innovators.  The early majority (43%) is interested, and watching.  The late majority is not in the game, yet.

So we are on track. And to prove it, let's look at one of these enterprise-level innovators: General Electric.

According to IBM storage expert Tony Pearson, GE has implemented cloud-based backups and archive for GE Corp, NBC Universal and GE Asset Management divisions running at only 32 cents per GB/month, representing a 40-60 percent savings over their previous methods. This includes backups of their external Web sites, archives of their digital and production assets, RMAN backups including development/staging databases. They plan to add out-of-region compliance archive in 2010. They also plan to monetize their intellectual property by offering "CloudStorage Manager" as a software offering for others.

We define hybrid cloud storage as utilization of private cloud storage at an enterprise data center, or a private cloud hosted by an IT service provider with some combination of additional IT service provider-based public and/or private cloud storage.  

In a recent post, Cloud Storage for the Enterprise - Part 1:  The Private Cloud, we covered the definition and requirements of cloud storage as an enterprise solution, and as a technology deployed within enterprise-owned data centers (or at least within their co- location racks and cages).  Fundamentally, a private cloud is also a non multi-tenant cloud (i.e., used by only one entity or related parties within an enterprise or a public sector agency) that is behind the firewall(s).  An additional solution that many enterprises are contemplating is the hybrid cloud, and we will look at the aspects of that solution in this post.  

Before we begin our investigation of hybrid cloud, let's review some of the basics.  The following diagram reviews the differences between public and private clouds:


Many enterprises are beginning their cloud evaluation with a "private cloud."  I extend the definition of private cloud to be a "single tenant" cloud, as some enterprises may chose to use a single tenant cloud hosted at a service provider, versus hosting their cloud within their own data centers.  In the following diagram, we show two private clouds, connected via policy-based replication in two data centers.  This provides the assurance of backup and disaster recovery that many enterprises require.  A third location could easily be added for even higher levels of backup and disaster recovery.


The growth of storage is driving increased costs, and the enterprise is on a continuous search to improve the way they can cost-effectively manage this growing data.  The primary difference between hybrid cloud and private cloud is the extension of service provider-oriented low cost cloud storage to the enterprise.  The service provider based cloud may be a private cloud (single tenant) or a public cloud (multi-tenant).  There are several implementations of hybrid cloud, and several examples are included.   The service provider cloud may enable enterprises to leverage the volume efficiencies of the service providers to realize additional savings. 

A hybrid cloud provides a way of securely using service provider-based cloud storage in combination with enterprise clouds.  Another implementation could be use of single tenant service provider-based private clouds at multiple locations. 

Some examples of hybrid clouds are offered for your consideration, although not every potential approach is covered herein:


Since the primary motivation for hybrid cloud is economics, let's begin the discussion with an understanding of the economics of cloud storage and then extend that discussion to the hybrid cloud environment. 

The primary cost components of cloud storage include:

1.    Data center occupancy - leased (co-location) or owned and depreciated.
2.    Data center environmental - utilities, cooling, heating, etc.
3.    Storage hardware (leased expense or capital requirements & associated depreciation).
4.    File system and storage management (may be bundled in the storage hardware).
5.    Cloud enablement or platform (discreet or bundled with the storage system).
6.    Systems management and operational overhead.
7.    Backup and disaster recovery.

While it can be argued that the economics at a large scale enterprise are very similar to those at a service provider, listed below are some of the most common reasons enterprises do turn to service providers for their technology solutions:

1.    Capital conservation.
2.    Distraction associated with infrastructure management.
3.    Desire to outsource functions that are required but not associated with core competency (focus dilution).
4.    Poor history of infrastructure management.
5.    Specific issues, for example, out of data center space and not projecting long term needs to add additional data centers, or unable to expand existing data centers and no desire for an additional site.
6.    Redundancy of networks available in data centers that may not be available in the enterprise with assuming additional costs.

Whatever the reason, service providers can solve these problems.  In each of the three hybrid cloud scenarios, there are costs and security tradeoffs that each cloud use-case will consider.  For example, in hybrid cloud variation #1, the economics can be quite appealing, but there are significant security concerns.  One approach to mitigate these concerns is to encrypting an object before replication to a public cloud might mitigate the threat.

Understanding where key functionality is applied in your cloud stack is critical for successful implementation and highly dependent on the cloud and storage subsystem technology, cloud interoperability capabilities, and data use case.  Critical technologies that provide benefits are: de-duplication, compression, encryption for data at rest and data in motion, geo location, geo replication, tagging and search capabilities, and cloud access methods.  I will address underlying cloud technology requirements for the enterprise in my next post.

Cloud Use Case Definitions:

Data Archiving - Storing data for retention management requirements (such requirements may be internally generated, or associated with regulatory and compliance needs).  Archive data must be highly secure, highly reliable over the archive period, and easily searchable.  Archive data is generally encrypted, compressed and stored in a proprietary format. Access to the data is usually very infrequent and thus typical enterprises have leveraged slower access, cheaper tape media or redundant NAS to control costs.  Typical data issues associated with archiving are maintaining the archive and eliminating what is known as bit rot of the data, which is where data becomes corrupt if stored in the same media for long periods of time and not accessed.

Data Backup - Storing data as a replacement copy in the event the original copy is somehow damaged or lost due to user error, system failure, or as a result of a disaster scenario.  Back up data may or may not need to be highly secure or easily searchable, but must be available for quick restore when needed.  This data is also generally encrypted, compressed and stored in a proprietary format. Access to the data is more frequent than with archive data and can be at any level of the organization.  A single file, user, server, site, or the entire enterprise could potentially need to be restored to proper service and backup data must support these highly variable access needs.

Data Access - Storing data in its original format for access by users or other applications.  This type of data is frequently accessed and is the superset of the data that comprise backup and archive data.  Access takes precedence over security, but needs to be easily and quickly searchable and retrievable by users and applications and thus highly available.  Typical issues with access data are the need for fast accessibility of frequently used data balanced against the overall cost associated with storing all the data.  Enterprises often implement tier strategies to stage data in progressively lower cost media based on frequency of access.


Hybrid cloud storage, which we have loosely defined as utilization of private cloud storage at an enterprise data center, or a private cloud hosted by an IT service provider with some combination of additional IT service provider-based public and/or private cloud storage, offers an approach that allows use case, economics and security to prevail when selecting the appropriate approach.  Implementation will also be driven by the technological capabilities of the three building blocks of cloud storage, the cloud abstraction layer, file/object system choice and storage subsystem hardware.

So, our discussion of hybrid cloud storage has likely demonstrated at least one significant additional aspect, and that is complexity.  Starting with use case definition and security requirements, combined with a clear understanding of the unique issues within each enterprise that effect cost, you can map a clear path to the cloud technology and selection of one or more cloud service providers.  Finally, the trusted service provider continues to be another significant requirement for exploitation of hybrid cloud.

1. Security will continue to be a big issue for the cloud, and, unfortunately, there will be at least one event this next year that is disruptive to Cloud Storage adoption, be it data loss or unauthorized data access.  Security will be an even more important point of evaluation for the use of specific Cloud Storage service offerings. The “trusted service provider“  becomes a requirement when selecting a cloud offering.
   
   
2. Cloud Storage will be characterized by a single word, “more”!  More adoption, more cloud storage offerings by more IT service providers, more variation in cloud capabilities, and more worries and concerns about the cloud.
   
   
3. The intersection of enhanced mobile devices with better wireless bandwidth will be combined with Cloud Storage to create exciting new work/life blended digital life applications. The user experience is of paramount importance.
   
   
4. Cloud Storage will see extraordinary adoption as a solution for backup, archiving and for policy-based georeplication for disaster recovery.

CloudStorageStrategy.com welcomes OpSource CEO Treb Ryan for an in-depth interview on cloud computing, from the perspective of the service provider.

NOTE: OpSource is a customer of Mezeo Software, the underwriter of this blog.

What are the opportunities you see in the cloud computing space, both for OpSource and your customers, and what impact has the downturn had on this?

It's interesting, but when people talk about cloud computing, they immediately go to the downturn and pricing - and cost being the big driver.  There's no question that cloud computing is cost effective, and it's accelerating adoption many times over, but what we're really seeing is something much more fundamental - a generation of users who are entering the workforce who've been using cloud computing all along; they've grown up on the Internet, and their interface to technology has always been through the Internet. 

As a result, this "Cloud Generation" has clear expectations of how technology should work:

1) it should be immediately available,
2) you do a search and get going,
3) it should be very flexible,
4) you should have ubiquitous access - anytime, anywhere,
5) sharing and collaboration - the expectation to collaborate and share anything they are working on.

This is not a generation which distinguishes between work data and home data - like my generation did. They've grown up with the concept of APIs and communities that grow around them; for instance, we see programmers who have grown up with Google and Facebook APIs, and now they expect that kind of thing in their work applications as well. So they're coming into the workforce and driving change in the workplace. They see technologies like client-server applications or hard-coded storage arrays pretty much the same way my generation saw green screens, mainframes, and mini-computers - as dated, inflexible, technology - hard to use, without nearly the power of cloud-based systems. So they have the day-to-day experience of the "consumer cloud" which they're now driving into business applications as well. 

To the Cloud Generation of programmers this means anything they can interact with on the Cloud they can program to through APIs. The idea of infrastructure being an item that can be addressed as part of the application, instead of something the application lays on top of, is a radical concept.  It has allowed not only for innovative applications, but also for true elastic computing making the Cloud environment even more flexible.



Great Cloud offerings have great communities around them. This is the aspect of Cloud computing that is so often missed - and even scoffed at - by the IT folks who think it's all about virtualization. One of the biggest gripes about Cloud computing is that support is done by the Community and not the vendor. While most will agree that far more proactive vendor support is necessary for Cloud computing, Community support is just as critical. For questions of configuration and usage tricks, the Community is a far better source of information than some call center employee with limited access. Often the Community devises more innovative solutions than the vendor ever could. And in addition to support, the Community can create third-party add-ins that make the Cloud even more useful.

The downturn has accelerated adoption from the top down as well.

We're seeing executives who have become enamored with this idea of the cloud - because of the ability to turn capital expenditures into operational expenses - and are pushing cloud computing into their organizations.  The CEO of one of our customers went so far as to tell his technical people - "now can you finally start using the cloud so I can get the board off my back?"

So, for different reasons, we have both top-down and grass-roots support for cloud-based applications, which makes this very interesting to say the least.

Which customer segments do you see leading the way in adoption?

Obviously, our traditional focus has been on ISVs and start-ups coming into Software-as-a-Service, business applications in the cloud, and we're seeing continued adoption of cloud infrastructure by those segments, but what has been interesting is that now that we offer the ability for any company to buy and use cloud infrastructure for any type of application, we're seeing a much broader spread of usage and adoption. Beyond the enterprise we also see widespread adoption by systems integrators, consultants, and VARs - upto 40% of our customer base - all without us targeting that segment at all.

How does OpSource differentiate its cloud offerings from other service providers?

We offer the best of the public cloud, combined with enterpise security and compliance, performance guarantees, and enterprise controls.

For instance, we offer:

• easy online sign-up & purchase with infrastructure provisioning in minutes
• pay by the hour and only for what you use, with no commitment (or purchase a monthly plan for a discount)
• a rich online community to share and collaborate with peers; get third party add-ins, images and configurations
• a web interface plus complete set of APIs

On the straight cloud, we provide a lot of the more robust, enterprise tools than you see from more consumer-based providers like Amazon, for example.

We focus on three different areas:

1) Security and Compliance: we provide a much more secure environment, because Opsource provides every customer with a Virtual Private Cloud within the public Cloud, allowing them to determine their own degree of public Internet connectivity. We also provide:

• Unique customizable security for firewalls
• VPN administration of all servers
• Unique username/password for each administrator
• Audit logs of all environmental changes
• SAS 70 audited
• 100% uptime SLA

2) Performance: we offer a multi-tier architecture with guaranteed latency in-between systems, sub-millisecond access time, industry standard technology, like VMware, instead of open-source, because that's where enterprise is comfortable.  Our 24/7 suppot also makes a diffence.

3) Control: today's cloud environment are single user environments, one user name and password, which is fine for individuals, but not so useful for the enterprise. We offer the ability to provision multiple users, do things like cross departmental billing, execute policy based control - which user can do what - and finally link all that back though an API to your existing management systems. So you can control how your users use the cloud same as you do your corporate datacenter.

So do you see any links into these large companies where they need to use ITIL for systems management?

Absolutely. OpSource has always focused on compliance as a major issue for our SaaS customers, eveything from SAS 70, PCI to European Safe Harbor, and even industry-specific ones like HIPAA, or government-specific certification, but in the cloud, we think about sophisticated  management techniques like federated authority and single sign-ons, and things like ITIL - while it's still in its infancy, it's shocking that most providers don't even have the ability to give their customers the critical capability to have more than one person manage the cloud for them - because they have a single user accounts. So while you can institute more sophisticated IT governance regimes like ITIL with the OpSource cloud, we give IT the capability to manage who does what, and track who did what, even if they aren't ready for something like ITIL.

So IT gets to do their own provisioning?   
  
Yes. So you want to know who provisioned what, how much it costs, and we give them that visibility instantly across their entire user community.  That way there are no surprises or charges they aren't aware of. It sort of reminds me of the controls I had to put in to alert me to my daughter's texting costs - so I'm aware of the charges before they get out of hand! I just blogged about this issue.

That's why you say that OpSource is what Amazon wants to be when it grows up... 

Absolutely.

And that's how you respond to cloud critics - the ones that say that the Cloud is not yet ready for the enterprise.

There are large parts of the cloud that are not yet ready for the enterprise. The cloud is still young, and it would be like asking that first 286 PC to run all of your corporate financials. However, a lot of these issues around enterprise adoption like security and compliance have been addressed, and are being taken care of, so as the cloud becomes more robust, we'll see increased adoption. We're seeing enterprise-level capabilities come to market that did not even exist six months ago.

We have just signed a partnership agreement under which OpSource will resell Gomez's Web performance management solution to our enterprise customers as well as use it to validate and monitor our own cloud performance service level agreements (SLAs). Through this partnership, we'll bring powerful performance monitoring to cloud computing, making it easier and more compelling than ever for enterprises to justify bringing their applications to the cloud.

Do you see infrastructure elements like storage growing now?

For true, full use of the cloud, we have to have the ability to access storage, go though the APIs to get to it, and give our customers a range of storage solutions, including cloud storage based on the specific application or need. We're giving our customers the widest range of choices.

What about agile programming? I heard you use agile methods to improve the customer experience.

Agile programming methods have helped us with not only development, but compliance and security as well. We talk to our customers to see how they are using our cloud offerings though our community, and we learn what's important to them.

We also test our offerings by having two programmers work on the same keyboard - literally  - one with the user story - so they can make sure that the customer is getting the exact functionality they need.

It's agile customer service.

Can you tell us a bit about your enthusiasm for composite applications (corporate mashups) and how they help your platform?

Of all the phenomenon in the cloud, we see the need for anytime-anywhere access and the idea that anything I can interact with I should also be able to program to.  So when Facebook enthusiasts start working in the enteprise, they bring their enthusiasm for integration as well.

So we see things in the cloud like direct access to the infrastructure as part of the application, which allows for all sorts of flexibility and robust usage.

We see real-time reporting applications of every kind you can imagine.  I myself am addicted to checking on everything that's coming out of our billing and customer systems tied into our Salesforce tabs.  So I'm always checking on the business in real-time via my iPhone.

I say this a lot, but integrating SaaS is a huge issue for today's enterprise. OpSource Connect can help SaaS companies -- of any size -- overcome integration hurdles and break out of the SaaS-only box. This speeds up adoption of SaaS in larger enterprise environments, opening the door for on-demand companies to cultivate business with large systems integrators. Plus, I'd say we're the only company providing Web operations from the ground up, addressing operational infrastructure, application management, and business operations. Today, integrations are expensive and one-to-one. For instance, while you can currently integrate your application with Google Maps as a composite application, OpSource Connect lets you integrate your app with many others, using just one platform. You can integrate your application with, for example, SAP, salesforce.com, Intuit QuickBooks, NetSuite, and a host of other SaaS and legacy applications. 

Everything is much more dynamic today, and programmers expect that. 

As the industry announcements on Cloud Storage APIs keep coming, the confusion surrounding what they mean keeps growing.

We have the Amazon S3 APIs, Eucalyptus APIs, Rackspace Cloud Files APIs, Mezeo APIs, Nivanix APIs, Simple Cloud API, along with the standards proposed by the Storage Networking Industry Association (SNIA) Cloud Storage Technical Work Group, and more. 

So what should you do or think about all this? What impact do these Cloud Storage APIs have on your decision-making? Just how important are they, and what's next?

Here's some information to aid your understanding of this emerging and important technology.  Let's begin by answering two basic questions: 

What is a Cloud Storage Application Programming Interface (API)?
    
A Cloud Storage Application Programming Interface (API) a method for access to and utilization of a cloud storage system.  The most common of these are REST (REpresentational State Transfer) although there are others, which are based on SOAP (Simple Object Access Protocol).  All of these are associated with establishing requests for service via the Internet. 

What is REST? 
REST is a concept introduced in the doctoral dissertation of Roy Fielding, and is widely recognized as an approach to "quality" scalable API design.  The actual API design and capabilities are very dependent on the actual capabilities of the underlying Cloud Storage System

One of the most important REST capabilities is that it is a "stateless" architecture.  This means that everything needed to complete the request to the storage cloud is contained in the request, so that a session between the requestor and the storage cloud is not required.  Why is this important?  The Internet is highly latent (it has an unpredictable response time and it is generally not particularly fast (when compared to a local area network (lan)).  Once you get a request, there is no guarantee that you can ask a "qualifying question" of the requestor in a reasonable time period.  So, REST is an approach that has very high affinity to the way the Internet works.  Traditional file storage access methods that use NFS (network files system) or CIFS (Common Internet File System) do not work over the Internet, because of latency.

One other thing we should clear up:  Cloud Storage is for files, which some refer to as objects, and others call unstructured data.  Think about the "files" stored on your PC, like pictures, spreadsheets and documents.  These have an extraordinary variability, thus "unstructured".  The other kind of data is "block" or "structured" data.  Think data base data, data that feeds transactional system that require a certain "guaranteed" or low-latency performance.  Cloud Storage is not for this use case.  IDC estimates that approximately 70% of the machine stored data in the world is unstructured, and this is also the fastest growing data type.

So, Cloud Storage is storage for files that is easily accessed via the Internet.  This does not mean you cannot access Cloud Storage on a private network or LAN, which may also provide access to a storage cloud by other approaches, like NFS or CIFS.  It does mean that the primary and preferred access is by a REST API.  (Here are other terms you will see, RESTful, or RESTlike or RESTstyle, which is geekspeak for how closely the API conforms to the REST approach.) 

Today, there are multiple definitions for Cloud Storage, and the one I prefer is "File Storage accessed through Web Services API's over a network".  This represents the key attributes of file storage that is cloud storage, versus other types of file storage.  Other key qualities of a storage cloud are:

• multi-tenant support (use by more than one unrelated user)
• geo location and geo replication, seamless and real time provisioning of accounts
• seamless and real time provisioning of accounts
  
• availability of "practically" unlimited amounts of storage "on-demand"
• "pay for use", which means that your payment is for actual storage used, over some time frame, usually a month. 
  

There are many who are still arguing about what I have defined above, but what I've said is generally accepted by the industry.  If it is a vendor doing the arguing I would suggest you check under their hood, usually you will find that they do not offer whichever of the above features they are trying to argue out of the definition.

Also, traditional storage vendors continue to proclaim the importance of local network access (like NFS, CIFS or ISCSI) for the purpose of Cloud Storage access by applications that today can only access via the older protocols.   This requires that the application making the request be on the same local network (think same data center) as the storage cloud.  Their reason for this view is that they are only just beginning to see application demand for storage cloud access via REST APIs, versus their traditional business model which serves an enterprise user with their own data center. 

This is why Cloud Storage has generally emerged as a service offering in the IT Service Provider  (also know as the WEB Hosting Industry) space first.  In this space, there is no doubting the importance and future of REST API access to storage clouds, it is only viewed as an adoption speed issue.  Note that within the data center, access to storage using an HTTP based protocol is not necessarily any slower than one of the more traditional protocols. API access has been labeled as being a slower form of access over NFS and CIFS. This view is largely due to the fact that it "may" be accessed over the Internet. In most cases, it is the network that adds the latency, not the means of access. Make no mistake, traditional storage vendors see this coming, and they will make offerings available in the near future.

REST APIs are language neutral and therefore can be leveraged, very easily, by developers using any development language they choose. Resources within the system may be acted on through a URL. So, an API is not a "programming language" it is the way a programming language is used to access a storage cloud.  This is part of the basic understanding of APIs that is required to discuss the dreaded "vendor lock in" and upcoming "cloud lock in" discussions and understand the issues that surround these assertions.

REST APIs are also about changing the state of resource through representations of those resources. They are not about calling web service methods in a functional sense. The key differences between different Cloud Storage APIs are the URLs defining the resources and the format of the representations.
 
The Cloud Storage space is very young and everyone has their opinions on how things should be represented and accessed. Efforts are underway by organizations like SNIA, with their Cloud Data Management Interface (CDMI), to standardize both the resource structure and the representations. However, standards are not developed overnight and customers are demanding programmatic access to Cloud Storage now.

Current Cloud Storage vendors have produced a basic set of APIs that are accomplishing fairly similar things, and other APIs that expose the underlying unique functionality of the Cloud Storage platform supplying the storage cloud.  You should expect that, over time, most storage clouds will provide the basic functions in somewhat similar ways, and further that additional advanced functions will be adopted and expected to be in every storage cloud offering. 

Finally, you should look for a taxonomy of APIs, that includes basic file functions, advanced functions, Provisioning APIs, Billing APIs, and Management APIs.  Storage clouds that become successful will offer all these capabilities, to increase the efficiency of their use.



 
Several efforts have been made to simplify the transition between vendors by providing an abstraction layer on top of the vendor's APIs. In this approach, a program library is created, for use in the application that needs cloud storage access, and this API translates (for the given program language) a single API into the API that is specific to a Cloud Storage offering.  So, the application, which is using this library, writes their APIs once, and achieves portability between storage clouds that are supported by this approach.

This approach has been largely programming language specific and may take advantage of the language it was designed for. Good examples of this are jClouds, an open source cloud storage abstraction library written in Java, and Simple Cloud API, a collaboration of vendors including Microsoft, Rackspace, Nirvanix, IBM and Zend which provides a simplified Cloud Storage interface for PHP developers. While extremely useful for developers, these abstractions tend to expose the lowest common denominator relating to Cloud Storage functionality and may omit critical features, for example only providing namespace object access as opposed to ID access.

So, let's discuss lock-in, the term used to express concern that once a vendor has gotten you to exploit their architecture and technology, they will recognize that you are committed to them and cannot easily move away.  As a result, they will then raise their prices and take advantage of your lock in status, keeping their price just below the amount that would encourage conversion away from their technology and towards a more "open" set of capabilities.  Let's look at all the "dreaded" examples that have been surfaced around cloud storage and as a reason to slow it's adoption:

1.    API lock in, which means your interaction with a storage cloud uses the APIs of that storage cloud, and suggests that you cannot easily move to another providers cloud with their own, different APIs.

2.    Vendor lock in, which means that since you are condemned because of your application development activity with specific APIs to use only a cloud from a specific supplier.

3.    Device lock in, meaning that you developed a cloud storage based program utilizing the APIs of that specific cloud, for a specific device (generally a PDA) that has specific functionality.  This is double lock in, both the device programming methodology and the API selection.

4.    Browser lock in, meaning that programming to specific APIs can also be rendered unique based on the Web browser that is selected.

5.    Programming language lock in, which means that you have written the APIs in a language like Python, or JAVA, or .NET, or whatever.

6.    API wrapper lock in, which means that you incorporated libraries into your application that allows your application to write generic APIs, which are then translated by these APIs to the correct API for the desired storage cloud (this is what Simple Cloud API is).

So, as you can see here, utilizing cloud storage could ultimately have you locked in on at least six levels! 

With this much opportunity for vendor abuse, why are developers rushing to write Web based applications that utilize cloud storage services via API access?  Are they simply uncontrolled, unthinking rebels who will shortly learn the error of their ways?  Have they made a fatal error?  Or do they know something you don't?

First, learn about Cloud Storage APIs.  What they do is make storage programmable, and they abstract storage from the application.  They offer advanced functionality (the programmable word) that makes it faster and easier to write the applications that are scalable versus the traditional storage access approaches.  When you add these two capabilities to the storage cloud offering of low cost, availability in multiple locations, seamless provisioning, ease of adding additional storage, and the pay for use model, the case for the cloud has become compelling.

Where are we seeing early adoption:  at service providers, because they host Web based applications and SaaS (usually Web based) applications, and this is where the developers who recognize the opportunity are focused. 

What is coming: the introduction of this technology into the enterprise, complete with the adoption of the RESTful API technology.  This will ultimately lead to a level of cooperation between service providers and the enterprise that has long been predicted.  Enterprises will move to an IT modeled on an OPEX model, and expect their applications to be provisioned and interacting with service provider clouds, via APIs.  IT Service Providers are racing to build the clouds to provide for this emerging business opportunity.

So, what about the lock in mentioned above.  Sit down with your developer, they will show you why they don't feel "locked in".  They will show you that you can quickly recraft your current APIs, in the programming language of your choice, to utilize the new APIs of the desired cloud.  For this reason, Simple Cloud API will likely be a short term measure, which precedes base case APIs that are extremely similar, and goes through a market led process to identify "best practice" APIs for both base case and advanced function, as well as all the other API led capabilities as mentioned above.  In short, vendor lock in is not the problem for this technology that it has been for others.  Also, the ingenuity and resourcefulness of all the suppliers, standards groups, and market adoption scenarios will continue to mute your ability to be lock in free. 

Your real challenge is not lock -in, but rather how to adopt this new set of capabilities, and solve problems and create opportunities with your IT solutions as rapidly as possible.  Standing on the sidelines waiting for this one to resolve will keep you out of a great opportunity, because we still have several meaningful years of rapid change associated with this technology adoption cycle. 

The announcement that Salesforce is integrating directly with cloud-storage Box.net is the tip of the iceberg when it comes to the future of the cloud:

Techcrunch explains what Box.net is thinking:

CEO Aaron Levie says that this is the first step in Box.net's plan to give businesses a secure way to share their files across multiple services on the web. He says that many of the cloud services geared toward the enterprise don't work well together -- oftentimes you'll have to reupload the same content to multiple sites to share or edit it. Box.net wants to help unify these services by serving as the central hub for your uploaded files, which you can then access from these other web-based services. Levie hints that we'll be seeing more integrations with other services in the near future.

What we are witnessing is the future of enterprise IT infrastructure. We have been talking about programmatic access through RESTful APIs for some time now.  This move by Saleforce is an evolutionary step in how enterprise IT will manage its IT infrastructure - it will be a cross-cloud platform, with applications and open access to the storage cloud of your choice.

Security is not an issue, and the future is about cross-cloud collaboration.

Phil Wainewright says that Box.net wants to be the "Switzerland of Data" - he's right and wrong.  Cloud Storage, provided by the various service providers are going to be the "switzerland of data storage."  Vendor lock-in is going by the wayside.

ReadWrite is spot on when they say that "you can start to see how platforms will evolve into service networks - where enterprise users may subscribe and get access to applications that they pay for on a per use basis."

The biggest threat then, is to traditional software vendors, and applications like Sharepoint.  We will see heated debates on this very topic in the days and weeks ahead.

BMC Software's announcement that it has entered into a definitive agreement to acquire privately-held Tideway Systems Limited (Tideway), a provider of IT discovery solutions, can be interpreted as an extension of BMC's commitment to cloud-computing.

Here are two important statements in the press-release:

1. BMC will deliver unmatched visibility into the data center and rapidly reduce the time and resources required to model, manage and maintain applications and services. This is critical for IT organizations that are transitioning applications and services to cloud computing environments.

2. With the acquisition of Tideway, BMC adds the industry's leading application discovery and dependency mapping capabilities to manage and maintain complex data center environments including distributed, virtual and mainframe IT platforms and further extends its leadership in business service management.

So let's see what this could mean. 

It gives BMC the critical capability to discover and map complex data environments which are both physical and cloud-based.

This acquisition also puts BMC in a strong position to build a cloud-based CMDB.  While that might not happen right away, it is clearly now a key capability if they decide to pursue it. It also allows them to build a federated CMDB - and manage the hybrid cloud - private and public - across enterprise and hosted data centers. 

The evolution towards cloud-based ITIL continues.

We've discussed ITIL and Cloud Computing and the role of trust as a differentiator for service providers. Yes, we see the evidence that IT Hosting companies and managed service providers are closer to their customers and we see that their differentiation is their commitment to serving the customer.

But Amazon, Google, and Microsoft aren't going away. As they pressure customers to make the switch to the cloud, traditional service providers must find new ways to compete. Step one, of course, is providing alternatives - cloud services, like storage for example.  Step two is to highlight their customer commitment - the relationships they already have and defend this "advantage" by becoming even more responsive. 

So how do you build trust? According to Stephen Covey Jr. trust is built through behavior. His work has identified 13 behaviors which build trust:

1. Talk Straight
2. Demonstrate Respect
3. Create Transparency
4. Right Wrongs
5. Show Loyalty
6. Deliver Results
7. Get Better
8. Confront Reality
9. Clarify Expectations
10. Practice Accountability
11. Listen First
12. Keep Commitments
13. Extend Trust

But how do these behaviors translate to a cloud service delivery model? 

To answer this question, I dug up an old model for assessing service quality - SERVQUAL -  which was introduced to the world of service and retail back in 1988 (those were the days before ITIL).  SERVQUAL has its share of detractors, but even recent research reminds us that it is still a useful model.  In particular, I'm interested in how it can be used to help service providers improve and extend their intangible advantages over the more impersonal big shops.

Over the years, the SERVQUAL instrument has been a popular methodology used to measure consumers' perceptions of service quality. Its five generic dimensions or factors are still valid:

(1) Tangibles: physical facilities, equipment and appearance of personnel.
(2) Reliability: the ability to perform the promised service dependably and accurately.
(3) Responsiveness: willingness to help customers and provide prompt service.
(4) Assurance: includes competence, courtesy, credibility and security; the knowledge and courtesy of employees and their ability to inspire trust and confidence.
(5) Empathy: includes access, communication, understanding the customer; caring and
individualized attention that the firm provides to its customers.

None of these dimensions will change in the cloud, with the exception that some of these dimensions are now virtual and must be proven online (customer support, for example) or through superior automation of work processes.

Let's also analyze the SERVQUAL "gap model," as it was called, and see how it applies to service delivery in the cloud:

Let's look at the meaning of each "gap" - the possible breakdown areas in service delivery:

Gap 1: Customers' expectations versus management perceptions: caused by the lack of a marketing research orientation, inadequate upward communication and too many layers of management.

Gap 2: Management perceptions versus service specifications: caused by an inadequate commitment to service quality, a perception of unfeasibility, inadequate task standardization and an absence of goal setting.

Gap 3: Service specifications versus service delivery: caused by role ambiguity and conflict, poor employee-job fit and poor technology-job fit, inappropriate supervisory control systems, lack of perceived control and lack of teamwork.

Gap 4: Service delivery versus external communication: caused by inadequate horizontal communications and propensity to over-promise.

Gap 5: The discrepancy between customer expectations and their perceptions of the service delivered: caused by the influences exerted from the customer side and the shortfalls (gaps) on the part of the service provider. In this case, customer expectations are influenced by the extent of personal needs, word of mouth recommendation and past service experiences.

Gap 6: The discrepancy between customer expectations and employees' perceptions: caused by the differences in the understanding of customer expectations by front-line service providers.

Gap 7: The discrepancy between employee's perceptions and management perceptions: caused by the differences in the understanding of customer expectations between managers and service providers.

Three of these gaps are directly connected external customers: Gap 1, Gap 5 and Gap 6.  Service providers will find their optimal "trust-building" opportunities here.  Apply Covey's 13 behaviors to each one of these gaps to build on your commitment to your customers.

Amazon, Google, and Microsoft aren't building a high-touch responsive model for their cloud services. But you, the service-provider, already have a high-touch relationship. Your cloud-based SLAs must reflect this advantage. The security issue is just a small part of this reality.

Service providers who dedicate themselves to closing the gaps will succeed in this new world.

The quest for quality service didn't start yesterday. I highly recommend that service providers give Delivering quality service: balancing customer perceptions and expectations by Valarie A. Zeithaml, A. Parasuraman, Leonard L. Berry, a second look.

Most of us in the Cloud Storage industry strongly believe that a key capability of a storage cloud is the REST style Web Services API.  Many of the most popular storage cloud services include or exclusively use REST, including SoftLayer's CloudLayer, Amazon S3, Nirvanix SDN and Rackspace Cloud Files.

Other access methods that are most often associated with Cloud Storage access include cifs, NFS and WebDAV,  NFS and cifs are not particularly usable via an Internet connection and therefore useless in public cloud offerings.  While WebDAV is very useful for an Internet connection, it is similarly limited, in that all three protocols support traditional file operations like store and retrieve, versus the robust set of services that Web Services APIs can deliver.

Amazon introduced S3 with REST style API access only.  Cloud Files from Rackspace also utilizes REST style APIs. Nirvanix SDN utilizes both REST and SOAP APIs.  Mezeo offers REST APIs.   Various groups are also engaging on the issue of what representations of REST should be common across cloud offerings.  The SNIA, (the Storage Networking Industry Association) has assembled a technical Cloud Storage working group for further refinement of REST style implementations for several purposes.

So, what is the purpose of the other, older access protocols?  When deployed with API based Cloud Storage offerings, they provide additional options for legacy applications to expose their objects (files) to the advanced services of the Cloud, and further make these files available to the new API based applications.

Why all the excitement about RESTful APIs?  Cloud Storage is more than a utility business model applied to traditional storage. It is storage that is accessed via Web Services APIs, over a network. Developers utilize these APIs because they are easy to use and they expose significant capabilities and services from the storage cloud, far beyond scalability, performance and pay for use.  As I have said before, scalability and pay for use are as much a business decision about how you sell storage, as they are a technology implementation of storage.  If there were no need for the API based services, the older and well used protocols would persevere.  This is clearly not the case.

I have carefully avoided the use of the word "standard" associated with the REST  style or architecture.  Here is an interesting view on that topic from Roger Costello:

REST is not a standard. You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer's toolkit. Why? Because REST is just an architectural style. You can't bottle up that style. You can only understand it, and design your Web services in that style. (Analogous to the client-server architectural style. There is no client-server standard.)

Cloud storage service providers understand that a new storage infrastructure has emerged, as an embodiment of Service Oriented Architecture, with a set of services that are delivered via APIs.  Scalability, performance and pay for use are attributes of traditional and cloud storage solutions, but Web services APIs are the distinguishing feature of cloud storage.  Accessing storage via Web services APIs represents a revolutionary change in storage, not a simple generational change. REST APIs are the embodiment of the way the Web works and are necessary to expose storage as a "storage cloud"!

What should you expect in relation to these API issues?

Most of us expect that over time, there will be a base set of specifications that are jointly developed within the marketplace and by various industry organization, resulting in a well accepted set of representations for REST style Web Services APIs.  At a panel at Hosting Con earlier this week, both Emil Seyegh of Rackspace and myself confirmed that when the industry gets further clarity on this specification, it will be relatively easy to introduce those APIs into our offerings, and that they can co exist with our current APIs.

REST is a topic that you will continue hearing more about.  You'll most certainly hear more about it from me in future posts.