Windows Azure

Windows Azure Storage at PDC 2009

Last week at PDC 2009, we announced several new features for Windows Azure Storage. Windows Azure Storage enables applications to store and manipulate large objects and files in the cloud via Blobs, store and manipulate service state via Tables, and provide reliable delivery of messages using Queues.  In addition, we also announced two new features coming soon to storage:

• Windows Azure XDrive – This allows your Windows Azure compute applications running in our cloud to use the existing NTFS APIs to store their data in a durable drive. The drive is backed by a Windows Azure Page Blob formatted as a single NTFS volume VHD.   The Page Blob can be mounted as a drive within the Windows Azure cloud, where all non-buffered/flushed NTFS writes are made durable to the drive (Page Blob).   If the application using the drive crashes, the data is kept persistent via the Page Blob, and can be remounted when the application instance is restarted or remounted elsewhere for a different application instance to use.   Since the drive is an NTFS formatted Page Blob, you can also use the standard blob interfaces to uploaded and download your NTFS VHDs to the cloud.
• Geo-Replication – We have been working hard to provide geo-replication between our geo-locations for your data.  We described at PDC 2008 how we replicate your data to keep multiple copies within the geo-location your storage account is allocated to.   When you do an update to your storage account we return success back when the update has been committed to multiple copies in that geo-location.  This keeps your data durable at the geo-location, and this hasn’t changed.   What geo-replication provides on top of this, is that after your update has been committed to your storage account in its primary geo-location, we quickly geo-replicate the update to another geo-location in the same geo-region (e.g., within the US, within Europe, within Asia).   This is an important feature for Geo-Disaster Contingency Planning, since this allows keeping multiple copies of your data in different geo-locations.

For more details on Windows Azure XDrive and Geo-Replication as well as the new Blob features listed below, please see the talk and slides from PDC 2009 on “Windows Azure Blob and Drive Deep Dive”.

At PDC 2009 there were also two other talks focused on Windows Azure Storage that you may want to check out:

• Windows Azure Tables and Queues Deep Dive – Deep dive into key areas for Windows Azure Tables and Queues.    This includes how to choose partitioning keys and what makes for fast and efficient queries for Tables.  For Queues, we describe some future features we will be providing such as (a) removing the time limit for how long a message can stay in the queue, (b) removing the time limit for how long the invisibility time can be, and (c) allowing you to change the invisibility time of a dequeued message at anytime.
• Building Scalable and Reliable Applications with Windows Azure – In terms of Windows Azure Storage, this talk describes the design target for scalability of storage accounts, Blobs, Entities, and Messages for commercial availability, and describes at a high level how we automatically load balance your data within a geo-location to meet the peak traffic demands for your data.   It also describes how to use Queues to create scalable and reliable workflow for your computation, and describes how to use rolling upgrade to perform a schema change (add a new property) for your Tables.

For the PDC 2009 new features, these are versioned using “x-ms-version: 2009-09-19”. All prior versions of commands executed against the storage system will continue to work, as we extend the capabilities of the existing commands and introduce new commands.

With the PDC 2009 release, we now support two types of blobs:

• Block Blob – This is the blob type that we have offered since PDC 2008, which is optimized for streaming workloads. Each blob consists of a sequence of blocks, and each block is identified by a unique Block ID relative to the blob. This type of blob allows blocks to be uploaded with PutBlock and then committed with PutBlockList. Block Blobs can now be up to 200GB in size.
• Page Blob – With this release we have added a new type of blob optimized for random reads/writes called Page Blob. A Page Blob consists of an array of pages and each page is identified by its offset from the start of the blob. PutPage is used to perform a ranged put on the blob, and the update is applied immediately to the blob. In addition, regions of the blob can be cleared with ClearPage, and these cleared regions do not consume storage space. This means a storage account is only charged for the pages within a Page Blob with data stored in them. A Page Blob can be up to 1TB in size.

Enhancements for both types of blobs:

• Content Delivery Network – Windows Azure CDN can be used to cache your Windows Azure Blobs at strategically placed locations to provide maximum bandwidth for delivering your content to users. You can now specify the HTTP Cache-Control policy for each blob, and that will determine the length of time in which the blob will be cached in the Windows Azure CDN. You can specify the time-to-live (TTL) in the Cache-Control to be as small as you want, but remember you only benefit from the CDN if your TTL is long enough and content popular enough to get cache hits when serving the data out of Windows Azure CDN. See here for more details on Windows Azure CDN:
  http://blogs.msdn.com/windowsazure/archive/2009/11/05/introducing-the-windows-azure-content-delivery-network.aspx
• Custom Storage Domain Names – The custom storage domain name feature allows you to register a custom domain name for a given storage account, and to use that custom domain to access your blobs instead of the blob service URL:http://<account>.blob.core.windows.net/<container>/<blobname> . With the release, custom storage domain names now work with authenticated access as well as for anonymous access. See here for more details on custom storage domain names:
  http://blogs.msdn.com/windowsazure/archive/2009/11/05/accessing-windows-azure-blobs-using-custom-storage-domain-names.aspx
• Snapshot Blob – Allows the creation of read-only versions of a blob, which can be used for creating blob backups or blob versioning. An account is only charged for the unique blocks or pages; blocks or pages shared across snapshots and the base blob from which they were derived do not accrue additional storage charges.
• Lease Blob – Clients can now acquire a lease on a blob for exclusive write access to that blob. A lease will lock the blob for exclusive writing until the lease expires, while still allowing non-exclusive read access to the blob. The initial version of Lease Blob supports only one-minute leases, but the leases can be renewed to allow clients to maintain the lock for longer periods of time. Lease Blob is useful when dealing with high concurrent writes to Page Blob.
• Get Blob – This is used to retrieve both block and page blobs. In addition, it now provides an option to return a dynamically generated MD5 for ranged reads that are less than or equal to 4MB in size.
• List Blobs – Applications can now retrieve each blob’s application metadata and MD5 information when listing blobs.
• Blob Properties – Applications can now update a blob’s properties independently of the blob, and can specify the standard HTTP Cache-Control property for blobs.
• Root Container - Anonymous access is now provided for blobs stored in the root container. This was an important missing feature for supporting cross domain policy access for Silverlight. For example, you can now specify the following cross domain policy file in the root blob container:  http://account.blob.core.windows.net/clientaccesspolicy.xml

Enhancement for Queue:

• Dequeue Count – We now return a dequeue count for each message retrieved from Windows Azure Queue. This allows applications to see how many times a message has been dequeued. 

In addition to the above new features we made the following semantic changes as part of this versioned CTP release:

• Anonymous Blob Access – All blob containers having their access set to public using the “x-ms-version: 2009-09-19” version of the blob API will have their anonymous requests processed using the 2009-09-19 version of the blob APIs. Containers that are set to public with a prior version will still have their anonymous requests processed with the CTP2008 version of the blob APIs.
• Blob and Queue Authentication – Support has been added for an improved signing algorithm for enhanced security by including additional information as part of the canonicalization of the String-to-Sign.
• Listing Containers, Queues and Blobs – Changed the response format for listing operations to be more XML friendly.
• Blob and Queue Metadata Naming – Metadata for a container or blob resource is stored as a name-value pair associated with the resource. Metadata names must now adhere to the naming rules for C# identifiers
• Table Query – A table query is allowed to execute for up to 5 seconds before returning a result and potential continuation.
• Table DataService Version – All REST calls to the Table service must now include the DataServiceVersion andMaxDataServiceVersion headers on every request. Applications using the Astoria client library already send the required headers.

The above features for this new release are available via the Windows Azure Storage REST interface, and they are also supported as part of the new Storage Client Library just released with the Windows Azure SDK.

For more information, details about these new features can be found in the MSDN documentation here: http://msdn.microsoft.com/en-us/library/dd894041.aspx.

As always, we appreciate any feedback you might have.

Brad Calder
Windows Azure Storage

New Endpoint Options Enable Additional Application Patterns

At PDC last week, we introduced two communication-related capabilities:  a) inter-role communication and b) external endpoints on worker roles.  These capabilities enable new application patterns in Windows Azure-hosted services.

Inter-role Communication

While loosely coupled communication via Queues remains the preferred method for reliable message processing, roles can now communicate directly using TCP, HTTP, or HTTPS connections.  In addition, roles are notified as role instances within the deployment are added or removed, enabling elasticity.  A common application pattern enabled by this is client-server, where the server could be an application such as a database or a memory cache.

This is implemented via a) a worker role with an InternalEndpoint in the service definition, b) server code that calls RoleEnvironment.CurrentRoleInstance to discover what IP/port to bind to, and c) client code the calls RoleEnvironment.Roles[<TargetRole>] to discover the server endpoints.  For more information, refer to the HelloFabric SDK sample.  To add elasticity, refer to the documentation for the RoleEnvironment.Changed event to have the clients notified when server instances are added or removed.

External Endpoints on Worker Roles

Worker roles can now contain external facing endpoints, or InputEndpoints.  You can bind to these endpoints either directly in the worker role or from within a process that you spawn from the worker role.  Unlike the InternalEndpoints used by inter-role communication, InputEndpoints are load balanced.

A common application type enabled by this is a self-hosted Internet-exposed service, such as a custom application server.

Note that the port that actually gets assigned to the instances is different from the port that gets exposed via the load balancer.  This port can be discovered via the RoleEnvironment.CurrentRoleInstance property.

Enjoy!

Mohit Srivastava
Program Manager

November 2009 Release of the Windows Azure Tools and SDK

Last week at PDC 2009, we announced several new features for Windows Azure.  These are available in the November 2009 release of the Windows Azure Tools and SDK.

This release adds support for Visual Studio 2010 Beta 2 and Visual Web Developer Express 2010 Beta 2.

What’s New

• Service Model UI: A redesigned and significantly more complete interface for manipulating Role configuration information. To access, double-click on a role node in the Solution Explorer.
• Windows Azure Service Hosting Runtime Managed Library: The latest version of the Service Hosting Runtime API includes support for enhanced communication between roles and for runtime notification of service configuration changes. Direct communication between role instances enables new application development scenarios, including applications that distribute state across role instances. Service configuration changes include an increase or decrease in the number of request role instances and changes to the values of configuration settings.
• Windows Azure Diagnostics Managed Library: The new Diagnostics API enables logging using standard .NET APIs. The Diagnostics API provides built-in support for collecting standard logs and diagnostic information, including the Windows Azure logs, IIS 7.0 logs, Failed Request logs, crash dumps, Windows Event logs, performance counters, and custom logs.
• Windows Azure Storage Client Managed Library: The Storage Client library provides a .NET API for accessing the Windows Azure storage services.
• Certificate Management: Enhanced support for SSL certificates in Windows Azure and in the Windows Azure SDK enables the secure automated deployment of certificates to services hosted on Windows Azure.
• Variable-size Virtual Machines (VMs): Developers may now specify the size of the virtual machine to which they wish to deploy a role instance, based on the role's resource requirements. The size of the VM determines the number of CPU cores, the memory capacity, and the local file system size allocated to a running instance.
• External endpoints for worker roles. A worker role may now define any number of external endpoints for HTTP, HTTPS, and TCP, and specify the desired port number for any external endpoint.
• Persistent Local Resource Storage: Developers can now choose to persist data written to a local storage resource at runtime can when the role is recycled.
• Development Storage: Development storage provides a high-fidelity simulation of the Windows Azure storage services in the cloud. Tables can now be created dynamically in the development storage Table service.
• Additional role templates: Support for ASP.NET MVC 2 (2010 only), F# worker roles (2010 only), and WCF Service Application web roles.
• Updated Samples: The samples included with the Windows Azure SDK have been updated to demonstrate new features. The samples now include both C# and Visual Basic versions.

Introducing the Windows Azure Content Delivery Network

As part of the Windows Azure CTP, we are announcing the Windows Azure Content Delivery Network (CDN) to deliver Windows Azure Blob content. Windows Azure CDN offers developers a global solution for delivering high-bandwidth content.

Windows Azure CDN has 18 locations globally (United States, Europe, Asia, Australia and South America) and continues to expand. Windows Azure CDN caches your Windows Azure blobs at strategically placed locations to provide maximum bandwidth for delivering your content to users. You can enable CDN delivery for any storage account via the Windows Azure Developer Portal. The CDN provides edge delivery only to blobs that are in public blob containers, which are available for anonymous access.

The benefit of using a CDN is better performance and user experience for users who are farther from the source of the content stored in the Windows Azure Blob service. In addition, Windows Azure CDN provides worldwide high-bandwidth access to serve content for popular events.

When you enable CDN access for a storage account, the Windows Azure portal provides you with a domain name of the following format: http:/ /<guid>.vo.msecnd.net/. This domain name can then be used to access blobs in a public container. For example, given a public container “images” and a storage account “cohowinery”, once the storage account is enabled for CDN access, users can access the blobs in that container using either of the following two URLs:

• Windows Azure Blob service URL: http://cohowinery.blob.core.windows.net/images/
• Windows Azure CDN URL: http://<guid>.vo.msecnd.net/images/

When a request is made using the Windows Azure Blob service URL, the blob is read directly from the Windows Azure Blob service. When a request is made using the Windows Azure CDN URL, the request is redirected to the CDN endpoint closest to the location from which the request was made to provide access to the blob. If the blob is not found at that endpoint, then it is retrieved from the Blob service and cached at the endpoint, where a time-to-live (TTL) setting is maintained for the cached blob. The TTL specifies that the blob should be cached for that amount of time in the CDN until it is refreshed by the Blob service. The CDN attempts to refresh the blob from Windows Azure Blob service only once the TTL has elapsed. The default TTL is 72 hours. At PDC 2009, we will allow you to specify the standard HTTP Cache-Control header for your Windows Azure blobs. If this value is specified for a blob, then the TTL period will be set to the value specified in Cache-Control header.

The value of caching blobs in the Windows Azure CDN is realized only when the content is delivered from the CDN edge cache, so content requested only once during the blob’s TTL period will not get performance improvements from edge caching. The blob content that benefits the most from caching are blobs accessed frequently during their cached TTL period.

You may also register one custom domain name for Windows Azure CDN access per storage account in the Windows Azure Developer Portal. For example, if you wanted to access CDN content through the domain “merlot.cohowinery.com”, you can register that custom domain name for the CDN endpoint in the portal. Continuing with our example, this would allow you to then access your blobs via one of the following three URLs:

1. http://cohowinery.blob.core.windows.net/images/
2. http://<guid>.vo.msecnd.net/images/
3. http://merlot.cohowinery.com/images/

The last two URLs above would access the blobs in the “images” container via the Windows Azure CDN, whereas the first URL would access the blobs directly from the Windows Azure Blob service.

The following steps are to enable CDN access to a storage account:

1. Go to the Windows Azure Developer Portal.
2. Click on your storage account.
3. Click on “Enable CDN” for your storage account.
4. The portal provides a CDN domain name in the form of: http://<guid>.vo.msecnd.net/ .

The configuration created for this endpoint is not immediately available; it can take up to 60 minutes for the registration to propagate through the CDN network worldwide. Users who try immediately to use the CDN domain name will get a 400 error until the configuration is updated worldwide.

After you’ve followed the steps listed above, you have to designate the containers you want to provide access to as a public container (http://msdn.microsoft.com/en-us/library/dd179391.aspx). You can then access blobs in that container using the CDN URL. The CDN domain name represents the storage account, so any public blob container within that storage account can be accessed via the CDN URL.

You can also register a custom domain name for the Windows Azure CDN endpoint. Follow these steps to register and use a custom storage domain name for your CDN content:

1. Go to the Windows Azure Developer Portal
2. Click on your storage account
3. Click on “Manage” for your http://<guid>.vo.msecnd.net/ endpoint.
4. Enter your custom domain name.
5. To complete the register of your custom domain name you will be asked to verify that you own the domain. You will be asked to register for your “custom.domain.name” a CNAME record from “<guid>.custom.domain.name” to “domainnameverification.windows.azure.com”, where the <guid> is specified by us in the portal.
6. Once you have registered that CNAME, click on validate in the portal for the CDN endpoint. Windows Azure will then validate that the CNAME record exists, and if successful your custom domain name will be registered.

To use the custom storage domain name:

1. Create a CNAME record from “custom.domain.name” to “<guid>.vo.msecnd.net”
2. Make the containers you want to provide anonymous access for public containers using the following blob API:
   http://msdn.microsoft.com/en-us/library/dd179391.aspx
3. You can then begin providing anonymous access to your blobs with http://custom.domain.name/ via the Windows Azure CDN.

If you no longer wish to cache a blob in the CDN, you can:

• Delete the blob from the public container
• Make the container private instead of public using the blob API:
  http://msdn.microsoft.com/en-us/library/dd179391.aspx
• Remove the Windows Azure CDN endpoint from your storage account in the Windows Azure Developer Portal.

Blobs already cached in the CDN will remain cached until the TTL for each blob expires. When the TTL expires, the Windows Azure CDN will check to see whether the CDN endpoint is still valid and the Windows Azure blob is still anonymously accessible. If it is not, then the blob will no longer be cached. This means that if you want to change the content of the blob and the blob is currently cached in the CDN, the new content will not be available via the CDN until the CDN refreshes its content when the cached content TTL expires.

Additional information:

• At this time there is no charge for CDN access to your blobs while in CTP. Information on pricing for the Windows Azure CDN offering will be provided in the future.
• For best performance, we recommend caching blobs less than 10 GB in size.
• Windows Azure CDN access only works for anonymous access and for HTTP. HTTPS is not supported for CDN access.
• A custom domain name can be registered for only one storage account endpoint at a time. For example, one could not register the domain name “merlot.cohowinery.com” for two different Windows Azure CDN endpoints at the same time.
• You can register overlapping domain names for different endpoints. For example, the following domain names can be registered at the same time for different storage accounts or endpoints:
  • http://merlot.cohowinery.com/
  • http://vintage.merlot.cohowinery.com/

Stay tuned for more information about the Windows Azure CDN and additional new and exciting features at PDC 2009.

Brad Calder
Windows Azure Storage

Accessing Windows Azure Blobs Using Custom Storage Domain Names

Today we are releasing the ability to access Windows Azure Blobs using custom domain names. Windows Azure Blob storage enables applications to store and manipulate large objects and files in the cloud.

The custom storage domain name feature allows you to register a custom domain name for a given storage account for anonymous blob access using that domain name. Currently we provide access to blob storage using the following domain name:

http://<account>.blob.core.windows.net/<container>/<blobname>

But if I owned a domain called “toddlers.wingtiptoys.com”, I may instead want my blobs accessible via:

http://toddlers.wingtiptoys.com/<container>/<blobname>

When registering a custom storage domain name, you can use that domain name to access the contents of a public container instead of http://<account>.blob.core.windows.net/. For example, given a public container “images” for a storage account named “toys”, we register the custom domain name “toddlers.wingtiptoys.com” for that storage account. This allows us to access the blobs in that container using either:

• http://toys.blob.core.windows.net/images/
• http://toddlers.wingtiptoys.com/images/

If we also had additional public containers for our “toys” storage account called “onsale” and “blogs” they could also be accessed via:

• http://toddlers.wingtiptoys.com/onsale/
• http://toddlers.wingtiptoys.com/blogs/

Follow these steps to register and use a custom storage domain name:

1. Go to the Windows Azure Developer Portal
2. Click on your storage account
3. Click on “Manage” your domain name for your storage account endpoint.
4. Enter your custom domain name.
5. To complete the register of your custom domain name you will be asked to verify that you own the domain. You will be asked to register for your “custom.domain.name” a CNAME record from “<guid>.custom.domain.name” to “domainnameverification.windows.azure.com”, where the <guid> is specified by us in the portal.
6. Once you have registered that CNAME, then click on validate in the portal for the storage account endpoint. Windows Azure will then validate that the CNAME record exists, and if successful your custom domain name will be registered.

To use the custom storage domain name:

1. Create a CNAME record from “custom.domain.name” to “<account>.blob.core.windows.net”
2. Make the containers you want to provide anonymous access for public containers using the following blob API:
   http://msdn.microsoft.com/en-us/library/dd179391.aspx
3. You can then begin providing access to your blobs with http://custom.domain.name/

Additional information:

• A storage account can have only one custom domain name registered for it.
• The custom domain name currently can only be used to access blobs that are in public blob containers, which are made available for anonymous access. At PDC 2009, we will allow custom domain access to also be used for authenticated access to Windows Azure Blobs.
• Custom storage domain name access only works for HTTP. HTTPS access is not supported.
• A custom domain name can be registered for only one storage account at a time. For example, one cannot register the domain name “toddlers.wingtiptoys.com” for two different Windows Azure storage accounts at the same time.
• You can register overlapping domain names for different storage accounts. For example, the following domain names can be registered at the same time for different storage accounts:
  • http://toddlers.wingtiptoys.com/
  • http://age3.toddlers.wingtiptoys.com/

Stay tuned for more information about Windows Azure Blobs and additional new and exciting features at PDC 2009.

Brad Calder
Windows Azure Storage

Windows Azure Platform Launch Update

In October 2008 at our Professional Developer Conference we opened the Community Technology Preview (CTP) for the Windows Azure platform (Windows Azure, SQL Azure and .NET Services).  The CTP has been invaluable in terms of shaping many aspects of the Windows Azure platform.

PDC 2009 is an exciting event for all of us who are working on the Windows Azure platform as it’s our opportunity to show you the work that we’ve done over the past year, including some brand new features. The conference also marks the beginning of our transition from a CTP to a business.  For your planning purposes, this post maps out the key stages of that transition that you should be aware of.

• At PDC 2009, on November 17^th, 2009, a number of new features in Windows Azure will be made available for the first time.  The CTP will remain open through December 31^st, allowing you to experiment with the full feature platform and to give us any final feedback.
• Beginning January, 2010, new customers will have to sign up for an offer to access services on the Windows Azure platform. Usage during the month of January will be at no charge, so you can see your exact usage while still enjoying free service.
• On February 1, 2010, we will begin charging customers for using the Windows Azure platform.

Making the transition in these three steps accomplishes a few goals.  First, it gives you a chance to explore our full feature set for free.  Second, it allows our team time to get your feedback on the new features and address any issues that arise.  Finally, it lets you preview exactly how billing will work before you need to start paying.

We’d like to thank everyone who has participated in our Community Technology Preview.  Windows Azure, SQL Azure and .NET Services are better products because of you. We look forward to seeing you next month at PDC 2009!

Updated 10/30/2009: Clarified that January is free of charge.

New Eclipse, PHP, and Java Tools for Windows Azure

Yesterday at the Eclipse Summit Europe in Ludwigsburg, Germany, Microsoft announced two exciting new open source projects that will make it easier for PHP and Java developers to work with Windows Azure.  Both projects were created in collaboration with Soyatec, a France-based IT solutions provider.

The first project, Windows Azure Tools for Eclipse, helps PHP developers to use Eclipse to author Windows Azure projects.  From the Interoperability @ Microsoft blog:

Windows Azure Tools for Eclipse provides a series of wizards and utilities that allow developers to write, debug, and configure for and deploy PHP applications to Windows Azure. It is available for download at www.windowsazure4e.org

…

The plug-in also bundles the existing Windows Azure SDK for PHP, which we introduced a few months ago.

The second project, Windows Azure SDK for Java, is a client library for accessing Windows Azure storage from Java.  This library was used in the creation of the “Storage Explorer” feature of the Eclipse extension.

We on the Windows Azure team are excited about both of these projects, which are part of our ongoing work to provide a great platform experience for all developers.

The announcements yesterday also included an enhanced Eclipse experience on Windows 7 and version 1.0 of the Eclipse Tools for Silverlight.  Read more on the  Interoperability @ Microsoft blog.

Upcoming Changes to Windows Azure Logging

At commercial launch, Windows Azure will feature an improved logging system.  The new system will give users greater flexibility over what information is logged and how it is collected.

In preparation for the new logging system rollout, next week we will disable the ability to retrieve logs via the Windows Azure Portal.  Your existing applications will continue to run without modification.

Why a New Logging System?

In our initial Community Technology Preview, we provided a logging API that allowed developers to write custom messages to an append-only log.  The API was built on top of the efficient event tracing capabilities of Windows.

We’re expanding the functionality of the logging system to simplify common use cases.  In the new logging system, you’ll have the ability to collect other kinds of data, such as performance counters.  You’ll have the ability to automatically push your logs to Windows Azure storage at an interval you specify, in a structured format that’s easy to query.  You’ll have the ability to reconfigure your logging on the fly, so you don’t have to decide up-front exactly what data you’ll need to debug problems.

The new logging system retains the best attributes of our initial logging API (simplicity and efficiency) while adding important features to help you build robust and reliable applications on Windows Azure.

Microsoft, Zend and others announce Simple API for Cloud Application Services

Yesterday Microsoft, Zend and others launched the Simple API for Cloud Application Services project, a new open source initiative that allows developers to use common application services in the cloud, while enabling them to unlock value-added features available from individual providers.

In essence, this project will allow developers to write basic cloud applications that work in all of the major cloud platforms. More specifically, it gives developers who use the PHP scripting language a “speed dial” to develop basic cloud applications that can be deployed across all major cloud platforms, including Windows Azure, while making it easier to complement software vendors’ fully-featured technology interfaces in a harmonious way.

This is good for our customers because we know they work in mixed environments and this should make it easier to access new technologies from cloud vendors. And its good for our industry because while we’re still in the early stages of collaborating on cloud interoperability issues, we’ve made great progress with our own products and standards support, as well as through industry collaboration such as this project announced today with Zend, IBM, Rackspace and others.

To read more about the “Simple API” project, please read today’s blog post from Vijay Rajagopalan, principal architect, Microsoft at: http://blogs.msdn.com/interoperability/archive/2009/09/22/microsoft-zend-and-others-announce-simple-api-for-cloud-application-services.aspx

To read the full release, go here: http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20090922006086&newsLang=en

And please feel free to post a comment here with your thoughts or questions; we’d love to hear from you.

Introducing a New Upgrade Option: In-Place

Today we are introducing a new upgrade mechanism, called “in-place upgrade,” which enables you to incrementally roll a new version of your service over the existing version without first deploying the new version to staging. With this new mechanism, you can upgrade your entire application or just a single role (e.g. web role) without disturbing the other roles in your application. Note that you will still have the option to upgrade as before, by first deploying the new version to staging and then swapping it with the production deployment.

To ensure application availability during an in-place upgrade, Windows Azure stops only a subset of your instances at a time to upgrade them, while keeping the remaining instances running. To achieve this, Windows Azure logically partitions your application into “upgrade domains” and updates one domain at a time. During the Community Technology Preview, Windows Azure uses two upgrade domains for each application. This means that half of your role instances will be offline at a time during an in-place upgrade. In the future, you will be able to choose how many upgrade domains you want.

You can perform in-place upgrades using the Windows Azure Portal or the new Service Management API. Note that you cannot use an in-place upgrade when the upgrade involves changes to your service definition (e.g., new roles or endpoints). For further details please refer to the MSDN documentation.

Do let us know your feedback!

Thanks,

Tushar Shanbhag

Introducing the Windows Azure Service Management API

Today, we are releasing a preview of the Windows Azure Service Management API to help you manage your deployments, hosted services and storage accounts. This is a REST-based API which users can code against in their toolset of choice to manage their services.

API Details at a glance

• You can find the documentation (along with the rest of the Windows Azure documentation) here.
• This is a REST-based API which uses X509 client certificates for authentication. Users can upload any valid X509 certificate in .cer format to the Windows Azure developer portal and then use it as a client certificate when making API requests.
• The following operations are currently supported.
  • Deployments – Viewing, creating, deleting, swapping, modifying configuration settings, changing instance counts, and updating the deployment.
  • Listing and viewing properties for hosted services, storage accounts and affinity groups
• We’ve put together a small tool called csmanage.exe to help you interact with this API and manage your deployments. You can find csmanage here along with our other samples.

How do I get started?

The documentation has detailed information on this but here’s a quick starter.

1. The first step is to get hold of a valid X509 certificate with a key size of at least 2048 bits. One quick way is to use IIS 7 to generate a self-signed certificate. Another option is to use makecert.exe (which ships with the Windows SDK) and use a command like the below:
   makecert -r -pe -a sha1 -n "CN=Windows Azure Authentication Certificate" -ss My -len 2048 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" -sy 24 testcert.cer
2. The next step is to upload the .cer file to the developer portal to let Windows Azure know that it should trust the certificate for API operations on your projects. The portal now has a new section called “API Certificates” under the Account tab where one can do this.
3. Use the certificate from step  #1 for any API request you make. The csmanage tool is a handy way to play and explore the functionality offered by the API. For users rolling their own tools, almost all mainstream programming platforms have support for client certificates. .NET users should use the ClientCertificates property of System.Net.HttpWebRequest. We’ll also be publishing client libraries to simplify this task soon.

In the pipeline

Over the next few weeks, we’ll publishing a sample .NET client library and samples, all with source code, to show how to use the API’s functionality.  This API is currently in CTP form and users should expect changes as we improve the service based on feedback.

As always, we welcome any feedback. Play with the API and tell us what you think!

Congrats to Dennis Palmer, Winner of the Twilio + Windows Azure Developer Contest!

Hats off to Dennis Palmer, who won a Netbook for winning last week’s Twilio + Windows Azure Developer Contest for his Cloud Call Me application for Facebook! Cloud Call Me allows Facebook users to call friends using Twilio and Azure, while keeping phone numbers completely private. Read more about the contest, as well as a few words from Dennis on his development experience here: http://blog.twilio.com/2009/09/cloud-call-me-wins-the-twilio-windows-azure-developer-contest.html

Federal Government Embraces Cloud Computing; Outlines Long-term Cloud Computing Strategy

In a press event on Tuesday at NASA Ames Research Center in California, Federal Chief Information Officer (CIO) Vivek Kundra unveiled apps.gov, an online storefront for federal agencies to browse and purchase cloud-based IT services. The Obama administration has long touted cloud computing as an effective means to take advantage of technology for less money, and promises this first project should streamline IT costs, while also demonstrating a strong commitment to embracing innovation to tackle increasingly complex IT issues.
 
We at Microsoft are very excited about this announcement and what it means for the public sector AND the role of cloud computing  in the overall technology industry.  Amitabh Srivastava, SVP Windows Azure at Microsoft, who was present at the industry roundtable following the press event, put it this way, “if there was any doubt that the era of cloud computing is alive in government, Kundra put those doubts to rest today in his announcement. Microsoft feels the White House is taking the correct approach by making cloud services available to government agencies, which will ultimately better serve citizens by leveraging technology innovations to run their organizations at lower costs, procure information technology more easily, and in a way that reduces government's ecological footprint.  Microsoft looks forward to working with the federal government to make the cloud computing vision a reality.   Government customers today seek -- and deserve -- a broad set of technology choices and solutions that address their diverse needs, which in most cases include both on-premise and cloud computing scenarios. As we work together to meet these needs, the industry must do so with the highest standards of interoperability, manageability and security safeguards.”

Yes, as Amitabh notes, cloud computing has applications far beyond apps.gov, the federal government’s first cloud computing project.   Teresa Carlson, vice president, Microsoft Federal, recently wrote a blog post discussing the broad implications of cloud computing in the public sector that you should read to learn more about some of the work already underway: http://microsoftontheissues.com/cs/blogs/mscorp/default.aspx

Microsoft has also started a project to help government agencies and developers publish and interact with their data in Windows Azure.  Announced May 7, 2009, the Open Government Data Initiative (OGDI), led by the Microsoft Public Sector Developer Evangelism team, is a cloud-based approach to housing public government data in Windows Azure making it accessible in a programmatic manner via open standard protocols and application programming interfaces, such as Silverlight, Flash, JavaScript, PHP, Python, Ruby, mapping web sites, etc..  For more information, please go to: http://ogdisdk.cloudapp.net/Default.aspx

Get Started with Windows Azure TODAY!

Steve Marx To Talk about Cloud Computing at XIX GeneXus International Meeting in Montevideo, Uruguay Monday, 9/14/09