Microsoft's cloud computing platform, Windows Azure, was announced at its Professional Developers Conference in October 2008. That was also the Windows 7 PDC, which diverted attention from Azure, but another problem was that Microsoft itself seemed half-hearted about it; it felt like a box the company had to tick in order to keep up with Amazon and Google, but that it was happier to keep on selling on-premise servers. It did not help that signing up for the beta was fiddly and difficult - anyone remember those "developer tokens"? - and that the early developer portal and tools were awkward to work with.

Two and a half years later, Azure is much improved, and those early foundations have proved solid despite the poor developer experience. Microsoft has also made it easier to kick the tires. In particular, if you have an MSDN subscription - which most serious Microsoft-platform developers will have - then since April 12 you get free Azure compute time amounting to 750 hours a month of an "Extra Small" instance with a Professional subscription, or more with the higher-level subscriptions. That means an Extra Small instance can run continuously without charge. Even an extra small instance is not that small a machine: when I tried it I found a virtual Quad Core 2.1 Ghz processor with 767MB RAM. There is also an allowance of storage, SQL Server, and so on. All the current offers, including similar deals for partners, are listed here.

This is a smart move from Microsoft, since previously it was easy to spend money inadvertently. The reason is that Azure charges for deployed instances even when they are not running. You have to delete them completely to stop paying.

But what is Azure? It is worth having a look at some of the more detailed descriptions of how the platform works, like this book extract by Chris Hay and Brian Prince, or this MSDN article, or this description from the perspective of Ryan Barrett who works on Google App Engine. Conceptually, it is a way of deploying applications in the cloud; but it is implemented by deploying virtual machines, with at least one for each application. The reason that deploying an application to Azure takes a few minutes is that the service has to configure a virtual machine image with your code and the correct runtime components, and then copy that virtual machine to one or more runtime locations and spin them up. Azure retains the original, so that it can replace the runtime copy if anything goes wrong. Note the implication that you should never store state or data on the application instance, as it could be wiped at any time. Microsoft also takes responsibility for patching the images with bug-fixes and security updates.

The new VM role is a bit different. In this case you simply upload your own VM image and Azure runs it; you have responsibility for patching and maintenance. It is actually not a good scenario, since you cannot directly patch the VM in the cloud; you have to prepare a new image and upload it, though you can use differencing to avoid a huge upload. The VM is still stateless, in that if you write any data it can get reverted by Azure to your last upload. See Steve Plank's detailed explanation here. It amounts to a good reason not to use the VM role unless you really need it.

This is just the compute aspect of Azure, of course. It is the other services that make this useful, including SQL Server and/or Azure's non-relational storage, AppFabric access control which can federate with your on-premise Active Directory, and so on.

What this means is that if you deploy on Azure, and presuming Microsoft has done a good job with the implementation, you get a high level of resilience and that the burden of maintaining the operating system is removed. With that in mind, Azure's pricing looks reasonable to me. You are not just paying for a VM to run your application, you are paying for a substantial infrastructure behind it. If you think what you would need to install and manage locally to achieve the same level of reliability, then Azure looks like excellent valuel; and I suspect that for some subset of applications it is the best choice on the market.

Every organisation already has a computing infrastructure of some kind, and despite the well-rehearsed advantages of cloud computing, the cost of doing something different and the fear of losing control of your own IT systems - which is a genine concern - can make Azure or its cloud competitors a hard sell. At the same time, it seems to me that anyone planning to deploy a new application, or considering how they deploy an existing one, should be considering cloud as well as on-premise options; and if it is a Windows platform, Azure should be on that list.

If you turn this into a skills issue, this means that knowledge of Windows Azure is an advantage in the job market, and now that Microsoft has made it easy to try it is well worth getting some hands-on experience.

I'm in Australia right now. I've been keynoting, paneling, and talking at Software Education's SDC conference. One of the participants asked the panel of speakers, "My management thinks I should be able to do the BA work and the Scrum Master work on my project. What do you think?" The other speakers were reasonable, explaining that because BAs are collaborative, they are a natural for the Scrum Master role.

I just about exploded out of my chair. "What is your management thinking? Do they want to do Scrum or do they want the project to fail? Or, maybe they want you to fail?" I ranted and raved a little more, but I'll save you from that. Here are the ideas behind my ranting and raving.

If you are new to agile and you want to do Scrum, then follow Scrum. There is a reason for the role of Scrum Master. That reason is that when you are new to agile, you need someone who advocate for the team to remove impediments at all levels of the organization, someone who can facilitate the process for the team. This person serves the team. This person, if serving the team, will spend all of their time serving their team. They will nudge the product owner into grooming the backlog. They will help people understand the acceptance criteria. They will facilitate the standup meetings and make sure those meetings occur, that the team collects the data and does not last longer than 15 minutes. That person ensures that the other problem-solving meetings occur. That person will solve problems on behalf of the team. In my experience, a new Scrum Master, for a new team spends a ton of time away from the team doing things like fighting the furniture police, fighting the network police, fighting the management police, so that the team can work. If this person also has deliverables to the team guess what? No one resolves the impediments. The team's velocity never settles into a rhythm. The team and the organization never sees the benefits of agile.

Someone says "Agile (or Scrum) doesn't work." Nope, that's not the problem. You're not doing agile or Scrum if you don't follow the directions. Don't adapt it if you don't first adopt it, lock, stock, and barrel.

When you try to play more than one role on an agile project, you are not adopting agile. You are adapting agile without understanding how to adopt it.

Multitasking on an agile project is just as bad as multitasking on any other project. You have to make it transparent. If you are asked to multitask, make it an obstacle. Show your lack of progress on the board. Consider using a kanban board inside a timebox if a number of people on the project are supposed to be multitasking. Ask your managers to start managing the project portfolio.

Because remember, it's not about the projects you start; it's about the projects you complete. It's not about the roles you take on; it's about the projects you complete. If you can successfully complete projects with multiple roles, great. That's a rare capability for rare projects. 

Keep your eye on the goal: finishing projects. Then you'll know what to do about this business of multiple roles.