SQLServerCentral Editorial

Dreaming of Clouds


Yesterday I gave a few downsides of cloud services. Along with income tax filing in the US, that was a double downer, so today we'll brighten things up with a look at some of the advantages of the cloud. Note that I think we are quite a ways from some of these things working, but I'm looking forward here.

I want to define the cloud as a set of services in the network, which is a very broad definition.  The network can be your corporate network, a private network with some hosting company, the public Internet, etc. It can take many forms, as can the services that are hosted there, so think broadly here.

For SQL Server let's change that to be a "networked" version of SQL Server where you essentially "install" SQL Server in your network, somehow partitioning out a series of Windows hosts (physical or virtual) that can actually execute these services. After all, a physical CPU somewhere (and memory and disk) have to actually do the work of storing your data and executing your query, but let's imagine that we can install SQL Server to our networks.

Imagine a DBA now concerned with managing the "databases", assigning logins to these databases and the various permissions needed. The DBA would request backups, and perhaps direct them to some network location, but the physical location of the backups wouldn't necessarily correspond to the machine on which SQL Server is running.

The DBA would connect to the SQL Agent scheduler, able to schedule a job against any database or requesting any resources, not tied to any particular server. All connections would use network locations to specify file services (folders and files), database services (other SQL Server services), and more. To application developers everything would look like a network resource, and they wouldn't need to be concerned about whether their application was on the same server as the database or not. It would just be some IPv6 location. We could allocate them a slice of the cloud (xx GB of space) and let them create databases in the cloud on demand. They could have the cloud "shut down" instances that weren't using resources, bringing them back when someone requested access.

We wouldn't ever need to "move" databases. The cloud would handle the movement of databases to new physical machines as more memory and CPU were needed. We could set limits on usage, and get alerts when our SQL Server cloud needed more resources. We could integrate with a SAN to carve up large blocks of storage as needed, perhaps even among multiple SANS. A lot of the minutia of managing individual servers would go away. Presumably we could segregate out our cloud into sections (dev, QA, production) and even apply patches to whole slices of our cloud at once.

I think it would be a very exciting world, one in which we'd have maintenance DBAs that dealt with issues related to actual physical machines (files not copying correctly, patches partially applied, failed servers, adding hardware etc.), and then production DBAs who just managed the database services, never dealing with an individual server, just worrying about one large "service" of SQL Server seen through SSMS and the various databases of which it's a part.

It could be a very exciting way to use SQL Server in the future. There's a lot of work to get there, but I think the entire paradigm of how we've grown used to SQL Server could easily change in the next decade or two.

Steve Jones

The Voice of the DBA Podcasts

Everyday Jones

The podcast feeds are available at sqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

You can also follow Steve Jones on Twitter:

Overall RSS Feed:

or now on iTunes!

Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.


3 (1)




3 (1)