Anyhow, the so.cl interface is reminiscent of Google+ (especially party invitations, that seem to be like Google+ Hangouts) and that got me thinking back over some Twitter conversations relating to G+ over the last few weeks.  Those of you who use G+ on the iPhone will have noticed that absolutely awful recent upgrade, which somehow attempts to merge G+ information with the images people are posting.  The result is a totally unusable interface.  I have decided not to use G+ on the iPhone until a new release comes out.  Whilst I’ve thought G+ could ultimately succeed Twitter and Facebook, I’ve had two reservations.  The first has been the availability of the G+ API (more on that in a moment), the second is the ability to address mobile.  Everyone uses social media on the move, whether that’s catching up with updates or posting pictures, so mobile is a hugely important platform.  This has already been recognised as one of Facebook’s weak points in terms of monetisation, so this area was perfect for G+ to pounce on.  However they have singularly missed the point and seem to be incapable of delivering to this platform.  Perhaps the problem is two-fold.  Google believe everything should be done through the browser.  Probably the only applications that don’t fit that mould are Google Earth and Google Drive because they need direct graphics access and local filesystem access respectively, two things which the browser isn’t able to deliver.  Currently, G+ is browser-only with few parts of the API currently released, the key missing piece being the API for Circles.  I’m not sure why Google are holding back on this release but by stalling they are restricting the ability for programmers to develop mobile-based G+ applications.  Without this (and of course decent desktop solutions), then G+ will be an also-ran.

The Storage Architect Take

We are starting to see social network sprawl.  Flipping between multiple applications and/or browsers doesn’t work as users have inertia to change.  Google need to release the full API now, or the platform will die.  As for Microsoft, well as usual they are just too late and might as well not bother.

The Legacy View

Legacy Provisioning Proces

For the last 10 years or so, the traditional view of  storage management has consisted of a number of Storage Administrators using a GUI, CLIs and/or scripts to process storage requests as they are generated by the business user.  The process is highly manual, with lots of interactions between the requestor, the storage admin delivering the work and other intermediaries to cover things like billing, change control, capacity management and workload scheduling.  This made the overall process pretty people intensive and not surprisingly elongated the delivery time.  Many end users will also have recollections of asking for their specific requirement to be told they can only have something “off the shelf” – i.e. storage to a standard LUN size and with a specific RAID protection.  This was done for obvious reasons; firstly the configuration of large arrays was predicated on pre-planning and a fixed design, usually created at hardware installation time.  Once defined and in use, it couldn’t be changed (or at least couldn’t be changed without significant impact and cost).  Second, it makes sense to reduce requirements into a smaller subset to make the provisioning process easier.  As well as being rigid in configuration, many legacy arrays assume the creation and provisioning of LUNs is an infrequent task.  Many require requests to be packaged and executed in batch and certainly can’t cope easily with concurrent requests.  Although it is possible to automate some provisioning processes using CLIs and scripts, this doesn’t address the real requirements in creating an on-demand model.

The New World

API Provisioning Process

As we scale up to ever large IT deployments and especially within service-based or “cloud” configurations, the idea of having large amounts of human intervention in the provisioning process simply doesn’t work.  Instead, we need to move to a model of “storage on demand” where an external agent – user or orchestration software – can request storage as part of a portal and see the request actioned in real-time or at least within a matter of minutes or hours.  This kind of operation can only be delivered where the hardware has been designed for the purpose.  Where previously storage administrators were involved in every provisioning request, those requests will be actioned within a provisioning framework, defined by the administrator or a storage architect.

Framework

What do we mean by framework?  Well, it’s all about setting a set of parameters around which allocations take place.  This could include:

• LUN Size
• Resiliency/Availability
• Performance
• Security credentials
• Snapshot policy
• Capacity on demand LUN

Designed for API

Of course there’s a big question around whether APIs can be retro-fitted to existing storage.  In classic IT tradition the answer is “it depends”.  Without a doubt no new storage array should be released without native API functionality.  However fitting an API to existing technology will depend on how flexible the existing configuration process is.  It’s possible to create an API wrapper and build automation into a middleware layer.  This is how products such as iWave’s Storage Automator work.  However adding these features to existing storage products could be costly and still be an imperfect solution.

The Storage Architect Take

As new storage platforms evolve, native API support is a must.  The Storage Administrator will simply be required to deploy the infrastructure and plug it into a higher framework from where provisioning will be entirely automated.  Vendors offering this level of functionality will be the most attractive to service providers, looking to make the cost of acquiring and managing storage as cheap as possible.  We’re about to see a paradigm shift in the way in which storage is managed and possibly an end to the storage administrator.

Available Now as Public Beta

• Compute – on-demand server instances.
• Cloud Object Storage – object-based storage using RESTful APIs.
• Content Delivery Network – local distribution of web content.

Still in Private Beta

As Chris Mellor recently reported, Fusion-IO have been increasing revenue but making a loss and Eric Savitz also noted that 55% of their revenue comes from just two companies – Apple and Facebook.  From what I understand there are also other storage companies that also contributed heavily to Fusion-IO’s revenue numbers.

Remember STEC?  They rode high on the back of the SSD boom until their major supplier, EMC, decided they had a stockpile and didn’t need to keep on buying.  Fusion-IO revenue for Q4 is anticpated to be flat.  Does that mean Apple and Facebook and slowing their purchases?

The Storage Architect Take

During a limo journey with Howard Marks and Stephen Foskett at SFD#1, the subject of Fusion-IO was raised; the consensus was Fusion-IO will live or die depending whether application developers decide to write to their SDK.  I happen to agree with this sentiment.  Application integration is the secret sauce that makes server side flash (SSF) disruptive, BUT there needs to be more.  We also need the ability to deliver cache consistency outside and therefore between servers.  Dell’s acquisition would make perfect sense as it would enable SSF to be placed in the server or shared and expanded between servers with something like Infiniband; a process that needs to be driven by the server vendors themselves as part of their architecture.

Fusion-IO need the SDK to work but they also need server inter-connect for scale and availability.  At $33/share and with increased competition, Dell’s offer may end up looking a pretty good one.

Cloud Storage

The concept of Cloud Storage is pretty simple.  Services like Dropbox allow you to share a local folder on your PC or Mac and have that data replicated into “the cloud”.  From there it can be accessed by other devices, including smartphones, web browsers and tablets.  The great benefit of cloud storage offerings is that they allow all copies of data to be kept in sync, while retaining a backup copy that can be used if any or all of the local device copies are lost or corrupted.

My Data?

You’d think that because you were uploading your files, that you own them.  Whilst that’s true, what you can’t tell is whether your data is being used by your cloud provider for something else.  As I highlighted when Google’s service was announced, their terms and conditions state the following:

Some of our Services allow you to submit content. You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours.

Great, but read on and the Terms of Service also say:

When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide licence to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes that we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content.

This amount of freedom with my data seems a little generous;  effectively Google (or any company they choose) can redistribute my content, including modifying it, for their purposes.  Now it could be argued that Google are providing this service for free and somehow they need to recover their costs, but as others have done, when you offer a “free” service you rather hope to upsell the customer to a paid offering, either by giving enhanced features or capacity and cover the cost of offering the service to some for free.

Encrypt

So far I’ve chosen not to write any content into the Google Drive while I work out the best way to encrypt my data and still have it accessible across all platforms.  Ultimately if you’re not happy with what Google are doing, then encryption is the way forward.  The trouble with encryption though, is it restricts the use of plugin apps (like Google Docs) and reduces the effectiveness of sharing, when keys have to be shared around those accessing the shared data.

Shared Metadata Local Content

There is another way this problem could be solved and that’s to develop a hybrid solution.  Content can be separated from the metadata and access method, allowing users to retain data on their equipment, using a provider to store metadata and provide the shared access API.  This is what OxygenCloud now offer and VMware will offer with Project Octopus.  These kinds of solutions allow customers to retain control over their data whilst having the benefit of Dropbox-like functionality and eventually (as these service providers hope) to store only their critical information locally, pushing more into the Cloud (and their partner service providers) as they trust security and service levels.

The Storage Architect Take

Google will do well with Drive simply because they have a critical mass of users who like “free” and don’t care about the security and data access issues.  Pushing Drive into corporate territory will require a different approach; charging a fee and offering encryption and/or better terms of service may be one way forward.  However, in the meantime, there are plenty of others out there already eating Google’s lunch.  The hybrid on/offsite model will develop and mature.  The hybrid solution is something I can’t see Google engaging in; they like to own everything, so perhaps Drive will not be as successful as Google would like it to be after all.

• Violin Podcast
• Speaking in Tech #5