This Is Not The Cloud Computing We Should Have

from the we've-got-it-all-wrong dept

Even though I was never a big Google Reader user, its death has got me thinking about online services quite a bit lately -- and really reminded me that we've done the cloud wrong. Rather than build true cloud computing, we've built a bunch of lockboxes.

The cloud was supposed to free us, not lock us in

"Cloud computing" went by a variety of other terms in the past before this marketing term stuck, but the key part of it was that it was supposed to free us of worrying about the location of our data. Rather than having to have things stored locally, the data could be anywhere, and we could access it via any machine or device. That sort of happened, and there definitely are benefits to data being stored in the cloud, rather than locally. But... what came with today's "cloud" was a totally different kind of lock: a lock to the service.

I can point many apps to data stored locally

I wrote something related to this a few years ago, concerning music in the cloud. If I have a bunch of MP3s stored locally, I can point any number of music apps at my music folder, and they can all play that music. As long as the data is not in a proprietary format, I can find the app that works best for me and the data is separate from the app. Even when you have proprietary formats like Microsoft's .doc, other apps can often make use of them as well -- so, for example, I can get by with Libre Office, and I don't lose access to all of my old Microsoft Word docs.

This is really useful, because it helps us avoid vendor lock-in in many cases. Even when, say, Microsoft or Apple dominates the market. It's still possible to come in and be compatible. The competition then focuses on building better services, rather than reinventing the data model. That's much more useful to consumers, because the innovation is focused on making their lives better, rather than reinventing the wheel.

Today's cloud brings us back to walled gardens

For the most part, today, however, "cloud" applications bundle the storage and the service as one, and the two are linked inseparably. You check your data into a new cloud service, but the application layer and the data are both held by the same company. Yes, you can often transfer data from one service to the other -- such as Google's "data liberation front" effort, which is fantastic (and goes beyond many other companies' efforts), but just the fact that data needs to be liberated suggests we're taking the wrong approach altogether. Rather than having to "export" all of your feeds from Google Reader and then waiting patiently for 50,000 other people who are trying to upload them to the few small Reader competitors out there, why shouldn't we have each had an OPML file stored somewhere that we control, and that we could easily point any reader application, whether its local or "in the cloud." And, yes, there are some services that attempt to do this, but it's not where the whole "cloud" space has gone.

Separate and liberate the data from the infrastructure

What the cloud should be about is both freeing us from being locked to local data, and also freeing us from having that data locked to a particular service. I should be able to keep my data in one spot and then access it via a variety of cloud clients -- and the clients and the data shouldn't necessarily be directly connected or held by the same party. If I don't want to listen to my music via one app, I can just connect a different app to my personal data cloud and off we go. If Google Reader shuts down, no problem, just point a different app at my RSS data. No extraction, no uploading. Just go.

There are, of course, plenty of players around which sort of do this. DropBox, Box, Amazon's S3 and even Google Drive are setting themselves up as personal data clouds, and there are a growing number of apps that run across them. Projects like the Locker Project are thinking about how we store personal data separated from apps as well. And I know there are a bunch of other projects either around today or quickly approaching release, that also seek to do something in this space.

But, for the most part, all of the stories that people talk about concerning "cloud" computing almost always involve services that tie together the app and the data and all you're really doing is trading the former limitations of local data for the limitations of a single service provider controlling your data. Many service providers want this, of course. It's a form of lock-in. Plus, having some sort of access to your data and your usage can enable them to do other things, such as more accurately data mine you and your usage.

But, as users, we really should be pushing more towards embracing the apps that separate the app from the data and that let you point their "cloud" app at any particular place you store your "cloud" data. Some of this may involve standardizing certain data formats, but that makes sense anyway, as, once again, that's an area where there are tremendous benefits to not reinventing the wheel, so that the innovation and competition can focus on the service level. While some vendors may fear losing lock-in, if they truly believe in their own ability to provide great services, it shouldn't be a problem. At the same time, they should also realize that embracing this kind of world means that it's easier for others to jump in and test their services as well.

The death of Google Reader raised a lot of issues around trust, and while you could "export" the data, that process is still messy and archaic when you think about it. The future of cloud computing should be much more focused on separating the data from the service. That would remove the fear that many are now talking about concerning adopting new cloud services that might not last very long. If the data is stored elsewhere, and entirely in the control of the user, then you don't need to trust the service provider nearly as much, but can dip in and test out different apps operating on the same data, and switch with ease.

If we're going to see the real promise of "the cloud" take place, that's where things need to head. We should be increasingly skeptical of "cloud" apps that also control the data.

Filed Under: cloud computing, data, innovation, openness, services, storage


Reader Comments

Subscribe: RSS

View by: Time | Thread


  1. icon
    JackOfShadows (profile), 30 Mar 2013 @ 12:12am

    These are not the Cloudservices you are looking for. ... Move along.

    What we have is a Jedi Mind Trick happening with the media, analysts, and CIOs seem to be well fitted for the role of the weak-willed Storm Troopers. We are still stuck at the same place we were at back before the Dotcom Meltdown amongst various Service Providers, each with their own interfaces generally unable to share with anybody else. We have, now, various X-as-a-Service providers with services supposedly using a SOA (Service Oriented Architecture) built on Standards-compliant goodness. Unfortunately, paraphrasing Linus'es dictum still applies: "I love standards. Standards are wonderful! There are so many to choose from!"

    We are still stuck with the old model; almost completely unable to translate between clouds and apps, due to everyone wanting their own sandbox and further wanting to take ALL of Everyone's marbles home at the end of the day. Yes, there are ESB (Enterprise Service Bus) connectors and/or Managed Service Providers who can connect one "cloud" to another, but each one is pretty much a one-shot interface that will almost certainly end up being on the receiving end of a Microsoft or Twitter interface (Service) change with the next update/upgrade. You might just want to take your marbles home (private cloud) or, gods above and demons below forfend, to another provider.

    There are numerous proposed, even a few implemented solutions, however they are rare enough that only a really forward-looking engineering team and/or CIO will bother about portability and inter-communications when considering requirements. I have been thinking about this problem for a couple of decades. Really. I saw this train-wreck coming a long way off, before the web breathed its first, and like most problems it's pretty simple. Unfortunately, to borrow from L. E. Modessitt, "simple problems are hard." Really, really hard.

    What it will take to change this? As with info-sec, a major catastrophe of some sort such as the collapse of first-tier service provider. We didn't learn from the last war (Dotcom) so we'll have to have a repeated do-overs until we get it right.

Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here



Subscribe to the Techdirt Daily newsletter




Comment Options:

  • Use markdown. Use plain text.
  • Remember name/email/url (set a cookie)

Follow Techdirt
Insider Shop - Show Your Support!

Advertisement
Report this ad  |  Hide Techdirt ads
Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Chat
Advertisement
Report this ad  |  Hide Techdirt ads
Recent Stories
Advertisement
Report this ad  |  Hide Techdirt ads

Close

Email This

This feature is only available to registered users. Register or sign in to use it.