Anyone who has worked on a software development project will be familiar with the concept of an “environment”. Simply put, an environment is a set of infrastructure that you can deploy your application to, supporting a specific activity in your software development lifecycle. Any significant project will have multiple environments, generally with names such as “Test”, “UAT”, “Staging” and “Production”.
On a traditional project, each environment is supported by dedicated physical infrastructure: for example, the Test environment is those two servers under the corner desk, the UAT environment is on Rack #4 in our lab, and production is hosted in the downtown datacentre. Typically these environments won’t be identically configured, with the “early” environments being hosted on whatever you can find lying around, with the “later” environments becoming increasingly more expensive and better managed.
When teams first start working with Windows Azure, they are often unsure about how to effectively represent the familiar concept of “environments” using the capabilities of the cloud. They note that every deployment has a “Production” and a “Staging” slot, but what about all their other environments such as Test or UAT? Other teams ask if they should host some environments on their own servers running under the compute emulator.
The short answer is that you probably want to have the same environments for a Windows Azure project as you would for any other project. The compute emulator is great for local development, but there are significant advantages to hosting every other environment in the cloud—for a start, the environments are identical so bugs will be picked up much earlier. But supporting multiple environments requires carefully planning how to use the various abstractions provided by Windows Azure (beyond just the “Production” and “Staging” deployment slots). Let’s take a look at the key abstractions and some considerations relating to environments:
Now that we understand the purpose of each of these abstractions, let’s look at how a typical organisation may use these to represent multiple environments for a single application. Note that depending on your requirements you may end up with a solution quite different to this one, but you should be able to use similar thought processes to arrive at a solution that makes sense for you.
The first thing you’ll note is that this organisation has chosen to use two different billing accounts. This is because one department is responsible for paying for the development (including testing) of solutions, while another is responsible for ongoing operations of production solutions.
Within the Development billing account, the organisation is using separate subscriptions for Development and Test. This was done because the developers and testers each wanted the ability to manage their own environments. The developers wanted to be able to make changes whenever they wanted for the purposes of experimenting and debugging. The testers wanted to ensure their environments were controlled, and in particular they didn’t want developers to be able to make changes without going through the automated build process. Within the Operations billing account, currently only a single subscription is used, which is only accessible to the operations team.
With the Subscriptions providing an appropriate management boundary for different teams, the organisation is using Hosted Services to represent the different environments. The development team has chosen to use a couple of different “Sandbox” services for experimenting and debugging, and can easily add or remove services as their needs change. The test team has chosen to use one “Test” service for their day-to-day testing of nightly builds, and a “UAT” service for user acceptance testing of a more stable build at the end of each sprint. Finally a single service is used in the Operations subscription for the hosting the production application.
As mentioned earlier, every service has a “Staging” and “Production” slot, but in this organisation only the “Production” slot is in constant use, with the “Staging” slots empty most of the time. The developers don’t bother using the “Staging” slot at all as they don’t care about downtime during the deployment process. For the test and production services, the “Staging” slot is used only when deploying new builds—once the new deployment has been signed off, the virtual IP addresses are swapped and the resulting “Staging” deployment is deleted to save money.
Using multiple subscriptions for different disciplines is necessary to provide the necessary isolation and access control. However for this to work you also need to make sure you are also following good security practices. Some of the main considerations for Windows Azure are:
While Windows Azure contains many useful abstractions, there is no direct equivalent to an “Environment” in the sense used by the typical software team. Any organisation planning a production application on Windows Azure should consider how to best use the Windows Azure abstractions to provide the best mix of flexibility and control for each team and activity.
Great post Tom!
Also worth mentioning for your readers is the co-admin capability, where multiple Windows Live IDs can have admin privileges to a subscription, eliminating the need to share WLID credentials.
Good call Brian. I just updated the post to clarify this.
Very useful post Tom.
Had faced similar challenges while trying to make Azure align with our existing software engineering practises. To fit the pieces it helps to have a clear understanding of the Azure billing and operational models (abstractions as you put it) design...which you have very aptly described.
I and my colleagues had authored a paper on the topic of practising Agile software development on the Azure platform... had made an attempt to discuss similar challenges and techniques to approach it. Incase you get time to read, would like to hear your views.
hi thanks for that
When we have SQL Azure involved and Azure table storage we have problems because they are not in the package and changes need to be done manually ... and it is not good at all