I should not have been surprised. The session was on “Building Your Dev and Test Sandbox with Windows Azure Infrastructure Services”, not best practices, interesting use cases, or automation for dev/test environments in Azure. It was, as advertised, an hour allotted for just the setup process. And unfortunately for those who stayed for the full session, nothing was ultimately built.
Instead, we watched an hour of .ppt slides, dissected a pricing matrix and joined in some awkward applause about the newest innovations in Dev/Test (pricing and marketing). You can watch it here, but I will save you the trouble. There were starter scripts, code snippets to make bespoke ,and packages to install. After what I saw, it wasn’t much of a shock when the demo environment failed.
And at the end, there was a Q & A.
Summarized for your benefit:
Can I take a live snapshot? (No, we recommend not. Shut everything down first.)
Clone and share the environment? (No, not really.)
Connect to TFS? (In the cloud? No, don’t do that.)
I stayed for the hour+ because I wanted to watch Microsoft explain how Azure helps developers build complex apps. And I wasn’t surprised. Making dev/test simple is what CloudShare does, and it’s not easy.
Like AWS, Rackspace and the rest of the production hosters, Azure sells VMs. They have massive scale that provides the power required to run a highly available service in production. However, they just don’t provide dev/test environments.
The time and effort spent in setting up the production public clouds, should be left to, well, production. The ups and downs in dev/test need something different. If you move your dev/test from a public cloud today, we have a special promotion for you. Just mention this blog post.