This morning we released some great updates to Windows Azure. These new capabilities include:
All of these improvements are now available to use immediately (note: some are still in preview). Below are more details about them.
I’m excited today to announce the preview release of the new Windows Azure Cache Service – our latest service addition to Windows Azure. The new Windows Azure Cache Service enables you to easily deploy dedicated, high performance, distributed caches that you can use from your Windows Azure applications to store data in-memory and dramatically improve their scalability and performance.
The new Windows Azure Cache Service can be used by any type of Windows Azure application – including those hosted within Windows or Linux Virtual Machines, as well as those deployed as a Windows Azure Web Site and Windows Azure Cloud Services. Support for Windows Azure Mobile Services will also be enabled in the future.
You can instantiate a dedicated instance of a Windows Azure Cache Service for each of your apps, or alternatively share a single Cache Service across multiple apps. This later scenario is particularly useful when you wish to partition your cloud backend solutions into multiple deployment units – now they can all easily share and work with the same cached data.
Some of the benefits of the new Windows Azure Cache Service include:
You can easily create a new Cache Service by going to the Windows Azure Management Portal and using the NEW -> DATA SERVICES -> CACHE option:
In the screenshot above, we specified that we wanted to create a new Premium cache of 5 GB named “scottgucache” in the “North Europe” region. Once we click the “Create a New Cache” button it will take about a few minutes to provision:
Once provisioned, the cache will show up in the Windows Azure Management Portal just like all of the other Windows Azure services (Web Sites, VMs, Databases, Storage Accounts, etc) within our subscription. We can click the DASHBOARD tab to see more details about it:
We can use the cache as-is (it comes with smart defaults and doesn’t require changes to get started). Or we can also optionally click the CONFIGURE tab to manage custom settings - like creating named cache partitions and configuring expiration behavior, evicition policy, availability settings (which means a cached item will be saved across multiple VM instances within the cache service so that they will survive even if a server crashes), and notification settings (which means our cache can call back our app when an item it updated or expired):
Once you make a change to one of these settings just click the “Save” button and it will be applied immediately (no need to redeploy).
Now that we have created a Cache Service, let’s use it from within an application.
To access the Cache Service from within an app, we’ll need to retrieve the endpoint URL for the Cache Service and retrieve an access key that allows us to securely access it. We can do both of these by navigating to the DASHBOARD view of our Cache Service within the Windows Azure Management Portal:
The endpoint URL can be found in the “quick glance” view of the service, and we can retrieve the API key for the service by clicking the “Manage Keys” button:
Once we have saved the endpoint URL and access key from the portal, we’ll update our applications to use them.
Using the Cache Service within a .NET or ASP.NET applications is easy. Simply right-click on your project within Visual Studio, choose the “Manage NuGet Packages” context menu, search the NuGet online gallery for the “Windows Azure Caching” NuGet package, and then add it to your application:
After you have installed the NuGet Windows Azure Caching package, open up your web.config/app.config file and replace the cache Service EndPoint URL and access key in the dataCacheClient section of your application’s config file:
Once you do this, you can now programmatically put and get things from the Cache Service using a .NET Cache API with code like below:
The objects we programmatically add to the cache will be automatically persisted within the Cache Service and can then be shared across any number of VMs, Web Sites, Mobile Services and Cloud Services that are using the same Cache Service instance. Because the cache is so fast (retrievals take on average about 1ms end-to-end across the wire and back) and because it can save 100s of GBs of content in-memory, you’ll find that it can dramatically improve the scalability, performance and availability of your solutions. Visit our documentation center to learn more about the Windows Azure Caching APIs.
The new Windows Azure Cache Service also comes with a supported ASP.NET Session State Provider that enables you to easily use the Cache Service to store ASP.NET Session State. This enables you to deploy your ASP.NET applications across any number of servers and have a customer’s session state be available on any of them regardless of which web server the customer happened to hit last in the web farm.
Enabling the ASP.NET Session State Cache Provider is really easy. Simply add the below configuration to your web.config file:
Once enabled your customers can hit any web server within your application’s web farm and the session state will be available. Visit our documentation center to learn more about the ASP.NET session state provider as well as the Output caching provider that we also support for ASP.NET.
Once your Cache Service is deployed, you can track the activity and usage of the cache by going to its MONITOR tab in the Windows Azure Management Portal. You can get useful information like bandwidth used, cache miss percentage, memory used, read requests/sec, write requests/sec etc. so that you can make scaling decisions based on your real-world traffic patterns:
You can also customize the monitoring page to see other metrics of interest instead of or in addition to the default ones. Clicking the “Add Metrics” button above provides an easy UI to configure this:
If you need to scale your cache due to increased traffic to your application, you can go to the SCALE tab and easily change the cache offering or cache size depending on your requirements. For this example we had initially created a 5GB Premium Cache. If we wanted to scale it up we could simply expand the slider below to be 140GB and then click the “Save” button. This will dynamically scale our cache without it losing any of the existing data already persisted within it:
This makes it really easy to scale out your cache if your application load increases, or reduce your cache size if you find your application doesn’t need as much memory and you want to save costs.
The new Windows Azure Cache Service enables you to really super-charge your Windows Azure applications. It provides a dedicated Cache that you can use from all of your Windows Azure applications – regardless of whether they are implemented within Virtual Machines or as Windows Azure Web Sites, Mobile Services, or Cloud Services. You’ll find that it can help really speed up your applications, improve your app scalability, and make your apps even more robust.
Review our Cache Service Documentation to learn more about the service. Visit here to learn more about more the details about the various cache offering sizes and pricing. And then use the Windows Azure Management Portal to try out the Windows Azure Cache Service today.
Three weeks ago we released scheduled AutoScale support for Cloud Services. Today, we are adding scheduled AutoScale support to Web sites and Virtual Machines as well, and we are also introducing support for setting up different time schedule rules depending on whether it is a weekday or weekend.
Just like for Cloud Services, you can now go to the Scale tab for a Virtual Machines or a Web site, and you’ll see a new button to Set up schedule times:
Scheduled AutoScale works the same way now for Web Sites and Virtual Machines as for Cloud Services. You can still choose to scale the same way at all times (by selecting No scheduled times), but you can now click the “Set up schedule times” dialog to setup scale rules that run differently depending on the time of day:
Once you define the start and stop of the day using the dialog above, you can then go back to the main scale tab and setup different rules for each time segment. For example, below I’ve setup rules so that during Week Days we’ll have between 2 and 5 small VMs running for our Web Site. I want AutoScale to scale-up/down the exact number depending on the CPU percentage of the VMs:
On Week Nights, though, I don’t want to have as many VMs running, so I’ll configure it to AutoScale only between 1 and 3 VMs. All I need to do to do this is to change the drop down from “Week Day” to “Week Night” and then edit a different set of rules and hit Save:
This makes it really easy to setup different policies and rules to use depending on the time of day – which can both improve your performance during peak times and save you more money during off-peak times.
Previously, we supported an instance count graph on the scale tab so you can see the history of actions for your service. With today’s release we’ve improved this graph to now show the sum of CPU usage across all of your instances:
This means that if you have one instance, the sum of the CPU can go from 0 to 1, but if you have three instances, it can go from 0 to 3. You can use this to get a sense of the total load across your entire role, and to see how well AutosSale is performing.
Finally, we’ve also improved the Operation Log entry for AutoscaleAction: it now shows you the exact Schedule that was used to scale your service, including the settings that were in effect during that specific scale action (it’s in the section called ActiveAutoscaleProfile):
With today’s release you can now configure Windows Azure Web Sites to write HTTP logs directly to a Windows Azure Storage Account. This makes it really easy to persist your HTTP logs as text blobs that you can store indefinitely (since storage accounts can maintain huge amounts of data) and which you can also use to later perform rich data mining/analysis on them.
To enable HTTP logs to be written directly to blob storage, navigate to a Web Site using the Windows Azure Management Portal and click the CONFIGURE tab. Then navigate to the SITE DIAGNOSTICS section. Starting today, when you turn “Web Server Logging” ON, you can choose to store your logs either on the file system or in a storage account (support for storage accounts is new as of today):
When you choose to keep your web server logs in a storage account, you can specify both the storage account and the blob container that you would like to use by clicking on the green manage storage button. This brings up a dialog that you can use to configure both:
By default, logs stored within a storage account are never deleted. You can override this by selecting the Set Retention checkbox in the site diagnostics section of the configure tab. You can use this to instead specify the number of days to keep the logs, after which they will be automatically deleted:
Once you’ve finished configuring how you want the logs to be persisted, and hit save within the portal to commit the settings, Windows Azure Web Sites will begin to automatically upload HTTP log data to the blob container in the storage account you’ve specified. The logs are continuously uploaded to the blob account – so you’ll quickly see the log files appear and then grow as traffic hits the web site.
The HTTP log files are persisted in a blob container using a naming scheme that makes it easy to identify which log file correlates to which activity. The log format name scheme is:
The HTTP logs themselves are plain text files that store many different settings in a standard HTTP log file format:
You can easily download the log files using a variety of tools (Visual Studio Server Explorer, 3rd Party Storage Tools, etc) as well as programmatically write scripts or apps to download and save them on a machine. Because the content of the files are in a standard HTTP log format you can then use a variety of tools (both free and commercial) to parse and analyze their content.
For more advanced scenarios, you can also now spin up your own Hadoop cluster using the Windows Azure HDInsight service. HDInsight enables you to easily spin up, as well as quickly tear down, Hadoop clusters on Windows Azure that you can use to perform MapReduce and analytics jobs with. Because HDInsight natively supports Windows Azure Blob Storage, you can now use HDInsight to perform custom MapReduce jobs on top of your Web Site Log Files stored there. This provides an even richer way to understand and analyze your site traffic and obtain rich insights from it.
Today’s release adds some improvements to the Windows Azure OPERATION LOGS feature (which you can now access in the Windows Azure Portal within the MANAGEMENT SERVICES section of the portal). We now support filtering based on several additional fields: STATUS, TYPE and SERVICE NAME. This is in addition to the two filters we already support – filter by SUBSCRIPTION and TIME.
This makes it even easier to filter to the specific log item you are looking for quickly.
Today’s release includes a bunch of great features that enable you to build even better cloud solutions. If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today. Then visit the Windows Azure Developer Center to learn more about how to build apps with it.
Hope this helps,
P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu