A Cloud Service By Any Other Name...

As a firm believer in freedom of expression, I guess I can't complain about the names that the Windows Azure team give to their services and features. After all, my responsibility is just to write about them. In theory that can call them whatever they like. The problem is that they keep calling things what they literally are.

Mind you, it's not just the Windows Azure people. The same problem seems to raise its head with many other technologies. I suppose it's just that I encounter the Windows Azure ones most often in my daily working life. And using literal names for things seems eminently sensible at first glance. For example, when Mr. Heinz started putting things in cans he used the obvious names. "Baked Beans", "Spaghetti Hoops", and "Mushroom Soup". His business may well have been less successful if he'd decided to label the tins "Whizz-bang Nice Stuff", "Delicacy Number 3", and "Supercalifragilisticexpialidocious".

But if Bill had decided to follow the Heinz approach way back in 1985 when Windows 1.0 appeared, he would have called it "Operating System". So everything written about it since then would have referred to "The Microsoft Operating System operating system". Obviously this would have been stupid. So why am I continually having to write "...stored in a Windows Azure SQL Database database" and "...hosted in a Windows Azure Virtual Machines virtual machine"?

I suppose giving things names that are generic descriptions makes it easier to recognize what they do. Amazon chose to give their cloud services distinctive names such as Glacier, Beanstalk, CloudWatch, Redshift, and DynamoDB. I guess I might want to store my data in a DynamoDB, or have my application monitored by a CloudWatch (unless it's actually something you wear on your wrist). But as I'm not a polar explorer, a fairy tale treasure hunter, or an astronomer I'm struggling to understand why I'd want a Glacier, Beanstalk, or RedShift.

Perhaps the other problem is that, like domain names, the world is running out of pronounceable combinations of letters that aren't already registered, or that don't mean something rude in some countries or regions. Like the unfortunate choice by the Japanese refrigerator company Fukushima Industries that my very respectable daily newspaper recently revealed...

Mind you, it gets even more confusing as you delve deeper into Windows Azure and try to write prescriptive guidance that is accurate to the nth degree. I recently discovered that a Windows Azure Virtual Machines virtual machine runs within a Windows Azure Cloud Services cloud service in much the same way as a Cloud Services cloud service does. And I assume that a Windows Azure Web Sites website does so as well. So now I'm having to refer to Windows Azure Cloud Services web and worker roles to differentiate the hosting platform I'm discussing from the Cloud Services cloud service that a Virtual Machines virtual machine runs in.

Of course, at the heart of all this is the strict writing style and capitalization rules we've traditionally applied here at p&p. Thankfully Microsoft is adopting a more modern style for technical documentation, which might mean that I can get away with just talking about "a Virtual Machine" or "a Cloud Service". With luck I can just use capitalization to differentiate between a virtual machine in general terms (a non-physical server) and a Virtual Machine that is an element of Windows Azure hosting services. Though, confusingly, I'm mandated to use lower-case for "web role" and "worker role", so I might be a little too optimistic here.

Perhaps I'll just write everything in lower-case. Microsoft Word word processor will automatically capitalize the first letter of sentences, and I'm sure my editor will look forward to sorting out the rest...