During yesterday’s Day two keynote at the BUILD, Microsoft announced the availability of the Windows Azure SDK 1.5 and Windows Azure Tools for Microsoft Visual Studio 2010. You can download the tools here using the Web Platform Installer.  All three of these releases are aimed at simplifying development, deployment, and management on the Windows Azure platform.

The Windows Azure SDK includes the following new features:

• Re-architected emulator enabling higher fidelity between local & cloud developments & deployments.
• Many fundamental improvements (performance of emulator and deployment, assembly/package validation before deployment)
• Support for uploading service certificates in csupload.exe and a new tool csencrypt.exe to help manage remote desktop encryption passwords.
• Many enhancements and fixes to Windows Azure SDK 1.4.

 Also available are several new enhancements in Windows Azure Tools for Visual Studio for developing & deploying cloud applications.  These enhancements include:

• Add Windows Azure Deployment project from Web Application project.
• Profile applications running in Windows Azure.
• Create ASP.NET MVC3 Web Roles.
• Manage multiple service configurations in one cloud project.
• Improved validation of Windows Azure packages.

Now, it is easier to add a Windows Azure deployment project to common web projects like ASP.NET MVC, ASP.NET Web Forms or WCF. Based on the type of web project that you have, the project properties for assemblies are also updated, if the service package requires additional assemblies for deployment.

With profiling support in the Windows Azure Tools you can easily detect performance bottlenecks in your application while it is running in Windows Azure.

The tools now support creating ASP.NET MVC3 web roles. The new template includes the new universal ASP.NET providers that support SQL Azure and it will also make sure that ASP.NET MVC assemblies are deployed with your application when you publish to Windows Azure.

 

If you want to maintain different settings for different deployment environments, the Windows Azure tools now support multiple service configurations in the same Windows Azure Project. This is especially useful for managing different Windows Azure Storage connection strings for local debugging and running in the cloud.

Finally the new tools will help you avoid some of the common problems when you deploy your application to Windows Azure. If you forget to include a local assembly in your package or you publish with a local Azure Storage connection string, the tools will let you know.

 

Read more about the recent features here. 

The Windows Azure Platform Training Kit has also been updated for the new tools. The Windows Azure Platform Training Kit includes a comprehensive set of technical content including hands-on labs, presentations, and demos that are designed to help you learn how to use the Windows Azure platform. You can download it here. 

New Windows Azure Service Management API Features

Introduction:

We are also excited to announce the release of new service management APIs for the following scenarios:

• Rollback an In-Progress Configuration Update or Service Upgrade
• Ability to Invoke Multiple “write” Operations on an Ongoing Deployment
• More Descriptive Status for Role Instances
• New API Method: Get Subscription

Background:

The Windows Azure Service Management API enables Windows Azure customers to programmatically administer their subscriptions, hosted services, and storage accounts.

Rollback an In-Progress Configuration Update or Service Upgrade

The API now exposes a new method – Rollback Update or Upgrade – which can be called on an in-progress service update or upgrade. The effects of rolling back an in-progress deployment are as follows:

• Any instances which had already been updated or upgraded to the new version of the service package (*.cspkg) and/or service configuration (*.cscfg) files will be rolled back to the previous version of these files.
• Note that the customer does not need to resupply the previous version of these files – the Windows Azure platform will retain these for the duration of the update or upgrade.
  • Any instances, which had not yet been updated or upgraded to the new version, will not be updated or upgraded, since those instances are already running the target version of the service.
  • Typically, such instances are not even restarted by the Windows Azure Fabric Controller as part of the Upgrade/Update à Rollback sequence.

Here are some additional details about the new Rollback Update or Upgrade method:

• As above, Rollback can be invoked on an ongoing service configuration update (triggered via Change Deployment Configuration) or service upgrade (triggered via Upgrade Deployment).
• It only makes sense to call Rollback on an in-place update or upgrade since VIP swap upgrades entail atomically replacing one entire running instance of your service with another.
• Rollback can be applied to upgrades performed in either manual or automatic mode. 
• Note that Rollback itself can be called in automatic or manual mode as well.
  • Rollback can only be called when an update (configuration change) or upgrade is in progress on the deployment, which can be detected by the client via checking whether the value of the “RollbackAllowed” flag – as returned by Get Deployment or Get Hosted Service Properties – is “true”.
  • In order to invoke the version of these methods which returns the RollbackAllowed field, you must use the following version (or greater) in the request header: “x-ms-version: 2011-10-01”. For more information about versioning headers, see Service Management Versioning.
  • An update or upgrade is considered “in progress” as long as there is at least one instance in the service, which has not yet been updated to the new version. 

What’s an example of when I might use this?

Suppose you are rolling out a major in-place upgrade to your Windows Azure hosted service. Because your new release is substantially different from the old, you want to control the rate at which the rollout proceeds and so you call Upgrade Deployment in manual mode and begin to Walk Upgrade Domains. Role instances in the 1st and 2nd upgrade domains appear to come up healthy after being upgraded but, as you’re walking the 3rd upgrade domain, some role instances in the 1st and 2nd upgrade domains become unresponsive. So you call Rollback on this upgrade, which will (1) leave untouched the instances which had not yet been upgraded and (2) roll back instances which had been upgraded (i.e., those in the 1st and 2nd upgrade domains as well as any in the 3rd to which the upgrade had already been applied) to the previous service package and configuration.

Can’t I achieve the same effect by calling Update or Upgrade on a service – in order to roll that service to the previous version? IOW, what does Rollback buy me?

Without Rollback, if you were in the process of updating or upgrading your service from version X to version X+1 and decided that you wanted to go back to version X, you first had to update or upgrade all role instances to X+1 then, after that completed, start a new update or upgrade to X. With Rollback, it’s possible to short-circuit that process (changing the target version from X+1 to X, in the midst of the upgrade to X+1), which results in less service interruption/churn. Moreover, the Windows Azure platform now retains (for the duration of an update or upgrade) the service package (*.cspkg) and service configuration (*.cscfg) files from the version of the service before the update or upgrade began (X), which means that the customer does not need to resupply these in the event that he wants to go back to the pre-upgrade version.

Ability to Invoke Multiple “write” Operations on an Ongoing Deployment

In order to provide customers more flexibility in administering their hosted services, we are relaxing the constraints on when mutable operations can be invoked on deployments. The mutable or write operations are: Change Deployment Configuration, Upgrade Deployment, Update Deployment Status (used to Start or Stop a deployment), Delete Deployment, and Rollback Update or Upgrade. In particular, prior to this release, customers were only able to have a single “in-progress” mutable operation on a deployment: once such an operation was started, the customer had to wait for that operation to complete before starting another one. That is, the deployment was locked. 

With this new Service Management API release, a couple methods (Get Deployment and Get Hosted Service Properties) return a new field, which explicitly informs customers as to whether a given deployment is “Locked” (unable to have write operations performed on it). Moreover, the period of time during which a lock is held (for a given deployment) is substantially reduced, which enables parallelizing or interrupting certain workflows.  

• As with the RollbackAllowed field, in order to invoke the version of these API methods which return the Locked field, you must use the following version (or greater) in the request header: “x-ms-version: 2011-10-01”.

What’s an example of when I might use this?

Suppose you’re performing an upgrade and there is a bug in the new version of the role code which causes the upgraded role instances to repeatedly crash.  This will prevent the upgrade from making progress – because the Fabric Controller will not move onto the next upgrade domain until a sufficient number of instances in the previous one are healthy. This is referred to as a “stuck deployment” and, with this Windows Azure release, customers can now get themselves “unstuck.” In particular, in that case, you could elect to apply a fresh Update or Upgrade over top of the toxic one.

More Descriptive Status for Role Instances

In order to provide better diagnostic and service health monitoring capabilities, customers can now obtain more descriptive information from Get Deployment about the state of their role instances than was previously available. Two new fields will be returned (InstanceStateDetails and InstanceErrorCode) and an existing field (InstanceStatus) will contain new values, including: RoleStateUnknown, CreatingVM, StartingVM, CreatingRole, StartingRole, ReadyRole, BusyRole, StoppingRole, StoppingVM, DeletingVM, StoppedVM, RestartingRole, CyclingRole, FailedStartingVM, UnresponsiveRole.

• In order to invoke this method, you must use the following version (or greater) in the request header: “x-ms-version: 2011-10-01”. For more information about versioning headers, see Service Management Versioning.

New API Method: Get Subscription

With this Service Management API release, we introduce a new method, Get Subscription, which enables obtaining basic information about a subscription (the subscription name, status, and email addresses of the Account and Service Administrators) as well as the current and max usage as far as number of storage accounts, hosted services, and cores. That is, with this new method you can programmatically obtain the quotas associated with your subscription.

• In order to invoke this method, you must use the following version (or greater) in the request header: “x-ms-version: 2011-10-01”. For more information about versioning headers, see Service Management Versioning.

What’s an example of when I might use this?

There are a couple immediate use cases for this new method. First, for security compliance purposes, you might have a program which periodically confirms that the configured service administrators for a given subscription are as expected (i.e. that no rogue values for AccountAdmin and ServiceAdmin have been configured). Secondly, this method provides visibility into a key component of your Windows Azure bill. Namely, the CurrentCoreCount value tells you how many cores all of your hosted services’ deployments together are using. The “compute hours” portion of your bill is calculated based on how many cores were used by your services over the billing period.

To read more about all of the Windows Azure-related announcements made at BUILD, please read the blog post, “JUST ANNOUNCED @ BUILD: New Windows Azure Toolkit for Windows 8, Windows Azure SDK 1.5, Geo-Replication for Windows Azure Storage, and More”.  For more information about BUILD or to watch the keynotes, please visit the BUILD Virtual Press Room.  And follow @WindowsAzure and @STBNewsBytes for the latest news and real-time talk about BUILD.

Vijay Rajagopalan is Principal Group Program Manager for Windows Azure. Follow Vijay at @vijayrvr.