Recently in Cloud Maturity Model Category

On July 19, 2010, Rackspace led the announcement of OpenStack, with a goal of creating an open source cloud software solution for use on industry-standard hardware.  The initial releases contemplate solutions for both cloud compute and object storage.  While these are the first two releases, they are separate offerings.  Remember, cloud storage is not just the storage target for cloud computing, it is one potential storage target for cloud computing, and is in and of itself a stand alone cloud offering of programmable storage.

Now, I have purposely used a term from the clothing industry, "off the rack", to spend a moment looking at a framework for evaluating the opportunities this may present.  With dress shirts, you can buy off the rack, semi custom, or custom, each with a unique value proposition based on fit, choice and cost.   Interestingly enough, this may be a good lens through which to consider the possibilities of OpenStack, and in particular, OpenStack Object Storage.

Rackspace has made no secret of its motivations for leading this initiative, and its desire to focus on "fanatical" service as it's key differentiator versus the fundamental technology on which the service is based.  Fair enough, and so the question becomes, is the rapidly emerging and immature cloud marketplace already "mature" enough to seek homeostasis?  (Homeostasis is the property of a system, either open or closed, that regulates its internal environment and tends to maintain a stable, constant condition.)  Have enough models and innovations, from startups, academia, open source movements and large tech companies, been tested in the marketplace to the extent that we can already race to the common denominator?  Perhaps now is a good time to start, as long as you are willing to acknowledge that the desired results are a good ways off.

Before we jump off into "Off the Rack" software, a quick look back at open source is helpful.  For more reading on the open source software industry a good introduction is The Cathedral and the Bazaar. Six things are particularly interesting: 

1. An open source alternative can emerge as a follow on to a successful commercial technology and can become pervasive versus the commercial offerings it succeeded (LINUX versus UNIX is the reference case here).
   
2. A second result of this approach can also end up with a big success, although in more of a niche than a pervasive replace for the earlier commercial offerings (MySQL versus Oracle, IBM and Microsoft in the relational data base space).  
   
3. An open source effort can also emerge earlier in a technology cycle and come of age as a pervasive solution (Apache Web Server comes to mind here).
   
4. Open source generally requires very careful cultivation of the community of developers, with active interest by academia (and partnering with NASA is part of the formula here).  Commercially sponsored open source efforts are becoming more common, although it as of yet has not been proven as the typical "breeding ground" for most great open source successes.  Eucalyptus, with its roots at University of California Santa Barbara, seems to be a more traditional route.
   
5. Open source is not necessarily reflective of rapid commercial opportunities for success.  Eucalyptus is obviously beginning to maneuver towards a repeat of the commercialization model.  OpenStack is taking the approach most favored by other open source successes like Apache.  A couple of good reads here are this article from BusinessWeek and this. See also Derrick Harris' post over at GigaOm.
   
6. There are also hundreds of thousands of open source projects that had mixed success or languished altogether. A quick look at  SourceForge (an open source project hosting site) shows nearly a quarter million hosted projects. How many of these have languished or had little impact on the market.
   

So, the first issue is that there will exist for some time to come a real question as to the adoption potential of OpenStack.   I believe that adoption is driven by applicability to need.  In a moment we will address a serious issue which OpenStack Object Storage must overcome to be successful, at best, and at worst, will confine it to a niche market.  My views are very much directed at the Object Storage offering, versus the compute offering, which I believe exists in a different space and as a different type of solution.  With this backdrop, let's have a look at the cloud storage marketplace today, and use the analogy of off the rack, semi custom and custom:

• Off the Rack:  implement as is, one size fits all, each with unique approaches for performance, scalability, bit integrity, may or may not provide geo services.
• Semi Custom:  Select from storage types (DAS, SAN, NAS, JBOD), shared or distributed file systems and object systems, mix and match storage for different SLA and cost/usage patterns on the same infrastructure, multiple APIs, meta data and catalog abstracted from storage layer, geo services.
• Custom:  Generally a service only offering and not available as deployable infrastructure, specifics will vary widely based on service provider offering strategy.
  

Infrastructure	Type	Comments
Eucalyptus	Off the Rack	Limited S3 APIs
OpenStack	Off the Rack	CloudFiles APIs
Scality	Off the Rack	S3 APIs
Mezeo	Semi Custom	Mezeo ReST APIs and S3 APIs
NetApp	Off the Rack	Bycast APIs, NetApp storage
EMC Atmos	Off the Rack	Atmos ReST APIs, EMC storage
Service	Type	Comments
Amazon S3	Custom	S3 APIs
Microsoft Azure	Custom	Windows centric
Rackspace	Off the Rack	Is the basis for OpenStack
Nirvanix	Custom	SOAP APIs, multi node
Google	Custom	Offers S3 APIs
AT&T Synaptic	Off the Rack	Based on EMC Atmos
OpSource, SoftLayer, Layered Tech and others	Custom	Based on Mezeo

As you can see from the summary above, there exist as many views of what constitutes either a cloud storage service or a desirable cloud storage deployable infrastructure as there are service providers and vendors.  Note that a semi custom infrastructure results in a "custom" service as implemented.  "Off the rack" results in very similar services by those who utilize the same infrastructure unless they make their own major additions.  Any offering can be differentiated by service, and the degree and quality of service is critical to customer satisfaction and plays a strong role in value creation.

The OpenStack announcement as it regards Object Store and its approach to cloud storage seems to view cloud storage infrastructure as highly akin to an operating system (or at least a "hypervisor") and more similar to a selection of LINUX or Windows than that of an application or middleware layer.  While I agree that cloud compute is very close to this model, cloud storage is a service oriented architecture, with programmability for new applications that can tolerate Internet latency because of Web Services (like ReST APIs). The industry constantly overlooks this key point as it is consumed with the low cost, pay for use and thin provisioning capabilities of this storage tier.  Solutions for thin provisioning and low cost have been available far longer than cloud storage. Further, pay for use is more of a business decision than a technology. 

In the earliest days of cloud storage, there existed initial confusion that cloud storage was defined by cost, scalability, pay for use, and thin provisioning only and not programmable access (usually via ReST APIs).  ParaScale paid a huge price for not understanding that cloud storage requires Web services (like ReST API) access.  Now, with OpenStack Object Store, we see a follow on case of this same perspective, but with basic APIs for Put, Get and List.   Yes, it provides for Internet access via ReST APIs, but the focus continues to be primarily cost based versus new application enablement based.  It could be argued that the open source approach will provide for the appropriate additions of "advanced services" to be added.  However, even the use of the platform by NASA is more focused on cost of storage than on advanced functionality because NASA stores much more data than almost any institution or enterprise in the world.

I think Savio Rodrigues states this view very well in his post:

"Select products based on business needs, not license alone: It's also interesting to note that very few enterprises are in NASA's position with regards to size of IT investment and skills in-house. While NASA engineers were ready and willing to contribute new features into the Eucalyptus open source community, few companies have the skills or governance to consider allowing their developers to contribute to open source projects.  Summary trend number 7 from the 2010 Eclipse survey results highlighted this issue.

To suggest that NASA's buying or IT decision making patterns represents much more than the top 1 percent of IT buyers would be a stretch."

The overwhelming majority of enterprises would rather pay a vendor to deliver, maintain, support and enhance their private cloud software infrastructure than place that burden on internal IT staff. Whether the enterprise is paying for a closed source commercial product, a commercial product based on an open core product, or a subscription to an open source product, the product selection decision will be made based on business requirements much broader than 'is the product open source or not?' "

Keep in mind that cloud storage is a stand alone service associated with application delivery over the Internet and also associated with low cost, pay for use, scalable storage resources.  Social media applications and many Web based applications exploit these capabilities; for example publishing a file to a URL and significant tagging of files.

This view of cloud storage as nothing more than cost and volume-based ignores its extraordinary importance as a service-oriented architecture for new application enablement.  I believe both views are equally important and need to be equally served.  Will OpenStack, with its pervasive cost focus, be able to drive its community to this additional view of needed contributions of advanced services for cloud storage?  Lydia Leong of Gartner Group provides an interesting view of the open source community issues associated with this in her post:

"At the same time, open sourcing is not necessarily a way to software success. Rackspace has a whole host of new challenges that it will have to meet. First, it must ensure that the roadmap of the new project aligns sufficiently with its own needs, since it has decided that it will use the project's public codebase for its own service. Second, it now has to manage and just as importantly, lead, an open-source community, getting useful commits from outside contributors and managing the commit process. (Rackspace and NASA have formed a board for governance of the project, on which they have multiple seats but are in the minority.) Third, as with all such things, there are potential code-quality issues, the impact of which become significantly magnified when running operations at massive scale."

One last comment on this business of vendor lock in and cloud storage APIs (another focus of the OpenStack announcement).  I would submit that while a specific set of APIs has the potential to create vendor lock in, this is a much smaller problem than what is experienced in other technologies.  If you are really worried about it, you probably have never actually written a ReST API call.  It is written in many languages, and we have seen cases where applications that run on S3 run unchanged on Mezeo.  Others need very minor modifications, and still others are excited to take advantage of some of the unique Mezeo services.  It just is not a problem, and this is much more related to FUD (fear, uncertainty and doubt) and marketing zealotry than it is associated with technological reality.  The APIs of choice will shake out, and it is far to early to say if it will be S3, OpenStack, CDMI or a combination of all of these, and others, as yet unforeseen.  (At Mezeo, we have never believed there will be one winner, and instead focused on architecture to enable easy and effective delivery of whichever APIs stand the test of time.)

The interesting view that seems to be missing here is that marketplace competition by service providers already serves to drive down the price of cloud storage, so a commoditized stack embraced by most is unlikely to yield extraordinary incremental savings.  At the same time, while the competitive market conspires to drive cloud storage costs ever lower, the need to differentiate, and deliver solutions as well as a programmable storage to enable multiple new and exciting types of applications will rapidly replace the pure cost and scale focus of current cloud storage offerings.  Sometimes, the "new" application is simply enabling it in the cloud, to produce the same result at a lower cost!  This requires significant cloud storage functionality in order to make this easy and productive.  Amazon continues to prove this with their many additions and capabilities which differentiate their service.  Mezeo sees much the same view on the part of our customers.  The focus is on what cloud storage can do, what problems will it solve, what business opportunities does it create, what new applications can it enable and all of these views assume it will be competitively priced.

Cloud storage represents significant opportunities for institutions, the enterprise (see my recent post on the business case for enterprise cloud storage) and for the IT service provider.  Cloud storage is substantially different from cloud compute, and requires that you understand this difference in order to effectively evaluate the impact of this announcement, as well as your next steps.

There is no doubt that every enterprise has devoted some time and energy to evaluating how cloud technologies can best be put to work in their ongoing pursuit of cost reduction and to a lesser extent for potential improved service levels particularly around rapid provisioning of compute and storage resources.  Mezeo has recently begun to work with various enterprises, and I want to share some of the opportunities that appear to align strongly with these two goals.

In terms of cost, most enterprises are experiencing continued and significant growth in unstructured data.  As they look at the cost of this growth, it is more than just physical storage, data center occupancy, bandwidth utilization and power and the accompanying management demands; it is also the backup and disaster recovery requirements and the ability to quickly satisfy users who need more storage in order to execute whatever tasks and jobs they have.  Against this backdrop, the drumbeat of Amazon S3 and other public storage clouds advertises storage at costs that are generally below the internal "advertised" cost of the typical Fortune 500 company.  What gives?

First, cents/GB/month is only the tip of the iceberg, and bandwidth along with access charges gives a more realistic cost appraisal.  Next, real and legitimate concerns about data security exist (will someone gain unauthorized access, by accident or via an attack, to company data stored in a multi-tenant public storage cloud?).  Also, data integrity concerns are well founded (will the bits I store be returned, and will they be backed up and appropriate DR measures taken?).  Finally, can I absolutely trust the service provider to execute to the extent deemed necessary, and if they do, can they really save me any real money versus the assumed risk profile?  Private cloud computing is an appropriate strategy for addressing these issues.  

Not all unstructured data is a candidate for the latency of cloud storage as delivered from an IT service provider via the Internet.  So, while some tiers of data may be appropriate for a cloud storage service, it is a subset of the enterprise unstructured data requirement and not a lower cost panacea.  Hopefully, CIOs can easily make this case with their peers in senior management, although it may sometimes seem like they are making an excuse for keeping control and not exploiting new technologies.

Question one surrounds the cost proposition, and our analysis suggests that, even at sub petabyte initial cloud sizes, the enterprise can deliver economics for in-house cloud storage that compare very favorably.  In fact, it may even be lower than what is available from a service provider.  The Mezeo team comes from both a hosting and a cloud storage background, and this just reinforces our view that the cost proposition for private cloud storage has favorable economics.  However, if you are being forced to allocate capital for data center build outs, or you are otherwise CAPEX constrained, the hosted public cloud economics can be quite appealing.  Since businesses require positive margins, this further drives up the cost of cloud storage as hosted at a public service provider.

The case for improved user satisfaction is similar, regardless of public versus private, because the cloud gives users the capabilities they want.  First, with rapid provisioning of pay-as-you-go low cost cloud storage, the end user gets what they need when they need it via a frictionless interface.   Second, several benefits drive end user demand for cloud storage; including: avoidance of workstation storage upgrades, one solution for file sharing and collaboration, new capabilities and applications that exploit file search, tagging and publishing to a public URL, and the ability to access your storage anytime, anywhere and on any device.  Third, the solution is also ideal for implementing a workstation backup solution with sync.  It is not hard to see why end users would find all of these capabilities appealing.

Cloud storage clients, gateways and edge devices are also beginning to appear, and can solve many different issues.  For example, a client gives the end user access to multiple cloud storage accounts at multiple providers.  Why not replace that tape backup operation at a remote location with an iSCSI interface directly to a storage cloud, for a scheduled backup without local user intervention (get rid of the tape backup of your local file server, forever)?  Speaking of file servers, multiple solutions for replacing or even displacing file servers are coming to the market.  The savings from removing an entire layer of infrastructure are quite compelling.

New applications, including use of social media, may require file publishing.  Cloud storage allows you to store training videos, and make them easily available at every end user in the company.  Tagging and search offers new application capabilities, and new opportunities to support existing compliance requirements.  Secure file sharing, versus file publishing, may be a significant requirement as you work with customers and business partners.  Partner, customer and employee portals can reach new levels of capability with API accessible cloud storage, as the availability and the management of information is delivered via the cloud.

Our observation is that the early adopters have begun the move to cloud storage.  Why?  Simply, enterprise private cloud storage allows you to gain many of the benefits and set aside the security and data integrity concerns of public cloud storage.  At the same time, data tiering and private and public could solutions will drive "hybrid" cloud approaches that will allow the enterprise to exploit the best of both worlds.  In an upcoming post, we will offer up some tools to examine the cost and the benefits of cloud storage for the enterprise. 

It is a little difficult to discuss an article like What's a Hybrid Cloud and Where Can I get One? without at least agreeing upon some sort of definition.  We've already heard many of these definitions, but I'm not sure they're good enough.  Note: we did try to define the term hybrid earlier, as part of our Cloud Storage Maturity Model.

Well, what is it? 

First, let's look at the textbook definition of the word hybrid:

A hybrid is the combination of two or more different things, aimed at achieving a particular objective or goal.

A "hybrid car" has both an electric motor and an internal combustion engine, and the combination of the two serves to propel your automobile while providing a more efficient use of fuel.  So, a hybrid cloud is a combination of a public and a private cloud, aimed at providing a common cloud computing experience.

But for what purpose?  Hybrid computing clouds provide cloud computing that delivers the appropriate offerings with provisioning, pay-as-you-go for relatively limitless capacity, and improved security, and some would say at a lower cost than an internal cloud. Hybrid clouds can and do offer the opportunity to provide baseline processing within your own facilities, and use service providers for peak requirements.  By doing this, they can lower the cost versus private cloud computing. 

I've seen some hybrid cloud definitions that include edge or gateway devices, but I do not think that is definitive for hybrid cloud.  Now, with this definition, we can sort out what a hybrid cloud actually delivers.  In general, the argument that a multi-tenant public cloud is lower cost (on an absolute cost basis) than a private cloud is hogwash, in my experience.  I have seen examples of all of these, and in the case of a large enterprise, they may very well run private clouds for their own use that cost less than what they can buy the resources for on an open market basis.  (Now, before the switchboards light up with capex versus opex and idle resource arguments, I want to assure you that even taking these issues into account, the theory holds water).  This still begs the question as to what purpose does hybrid cloud serve?

In its most general case, the business value of hybrid cloud lies in its ability to bridge the gap between baseline computing and peak computing, assuming all things are equal or if not equal, at least acceptable (in terms of security and other incremental costs associated with hybrid cloud).  Otherwise, why go to the trouble?

There are other examples that are associated with backup and disaster recovery versus cost that also can be of high value with a hybrid approach, particularly if you only have one data center.  I store my backup locally, in case I need to do a speedy recovery.  I store an encrypted copy remotely, at a service provider, for DR purposes.  Voila!  Low cost, secure, multiple requirements solved.  Hybrid, it's a beautiful thing.

The hybrid cloud can also allow you to "bridge the gap" if you are in a data center bind, i.e. out of space or between build-outs.  This is a special case of bridging the gap.

Where can you get this, now? 

This is exactly our game plan (at Mezeo), and working with backup and archive providers, as well as Mezeo-based cloud storage service providers, and Mezeo private storage clouds for the enterprise, we deliver this solution today - in a matter of days and weeks, not months!

Cloud storage is already showing signs of Phase Two (see our post on the cloud storage maturity model), as a new set of solutions arrive in the marketplace.  These solutions are referred to as cloud gateways, on ramps, cloud clients, edge devices and other exotic names. 

For ease of discussion, lets use "cloud client" to describe a solution that is on a single user device (workstation, PDA, Tablet) and "cloud gateway" or just "gateway" for a solution that is delivered on a server or router for many users.  Whether they are a client or a gateway, some store a "blob" of data, and some store "chunks" of data that are parts of the original object.  Others store the actual object.  What's the difference and is it important? Should you consider it in your cloud gateway use plans?

What is a blob?  A blob can start as either a single object or a collection of objects, for example, all of the files on a single server, or a VM image.  Then, you do something to it in the client/gateway device that requires it to be brought back through the original client/gateway to be returned to a useful state.  Examples include de-duplication and compression followed by encryption prior to transmission of the object to the cloud (I call this D/C/E).  The result is a "blob" of data, an object that is minimized in size, and must be retrieved by the application that created it in order to be useful again. 

A chunk is part of an object, and the original object must be re-assembled by the gateway that parsed it in the first place. Some gateways store blobs.  Some store the object in chunks.  Finally, some store the actual object with its original file type, intact.  These may be workstation clients, or interface solutions that allow for a CIFS or iSCSI (today, TwinStrata is an example of the iSCSI capability) attached device to store in the cloud.  There are trade-offs and advantages associated with each approach, and your cloud storage use case and objective must be carefully analyzed in order to determine the applicability of the gateway to your business requirement.

Now, let's consider D/C/E.  This provides savings in addition to the savings associated with cloud storage.  D and C gives you a small object size, so your bandwidth cost is lower, and your overall storage cost is lower.  When there is a change to the stored objects, chunks allow you to send only the changed part of the object, reducing bandwidth and potentially improving performance.  Encrypting, or chunking, or both, may improve security and relieve you of the costs and management associated with other security approaches.

So, blobs and chunks sound pretty good, providing better security and lower costs.  What's the catch?  First, storage clouds are great places to provide anytime and anywhere access to your data, from multiple devices.  If you have to go back to a gateway to get the original version of the object, that flexibility may be very limited or non-existent.  Clouds are also a great place for sharing and collaboration, which is not in play if the object in the cloud is not in a useful form.  Finally, vendors are not giving gateway solutions away - we must ask what they cost, and are they worth it?

As usual, the answer is, it depends.  What services can I get from the cloud? And what services can I get from the gateway?

An example that is getting a lot of attention is file server replacement, or even better, file server displacement.  I get less excited about replacing a file server with another server that is a policy driven cache, because I still have this layer of technology in place.  However, if you can displace most of your file servers, then the potential for significant cost savings become obvious.  

I tend to look at single user clients as very interesting on ramps to the cloud.  A client, using some modest amount of workstation storage as a cache, can deliver most of the benefits of a file server.  Companies like Gladinet, SMEStorage, GoodReader, Mezeo and others have very interesting cloud clients.  You will still need a few file servers if you need to provide a place for very large files.  Interestingly enough, those very large files are often rich media (like training videos), and streaming them to a reader on the client from the cloud is often good enough.  Another cloud client capability we expect to see will allow the end-user to store files and move them across multiple storage providers - from private to public and vice-versa, for example.  This functionality could also be in a server-based gateway.

Another cloud client capability might include giving encryption capability to the end user, and let them decide if they want to encrypt the file themselves.   Or, use a cloud that provides user selectable encryption.  Give your end users or customers the power of choice, the freedom of access anytime and anywhere, the ability to get the amount of storage they need when they need it (what Gartner calls "reservationless", and kudos for them, great term).  Don't tie users to a "home base" gateway that does not store their object in it's original format, or at least give them a choice.  All that being said, we are seeing that some mix of clients for file server displacement, and file server replacement gateways may ultimately be the appropriate solution.  

Backup and archive is a different story, and here a gateway can make a lot of sense.  First, there is quite a bit of local housekeeping associated with these solutions, and the solution can decide if utilizing the cloud for some or all of the files makes sense. Speed of restore is a major consideration for a backup, and may drive local versus cloud based storage solutions.  Further, the need for a disaster recovery site, or to archive, can often be a cloud use case.  Companies like Zmanda and CommVault are very active in cloud based backup solutions.  What if you have applications that do not speak REST APIs, like a legacy backup solution?  There are gateways that can attach these legacy applications to the cloud, for example, TwinStrata.

Special purpose gateways can also solve an immediate problem.  Blue Thread offers a cloud storage interface for SharePoint.  The marketplace is rapidly developing a portfolio of cloud storage gateways and clients, as well as backup and archive solutions and all have their own unique perspective on cloud use.  Examples include StorSimple, Cirtas, Gladinet (who also makes clients), and EntropySoft.  Venture capital companies are deploying significant capital for these sorts of solutions.  Each of these solution providers sees a clear path to adding significant value to cloud storage solution delivery.

Cloud storage requires significant use case consideration to evaluate the functionality required, both in the cloud and in the gateway or client, and where the application or user can best exploit the functionality.  After all, cloud storage is also about empowering the end user with the storage they need, when they need it, at a favorable price, and providing advanced functionality, like publishing and sharing.

At Mezeo, we have both a deployable cloud infrastructure, and clients.  That causes us to look at where the best place to put the functionality is.  That creates a slightly different perspective, and we think it creates very useful products.  On the other hand, nothing gets us more excited than the thought of more solutions that drive cloud storage adoption and usefulness.  For this reason, we are rolling out a new marketing and certification program, Mezeo Ready™. 

With Mezeo Ready™, service provider public storage clouds can easily identify their offering as being "Ready" for use by Mezeo Ready™ clients or gateways, and backup and archive solutions.  Users of these products can pick one of many trusted service providers hosting Mezeo Ready™ cloud storage solutions.  This cloud storage on ramp and cloud storage provider "ecosystem" ultimately delivers valuable solutions to customers and is a big part of Mezeo's vision for the cloud storage market.

So, more to come on Mezeo Ready™, we are nearing the official announcement of the program, and will extend it to storage providers and file system providers who work with Mezeo to deliver storage clouds, both private and public.  Other solutions, like billing and provisioning systems will also be in the Mezeo Ready™ program.  The changes the cloud is delivering are new and useful, and deliver real value to the institutions and businesses that are embracing them.  The ecosystem is critical to the value delivery chain, and key to providing unique, desirable solutions.

We see a lot of coverage about cloud storage these days - and why it is or is not being adopted. One way to look at cloud storage adoption is to view it as an evolutionary process which changes over time, as both the organization matures and becomes adept at leveraging the new technology, and as the technology itself evolves to meet the real needs of the end-user.  The common name for this sort of thinking is a "maturity model."

With that in mind we developed this simple maturity model for cloud storage, based on the actual cloud storage adoption process we're witnessing in the industry. We'd like to hear your thoughts - are you seeing the same trends?


PHASE ONE: Public Cloud Storage

Description
There remains significant marketplace confusion about what constitutes cloud storage.  Cloud storage is a persistent storage for unstructured data accessed via Web services APIs over a network (LAN or WAN), with the additional  characteristics of rapid provisioning of both new accounts of any size as well as rapid provisioning of increases (or decreases) in account size, along with a pay for use model, Some believe that cloud storage is just the provisioning and pay for use model with access method being varied between older technologies (CIFS/NFS) and http (Web services API access).  Public, multi-tenant storage clouds as delivered by service providers clearly meet our definition, as traditional access methods like CIFS/NFS are not useful over the Internet.

Many technologists and almost all non technologists, make the initial mistake that cloud storage is simply the storage used when using cloud computing.  In fact, a cloud computing image (CCI) may very well be provisioned and stored when not in use on traditional iscsi type storage systems, and is often dependent on very high speed access associated with a locally attached device.  Many times, the data needed for the application supported by the CCI is often stored on shared storage devices within the same data center as the CCI, for application performance reasons.  The data for these CCIs may also be block, or data base data.  This is storage for cloud computing, but it is not "Cloud Storage"!  This confusion permeates the marketplace in Phase One.  Many vendors, particularly traditional storage vendors, have confused the marketplace by claiming to be cloud storage based on "thin provisioning" attributes with traditional data center access versus HTTP access. Cloud storage may also be accessed and utilized by CCI based applications, but that is not a defining attribute of cloud storage.  Cloud storage is accessed by applications on both CCIs and dedicated servers, as well as clients on PDA's and PC's, wherever they are and whenever they need access.  The use cases are very tolerant of the latency associated with the Internet. The thin provisioning and pay for use model of cloud storage does deliver the important cloud storage attribute of transferring storage costs from a CAPEX to an OPEX basis, if you are acquiring your cloud storage form a service provider on a pay for use basis.

 The IT service provider space is the earliest adopter of cloud storage, for both offensive and defensive purposes.  Many service providers are hosting workloads on dedicated or virtual servers (CCIs), and the workloads are new applications that utilize cloud storage from companies like Amazon S3, Rackspace Cloud Files, Nirvanix, and SoftLayer CloudLayer. Since the amount of data can be very large, it is difficult to move without downtime. And since the processing is relatively easy to move, IT service providers recognize the need for their own cloud storage service in order to provide a complete offering to their customers and to promote retention.  Without the associated cloud storage, the application server workload can easily move, usually to the provider who provides the storage cloud.  This is the defensive argument for service providers to offer their own storage cloud.  On the offensive side, cloud storage is growing rapidly in terms of adoption, provides a new revenue stream, can attract new hosted workloads (cloud or otherwise), and drives increased (and very profitable) bandwidth use.

The web hosting industry also saw the initial development activities associated with adoption of Web services APIs, which provide many programming capabilities that are now resident in the storage, and easily enabled new applications that are delivered via the Web.  These services, including tagging, searching and filtering, sharing, publishing, and collaboration, all exist within the APIs of a storage cloud, and are easily implemented within the application.  While the enterprise has not yet adopted this new functionality, it has become quite pervasive within social networking apps, enabling new apps on mobile devices, file sharing services, and online file services, and backup and archive services.

Cloud storage is currently offered by only a few service providers including Amazon (S3); SoftLayer (CloudLayer); Rackspace (CloudFiles), Nirvanix, and is only available as a service.  Enterprise adoption is limited to development only, primarily testing, and enterprise adoption has not yet occurred, primarily because of security concerns.

Key attributes

Adoption Drivers:
Business drivers: low cost, rapid scalability and on-demand capacity
Technology enablers: New programming capabilities

Adopters:
- SMBs/ SMEs
- Developers
- Consumers

Use Cases:  
- Testing and application development
- SaaS (Consumer & SME/SMB users: Backup, file sharing, additional device storage, rich media)

Differentiators:  
- SLA variability
- Pricing elements

PHASE TWO: Public & Private Cloud Storage

Description: As large enterprises start to fully comprehend the benefits of cloud storage, their interest grows.  While security concerns keep them from adopting the public cloud, they begin building private clouds behind their firewall. A private cloud provides them with the level of control and security that they are comfortable with and improves the utilization rates of their existing storage infrastructure, because of thin provisioning and potential for technology reuse. Enterprises start to roll out advanced capabilities such as file sharing and collaboration to their employees and their partners. The initial use of storage cloud services allow the enterprise to begin initial development of storage cloud based applications.  They also start to move backup and archives into their  own clouds. Since these applications do not require the highest performing storage, enterprises are able to reuse decommissioned hardware. This effectively starts the process of "tiered storage." 

At the same time, the public cloud storage offerings continue to grow.  The availability of deployable solutions to create your own storage cloud begin to arrive in the market, enabling IT service providers to quickly implement storage clouds versus being faced with a roll your own development effort.  Public storage cloud service offerings become more pervasive and better accepted as security and awareness increases.

Key attributes (Private Cloud Storage)

Adoption Drivers:
Business drivers: low cost, rapid scalability, high security and control
Technology enablers: new programming capabilities, cloud gateways (such as Blue Thread, Entropy)

Adopters:
- Enterprises

Use Cases: 
- Application Development
- Testing
- Backup
- Archiving
- File Sharing and Collaboration

Key attributes (Public Cloud Storage)

Adoption Drivers:
Business drivers: Low cost, rapid scalability, on-demand capacity
Technology enablers: new programming capabilities, cloud gateways generating multi-cloud usage

Adopters:
- SMBs/SMEs
- Developers
- Consumers
- Enterprise Evaluators

Use Cases: 
- Testing and application development
- Backup
- SaaS (Consumer & SME/SMB users: Backup, file sharing, additional device storage, rich media)
- Personal cloud storage with access clients
- Backup and archiving using cloud gateway
- Special use cases enabled by cloud gateway
- File server replacement
- Availability of CIFS/NFS access within the data center

Differentiators: 
- SLA variability
- Pricing
- Scalability and performance
- Access options

PHASE THREE: Public, Private and Hybrid Cloud Storage

Description: The maturity of the cloud (both private and public) has enabled many new applications which now require all the advanced services of a storage cloud (Web services API access, tagging, search, sharing, collaboration, etc).  Capabilities such as Geo Access (accessing files from a repository closest to the requester) and Geo Replication (policy driven replication across geographies to facilitate disaster recovery) are realized.  As Internet latency is constantly improving, more and more applications become "cloudy" in terms of storage, and cloud location becomes slightly less important as associated with performance.  Cloud storage is now a requirement of developers and development platforms.  Most SaaS applications also expect the availability of cloud storage.  Everyone is storing everything!  Most importantly, the improved security in public storage cloud offerings begins to blur the distinction of importance of security as being where data is stored (in public or private clouds).  Instead, applications utilize both public and private clouds, for reasons associated with location of data, disaster recovery and backup, and CAPEX versus OPEX.   Only the most sensitive data still retains a private cloud requirement.  Performance is a more salient driver of where the data is stored, does it need to be on a LAN in the same data center as the application?

This use of both public and private clouds as solutions for storage, often by the same application, becomes what we refer to as the Hybrid Cloud.

Key attributes (Private Cloud Storage)

Adoption Drivers:
Business drivers: Low cost, high security and control, rapid scalability, compliance and forensics
Technology enablers: New programming capabilities, cloud gateways
 
Adopters:
- Enterprises

Use Cases:  
- Application development
- Backup
- Archiving
- File sharing and collaboration
- Geo access

Key attributes (Public Cloud Storage)

Adoption Drivers:
Business drivers: low cost, rapid scalability, on-demand capacity, clouds become more pervasive
Technology enablers: new programming capabilities, cloud gateways generating multi-cloud usage

Adopters:
- SMBs/ SMEs
- Developers
- Consumers
- Enterprise evaluators

Use Cases:  
- Testing and application development
- SaaS (Consumer & SME/SMB users: Backup, file sharing, additional device storage, rich media)
- Personal cloud storage with access clients
- Backup and archiving using cloud gateway
- Special use cases enabled by cloud gateway
- File server replacement
- Availability of CIFS/NFS access within the data center

Differentiators:
- SLA variability
- Pricing elements
- Scalability and performance
- Access options
- Multiple clouds vs. single cloud

Key attributes (Hybrid Cloud Storage - a mix of Public and Private Cloud Storage)

Adoption Drivers:
Business drivers: lowered average cost obtained via a mix of public/private cloud, reduction of DR/BC costs, optimized mix of capex and opex
Technology enablers: improved security

Adopters:
- Enterprises

Use Cases:  
-  Incorporates use cases for private and public clouds

Differentiators:
-  SLA variability
-  Pricing elements
-  Scalability and performance
-  Access options
-  Multiple cloud vs. single cloud

PHASE FOUR: Federated Cloud Storage

Description: With the advent of greater security, flexibility and interactivity, users will demand applications that provide real time dynamic interaction within their supply chain. Regardless of where their data may reside, partners, customers, employees and consumers will want a seamless, transparent access capability. Enter the Federated Cloud. Through a common management layer, Federated cloud will connect private and public clouds exposing all storage as a single name space. Through federated identity management and creation of trust relationships amongst various vendors and enterprises, authorized users (human or programmatic) will be able to authenticate to their cloud and be able to access information that resides anywhere across the globe. Excess capacity will be easily pushed over a grid and be sold and consumed as a true utility. Ultra-high utilization rates will be achieved, and within the trust circle security and compliance requirements will be defined and met. Interoperability will be ensured by continued maturity and standardization of APIs and applications.

This truly will culminate in a meaningful internet of knowledge and commerce.  The "Semantic Web" has arrived!  Note that, for matters of very high security, agencies and enterprises will continue to use private clouds.

Key attributes (Federated Cloud Storage)

Adoption Drivers:
Business drivers: need for real time dynamic interaction with partners/customers on different clouds, ability to sell excess capacity within the trust circle, optimized infrastructure utilization, establishment of trust relationships
Technology drivers: federated authentication and provisioning across clouds, streamlined cross-cloud management, standardized APIs  
'
Adopters:
- Service providers
- SMEs/SMBs
- Consumers
- Enterprises

Use Cases:  
- Supply chain management
- Ad-hoc capacity capacity enhancement
- Non-sensitive and sensitive data hosting

Differentiators:
- SLA variability
- Pricing elements
- Scalability and performance
- Access options
- Security
- Governance and regulation compliance

Based upon our experience in the marketplace, a large majority of the organizations are still in the first two phases. There is an undeniable appetite by the early adopters to be at the forefront, however, unlike many other emergent technologies, cloud storage comes equipped with a very compelling economic model and that is really helping justify the move into the cloud.

There are relatively few options for early adopters to implement private clouds that deliver the appropriate capabilities.  This is why Mezeo focused on a deployable platform versus only offering cloud storage as a service.  With the deployable platform, enterprises can implement their own in house cloud, and also take advantage of a "private" cloud hosted on their behalf at a service provider.  See my discussion of this topic in my post: Cloud Storage for the Enterprise - Part 2: The Hybrid Cloud

In summary, those of us who hail from the IT service provider industry are very comfortable with cloud storage.  We see the adoption as proceeding, and the issues are being knocked off as they arise.  We are in an early technology cycle but with innovative early adopters we see a bright future.

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. 

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.

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. 

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.

The concept of Service Oriented Architecture (SOA) has been around for a long time, and some people believe it has not fulfilled its promise.  To the contrary, SOA is well on its way to fulfilling its promise and the rise of cloud computing infrastructure is an important step in this process.  In fact, cloud computing is already beginning to unleash the potential of SOA and much more is on the way.

David Linthicum, Editor-in-Chief of Sys-Con's Virtualization Journal, has it mostly right.  He says:

Let's get this straight: SOA is an architectural pattern, simply put the ability to create an architecture around the notion of many services that are bound together to create and re-create business solutions. Cloud computing is a set of enabling technologies as a potential target platform or technological approach for that architecture...One is the way of doing something, while the other is a potential outcome. SOA doesn't go away. It's not replaced. It's architecture. Cloud computing is a potential outcome of that architecture, thus cloud computing needs architecture, and vice versa.

David's rant was an argument against complaints by certain industry pundits that cloud computing is just an over-hyped reincarnation of SOA. 

I agree with David as far as he goes, but he can take his point further. He is correct to call SOA an architectural pattern.  He is correct to call cloud computing a "target platform."  But the real news in this story is that a target platform is exactly what SOA has been lacking all these years.  All applications must run somewhere; applications need infrastructure. 

SOA is an application architecture; cloud computing is an infrastructure architecture.  It's that simple.  This marriage is long overdue.

SOA applications inherently call upon Web services to request resources, so to run properly SOA applications need infrastructure architecture that lends itself SOA.  Cloud processing (dynamic allocation of CPU resources) and cloud storage (Web services API access to storage resources) infrastructure is the most natural target platform for SOA apps because cloud infrastructure is designed to scale in the way implied by the SOA approach to application architecture. 

Until recently, where could a SOA app find a venue to stretch its legs?  There weren't many options until the earliest cloud computing service providers deployed large-scale cloud infrastructure.  The SOA world owes Amazon and Rackspace a big thanks for making the infrastructure investment required to launch S3, EC2, CloudSites, CloudFiles, and CloudServers.  As the rest of the Hosting market--and broader IT service provider industry--follows suit, SOA applications will flourish.

So David, you're right.  Not only do cloud computing and SOA "need each other," but together they will ultimately justify all the hype.