The first thing I had the opportunity to work on when I joined the Azure team was something that I’m excited to show off today. I demonstrated the early bits of the Azure Management Libraries at the TechEd Australia Developer kick-off session, and now that they’re out I’m really excited to walk you through getting started with their use. This post will sum up what the Azure Management Libraries are and why you should care to take a peek at them, and then I’ll dive into some code to show you how to get started.
What are these libraries you speak of?
With this release, a broad surface area of the Azure cloud infrastructure can be accessed and automated using the same technology that was previously available only from the Azure PowerShell Cmdlets or directly from the REST API. Today’s initial preview includes support for hosted Cloud Services, Virtual Machines, Virtual Networks, Web Sites, Storage Accounts, as well as infrastructure components such as affinity groups.
We’ve spent a lot of time designing natural .NET Framework APIs that map cleanly to their underlying REST endpoints. It was very important to expose these services using a modern .NET approach that developers will find familiar and easy to use:
- Supports Portable Class Library (PCL), which targets apps that are built for .NET Framework 4.5, Windows Phone 8, Windows Store, and Silverlight
- Ships as a set of focused NuGet packages with minimal dependencies to simplify versioning
- Supports async/await-based task asynchrony (with easy synchronous overloads)
- Has a shared infrastructure for common error handling, tracing, configuration, and HTTP pipeline manipulation
- Is factored for easy testability and mocking
- Is built on top of popular libraries such as HttpClient and Json.NET
These packages open up a rich surface area of Azure services, giving you the power to automate, deploy, and test cloud infrastructure with ease. These services support Azure Virtual Machines, Hosted Services, Storage, Virtual Networks, Web Sites and core data center infrastructure management.
As with any good SDK, it helps to know how you could get started using it by taking a look at some code. No code should ever be written to solve a problem that doesn’t exist, so let’s start with a decent, but simple, problem statement:
I have this process I run as in Azure as a Worker Role. It runs great, but the process it deals with really only needs to be run a few times a week. It’d be great if I could set up a new service, deploy my code to it, then have it run. Once the process finishes it’d be even better if the service could “phone home” so it could be deleted automatically. I sometimes forget to turn it off when I’m not using it, and that can be expensive. It’d be great if I could automate the creation of what I need, then let it run, then have it self-destruct.
Until this preview release of the Azure Management Libraries (WAML for short hereafter, though this is notan official acronym, I’m just being lazy), this wasn’t very easy. There’ve been some great open-source contributions to answering the .NET layer in managing Azure services and their automation, but nothing comprehensive that delivers C# wrappers for nearly all of the Azure Management REST APIs. If you needed to use these API to generate your own “stuff” in Azure, you pretty much had to write your own HTTP/XML code to communicate with the REST API. Not fun. Repetitive. Boring, maybe, after you do a few dozen out of hundreds of API methods.
Getting the Management Libraries
I decided to do this work in a simple WPF application I’ll run on my desktop for the time being. I’ll want to run it as long-running app or service later, but for now this will work just fine. Since I’ve got a Azure Cloud Service with a Worker Role I’ll want to run in the cloud, I’ve just added all three projects to a single solution, which you’ll see below.
You probably noticed that I’m preparing to add some NuGet packages to the WPF application. That’s because all of the Azure Management Libraries are available as individual NuGet packages. I’m going to select the Microsoft.WindowsAzure.Management.Libraries package, as that one will pull everything in the Management Libraries into my project. If I wanted to manage one aspect of Azure rather than all of it, I’d reference one of the more specific packages, like Microsoft.WindowsAzure.Management.WebSites, which provides management functionality specific only to the Azure Web Sites component.
Once I’ve referenced the NuGet packages, I’m ready to set up client authentication between my WPF application and the Azure REST APIs.
The first implementation we’ve built out for authenticating users who are using WAML and Azure is a familiar one – using X509 Certificates. Integrated sign-in was added recently in SDK 2.2 to Visual Studio and to PowerShell, and we’re working on a solution for this in WAML, too. With this first preview release we’re shipping certificate authentication, but stay tuned, we’re doing our best to add in additional functionality.
Don’t panic. We’ve made this so easy even I can do it.
I’m not going to go deep into a discussion of using certificate-based authentication in this post. In fact, I’m going to be as brute-force as possible just to move into the functional areas of this tutorial. I’ll need two pieces of information to be able to log into the Azure API:
- A subscription ID
- A management certificate
I obtained these values from one of my publish settings files. The XML for this file is below.
With the key and the subscription ID in my code later on, I can call the GetCredentialsmethod below that returns an instance of the abstract class, SubscriptionCloudCredentials, we’re using to represent a credential instance in the Management Library code. That way, if I add single-sign on later it’ll be easy for me to replace the certificate authentication with something else. The code the the CertificateAuthenticationHelper class from my sample code is below:
Now I’ll write a controller class that’ll do the work between my WPF application and the Management Libraries – a convenience layer, in a sense.
Management Convenience Layer
To map out all the various parameters I’ll have in my workflow I’ve created the ManagementControllerParameters class shown below. This class will summarize all of the pieces of data I’ll need to create my services and deploy my code.
Then, I’ll create a class that will provide convenience functionality between the UX code and the Management Library layer. This code will make for cleaner code in the UX layer later on. Note the constructor of the code below. In it, two clients are being created. One, the StorageManagementClient, will provide the ability for me to manage storage accounts. The other, the ComputeManagementClient, provides the ability for me to work with most of the Azure compute landscape – hosted services, locations, virtual machines, and so on.
For the purposes of explaining these steps individually, I've created a partial class named ManagementControllerthat's spread across multiple files. This just breaks up the code into functional units to make it easier to explain in this post, and to provide for you as a public Gist so that you can clone all the files and use them in your own code.
Now, let’s wire up some management clients and do some work.
Create a New Storage Account using the Storage Management Client
The first thing I’ll need in my deployment strategy is a storage account. I’ll be uploading the .cspkg file I packaged up from a Cloud project in Visual Studio into a Azure blob. Before I can do that, I’ll need to create an account into which that package file can be uploaded. The code below will create a new storage account in a specified region.
Once the storage account has finished creating, I'm ready to use it. Given that I'll need a connection string to connect my application (and my soon-to-be-created cloud service) to the storage account, I'll create a method that will reach out to the Azure REST APIs to get the storage account's connection keys. Then, I'll build the connection string and hand it back to the calling code.
Now that the storage account has been created I'll create my cloud service and publish my package up to Azure.
Create and Deploy a new Cloud Service using the Compute Management Client
The call to create a cloud service is surprisingly simple. All I need to do is to provide the name of the cloud service I intend on creating and the region in which I'd like it to be created.
Finally, all I need to do to deploy the cloud service is to upload the cloud service package file I created in Visual Studio to a blob, then call the REST API. That call will consist of the blob URI of the package I uploaded to my storage account, and the XML data from the cloud project's configuration file. This code will make use of the Azure Storage SDK, which is also available as a NuGet package.
Now that all the code's written to create my Azure application, I'll write some code to destroy it once it wraps up all of the work it was designed to do.
Deleting Assets from Azure
Deleting assets using the Azure Management Libraries is as easy as creating the assets. The code below cleans up the storage account I created. Then, it deletes the cloud service deployment and the cloud service altogether.
With all the convenience code written at this point, the user experience code should be relatively painless to write next.
The User Experience
The UX for this application is relatively simplistic. I'm just providing a pair of buttons on a WPF form. One will create the assets I need in Azure and perform the deployment. The other will delete the assets from Azure. XAML code for this UX is below. It isn't much to look at but the idea here is to keep this simple.
The codebehind for the UX is also just as easy. In the Create button-click event, I create a new ManagementController instance, providing it all of the parameters I'll need to create the application's components in the Azure fabric. Then I call all of the methods to created everything.
I also handle the Delete button-click by cleaning up everything I just created.
I could modify this code to use the Windows Storage SDK to watch a storage queue on the client side. When the cloud service is finished doing its job, it could send a message into that queue in the cloud. The message would then be caught by the client, which would in turn call the Cleanup method and delete the entire application.
Endless Automation Possibilities
The Azure Management Libraries provide a great automation layer between your code and Azure. You can use these libraries, which are in their preview release as of this week, to automate your entire Azure creation and destruction processes. In this first preview release, we're providing these management libraries for our compute and storage stacks, as well as for Azure Web Sites. In time, we'll be adding more functionality to the libraries. The goal is to give you automation capabilities for everything in Azure.
We're also excited about your feedback and look forward to suggestions during this preview phase. Please try out the Management Libraries, use them in your own experimentation, and let us know what you're using them to facilitate. If you have ideas or questions about the design, we're open to that too. The code for the libraries, like many other things in the Azure stack, are open source. We encourage you to take a look at the code in our GitHub repository.
This Team is Astounding. I am Not Worthy.
Jeff Wilcox’s team of amazing developers have put in a lot of time on the Management Libraries and today we’re excited to share them with you via NuGet. Jeff’s build script and NuGet wizardry have been a lot of fun to watch. The pride this team takes in what it does and the awesomeness of what they’ve produced is evident in how easy the Management Libraries are to use. We think you’ll agree, and welcome your feedback and stories of how you’re finding ways to use them.