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.
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.
No comments:
Post a Comment