It's becoming clear that creating guidance on cloud computing is great deal more difficult than for most other development environments. Or, to be more precise, following our usual practice of combining written guidance with a reference implementation (RI) code sample is turning out to be what you might whimsically call "an interesting experience".
It's not that we can't create suitable examples, and we seem to be doing OK writing guidance to accompany them. It's the deployment and setup that are causing the problems, which most of our users have yet to encounter as we get further down the road with our Windows Azure Integrating with the Cloud hybrid applications Guide.
As it's a hybrid application integration scenario, we are demonstrating and providing guidance on a whole range of Azure technologies and services. There's a smattering of Azure Connect, a pinch of Data Sync, some Service Bus Queues and Topics, a VM Role, a choice selection of SQL Azure databases, a wee snifter of Enterprise Library Extensions for Windows Azure, a delicate combination of SQL Azure Reporting with Windows Marketplace, and a dollop of Azure Cache to top it off.
And that's not all. We're using the Access Control Service (ACS) to authenticate application users, and installing the website part of the application in multiple datacenters to demonstrate using Traffic Manager. We're even simulating an external transport partner based on the interaction pattern typical for companies such as DHL and UPS. As part of the team that designed the architecture and technology map for the project, I suspect I must be suffering from some kind of self-harming psychosis.
What's at the root of the problems is that almost all of these application ingredients are services exposed by Windows Azure (which makes sense considering the scope of the guide), and require users to manually create and configure a namespace for each technology using the Windows Azure portal. We can ease some of the pain by providing a setup program that uses the Azure Management API to configure the services after the namespaces have been manually created, but users still have to edit the program and all of the configuration files to specify their namespaces and their Azure account credentials.
On top of all this, there's connection strings to the databases, queue names, connection endpoints, WIF settings, data sync paths, cache URIs, and more to configure before it all works. The setup instructions in the readme file grow by the hour, and keeping them up to date is a whole new career opportunity I seem to have acquired, without actually applying for the job.
And, of course, users have to subscribe to Azure and pay for all of the services. I can see that this might dissuade some from actually setting up the example. If the first bullet point in the instructions is "Sign up for all of the Azure services in three data centers", we might just encounter some opposition. Strangely enough, the Azure people don't seem very keen for us to fill their data centers with applications running for free.
So one of the simplifications we've had to make is to limit the requirements of the sample application by making it auto-detect the presence of some services and change its behavior if not present, and allowing users to turn off some features where they don't have a suitable Azure service subscription. I suppose you could call this unintegrating with the cloud (or dehybrigation if you read my post from a couple of weeks ago). And, as far as Traffic Manager and SQL Azure Reporting go, we don't include them in the sample at all so we can make do with just one datacenter.
Yet the guide still has to cover all the bases. If we're doing hybrid applications, we need to provide guidance on the typical hybrid application technologies. So we've got the dev guys building spikes to test and confirm our initial assumptions and to discover the gotchas. The guide will patiently explain how our fictitious example corporation built their application to use all these features, but users won't see a few of them in the sample code.
Hopefully the Sale of Goods Act (1979) or my professional indemnity insurance will cover me against claims for what's missing...