Some of you know I’ve been working with SQL Server for a long time, more than 22 years in fact, and that was after spending many years working with computers and doing programming that had nothing to do with relational databases. The first computer programming class I took used punch cards, as did the first class I taught. No knowledge of the computer infrastructure was required to submit the cards to the operator and pick up the output. It was useful to be aware of certain limitations of the system, but really, all we needed to know was how to format and submit our programs. A few years later, when we moved to terminal-based programming, we still needed no specific knowledge of the computer system itself. We needed to know how to create and edit a file, and we needed to know the commands for compile and execute, but that was all. What kind of computer was it? Where was the processing actually taking place? Which other users were trying to run programs at the same time? I have no doubt someone knew the answers to these questions, but as programmers, we had no access to, or even interest in, this level of information.
I couldn’t help but think of programmers’ isolation from the machine when I started reading about cloud computing and Microsoft’s cloud database service SQL Azure. (You can read some basic information about SQL Azure at www.microsoft.com/windowsazure/sqlazure.) The descriptions of the service tout the fact that database programmers don’t need any knowledge of how or where the data actually exists, or who else might be using the same machine for other, possibly unrelated, purposes.
So how is cloud computing with SQL Azure different from the dumb terminal model we used so many years ago? Is it like a pendulum swinging back and forth, from programmer isolation to programmers having full knowledge and control of the physical environment and now back to programmer isolation again? Or is it more like a three-dimensional spiral; each time we come back around to a point we were at before, we’re a little higher up, with better, more powerful machines and more complex infrastructure? Plus, now we have the Internet. With SQL Azure, we aren’t limited to accessing a computer that’s in close physical proximity to the punch card stations or the dumb terminals. With SQL Azure, and cloud computing in general, you can be anywhere in the world and so can your data. In fact, all of your data doesn’t even have to be in the same physical location.
I can’t begin to go into any detail here about how SQL Azure actually works and what you need to do to get set up to use it. I suggest you take a look at the Microsoft website I referenced earlier, which should give you a good start. You can even download a training kit, which is full of example scripts and hands on labs, from the website to really get your hands dirty.
So how might working in the cloud change your practices? What would you do differently if you had no access to the physical storage mechanisms and no ability to do any kind of system configuration, monitoring, or tuning? I’m aware of the fact that there are SQL programmers not working with cloud-based data right now who have no interest in the actual physical storage or system configuration and wouldn’t know what to do with the results of any type of monitoring. But if these programmers ever did develop an interest in digging deeper, they would have the tools and resources to do that in a typical SQL Server environment.
I must admit that the thought of not having full information about my data environment available makes me uncomfortable. But maybe that’s just because I have enough experience to know what to do with that information. For users who just need to get a job done and don’t have the need to understand exactly what’s happening at every step as long as the job gets done, maybe it’s a good thing to let someone else handle the messy physical details and deal with hardware setup and SQL Server software installation and patching. It’s probably a good thing that nobody is being forced to access only data in the cloud; instead, we can choose the services and tools that work best for us.