Let me tell you something nifty about the application I’m using to write this blog post (that is, Windows Live Writer). It doesn’t bother me with files, directories or file names. I only have to deal with constructs of the domain — blog posts, post title and which blog to post to. Once published, I don’t have to worry about anything sitting on my hard disk. I can use it on different blogging services. If I want, I can throw it away and switch to a different tool (like w.bloggar) and still be able to access posts written with Live Writer (although that’s due to standard API’s, not cleverness on the part of Live Writer). If I want, I can throw away the desktop editor altogether and directly use the blogging service’s web posting form. I can tweak the presentation of the blog in enough ways that the only thing that remains constant is the raw content I submitted. Importing my posts from one blogging service to another may be a bit difficult, but not impossible.
I only brought this up to illustrate a few points in relation to a rather popular bandwagon — Cloud Computing/Software as a service (SaaS) , which, once the buzzwords are peeled off, is basically storing and working on your data on the Internet rather than storing them as files on your computer and working on them using desktop applications. Bear with me if you get a faint whiff of Web Services déjà vu, as I’m about to argue in favor of splitting the Cloud neatly in two:
- Named data stores
- Data manipulation services
Although it’s not strictly accurate to do so, let us compare the above to Google Docs, a poster boy of cloud computing, if I’m not mistaken:
It’s a monolithic web application — the service and the data are coupled. If you want to pick up your data and go elsewhere, you’re largely out of luck (unless you’re ok with downloading all your documents as MS Word/PDF files, after which you will need to find another service that’s willing to import in that format). If you want to manipulate your data in a way your current service provider doesn’t support, you’re again out of luck — they won’t allow other service providers to touch their (your) data.
Now consider this:
You have a service provider that gives you space to store named, structured data objects or data stores. It may be file-like (e.g. an XML object representing a document) or database-like.
You can work with the data in two ways — either you can use a locally installed application that directly loads from (and saves to) the cloud data service, or you can select a third party cloud application service that has functionality that can operate on your data format (e.g. a word processor service or a blog publishing service). You provide data access to the third party service by providing an access key to your data store. If you don’t trust third parties with your data, you put it in an encrypted store, decrypting on-the-fly on your desktop client application (and of course encrypting again before putting the data back on the wire). Some services will directly connect to each other (e.g. a word processor service may use somebody else’s dictionary service rather than develop their own).
Provided that data store formats and API’s have some semblance of standardization, you will be able to access your data with one service one day, another next and your PC or mobile phone the next. You’ll be able to move data from one storage provider to another if you wish. You will be able to embed/publish data from multiple data stores in different places on the Web without copying and pasting. And you will live happily ever after.
Here’s an admirable attempt by Google — you can access Google Translate as a function within a Google spreadsheet:
P.S. Those of you who have ever used sed and awk with a few Unix pipes to manipulate data and have wondered why the rest of the computing world can’t be so beautifully simple, raise their hands. The rest of you, go ahead and wonder how that could possibly be related to what we’re discussing.
