Data as a Service

Why is working with a database always an awkward proposition?  It’s like this monolithic bank that houses all your valuables. Except it can’t be just any bank.  It has to be this specific bank, on this corner with this address.  Your data is tucked away in this one account with this particular name.  Here’s your bankbook.  Be sure to bring it back if you ever want to take a look at your data.  And don’t even think about leaving home without it.

It bugs me that the data is always associated with a server.  Your apps do this, mine do too.  Your data resides in this one server.  It’s the accounting database over here and the fulfillment database over there.  Sure, some apps use tricks to abstract away knowledge of the particular physical server from the application code.  You might have app configuration data or external connection files that whisper the secret name of the sales database into your app at runtime, but it is still pretty much the same thing.  Your app is focused around one or possibly a few monolithic storage locations that you manipulate with remote commands.  “Psst, hey buddy, why don’t you pick up that record over there.”  “Yes, that one.”  “Pick it up and move it over here.”  “That’s it, keep it coming.”  “Good.  Thanks a bunch.  Now do you see that other one?”

Now, there’s nothing wrong with this actually.  Your apps are structured that way because their functions are to manipulate that data.  Database servers work wonderfully for this.  But is that it?  Is that all databases are for, storing information for applications that exist merely to shuffle that specific data around?  I think we are missing something here, something big.  Databases can be so much more. 

I’m not talking about turning the database into some app server or ice-cream shop.  I’m talking about using the database as a database, just more so.  The problem here is that the database is treated as a server, when it should be being treated as a service.

A server is a physical thing.  You build your app around access to that server.  It is the primary focus, the center of your application universe.  You know it is there.  It is in your face the whole time.  A service is entirely different.  A service blends into the background. It becomes part of the environment.  You don’t really see a service; you just use it, because its very essence is as a natural part of the expression of your app.

If your database was a service, you could make much more use of it.  Think of a database service more like a file system than a database today.  With a file system you have a storage location that is available at all times (or almost all times.)  You don’t need particular credentials to make a file, to add some data, to read it back in.  You can employ mechanisms to read and write temporary files.  You can store data in an application specific location, etc.  There are many things that non-database-centric apps do with data, and that data today is stored anywhere else but in a database.

But it could be different, if only your operating system had a data service built right in.  Imagine writing apps that read and write one-off data tables, doing set operations over batches of numbers, joining, filtering, projecting, all without ever needing to know the name of a server or any credentials to get you in the door.  Imagine leaving large chunks of change in a data bank that has no name and is always available and always remembers who you are, and what what your app is.

Not possible you say?  How could it work without knowing where to put the data, without knowing how to get it back?

Well, it’s true that some data (a lot actually) is very specific data that is shared by many apps across many machines.  This kind of data needs to be housed in a specific location, etc, etc, etc.  Yet there are also other kinds of data that do not.  You see this kind of data today when you build web apps.  Session data is not global and shared.  It is tied to the user and the app and the machine.  In the new world of webservices 2.0, certainly there will be long-lived transactions that need to maintain session state.  Why shouldn’t this information be stored in a database, and why shouldn’t access to that database be automatic.  After all, why can’t the operating system pair the database back up to the app and the user?  It has all the information required.

So basically, if you write apps that maintain user data, session data, or global app data, you could be using a database to store this.  But unless your app is part of an enterprise ‘system’ you probably are not.  If the database were a service, there’d be no reason not too.  Data services would be easy to use and always available.  You could write your app to leverage these services and distribute it knowing it would always install, and always run.  Using data would be natural.

Natural is good.

Matt