My name is Laurent and I recently moved from France to join the Python team at Microsoft. Along with the rest of our team, I am responsible for maintaining the Azure Python SDK, and we are glad to announce the 2.0.0 RC2 version! This is a major step for Python on Azure and the product of several teams collaborating in Microsoft to establish a solid foundation for the future of the Python SDK. This post will give you an idea of what you can expect of this release.

Once upon a time

Let’s go back in the past, when the 0.x versions of the Azure Python SDK were released using the Azure Service Management API (a.k.a. ASM). This Python SDK was written by hand against each Azure service. Moreover, ASM was not strict on the URL and answer format of the REST API. For instance, some services handled only JSON, some others XML or Atom/XML format. It was very difficult to work in this situation to be able to scale the SDK as fast as Azure grew up. Because of these issues you needed to use C# to be on the edge of the latest Azure features.

The new Azure Resource Management (a.k.a ARM) REST API is built over a more common approach for each Azure service. Each service is associated with a provider and you can group several service components into a resource group. This also allows you to deploy any service using a JSON template. And since this internally uses the same REST APIs, every new service has automatic template support. The ARM template website is a gold mine for every Azure addict.

Since ARM is a common framework, which comes with a stronger model — URL patterns and HTTP responses are more consistent than ASM — it’s now possible to describe a meta-model of each service REST API, and then use this meta-model to generate the SDK. The first attempt gave the Azure Python SDK 1.x series, but it was not powerful enough and was abandoned.

From this first experiment, we learned and chose to use the Swagger format to describe all our REST API models. We also decided, at Microsoft, to create our own Swagger based code generator, called Autorest, to have the flexibility we wanted to provide the best SDK for our users. Obviously Autorest is Open Source!

The really important point here is that now, every SDK (even C#) will use the generator to build their SDK. Autorest is indeed capable of generation of C#, Python, Java, Ruby, NodeJS and soon PHP. Autorest is available in Visual Studio (as a reminder, don’t forget that Visual Studio is Python friendly) or can be run easily on Linux using Mono.

What about Python specifically?

The Azure Python SDK 2.0.0 RC2 is the first Python release from Autorest. It provides supports for

• Authorization Resource Management : permissions, subscriptions, roles and more
• CDN Resource Management : profiles, endpoints creation and more
• Compute Resource Management : virtual machines, availability sets and more
• Apps:
  • Logic Apps Resource Management : workflow and job management
  • Web Apps Management : App Service Plan, web sites, certificate, domains and more
• Network Resource Management : Application Gateways, Express route, Load balancers, virtual networks, public ip, subnets and more
• Notification Hubs Resource Management : Namespaces, hub creation/deletion and more
• Redis Cache Resource Management : create cache and more
• Resource Management is separated in four clients:
  • resources : create resource groups, register providers, do deployments and more
  • features : manage features of provider and more
  • locks : manage resource group lock and more
  • subscriptions : manage subscriptions and more
• Scheduler Management : create job collections, create job and more
• Storage Resource Management : create storage accounts, list keys, and more
• Azure Active Directory Graph RBAC : manage users, applications and more

You can found it as usual on PyPI, compatible with Python 3.5, 3.4, 3.3 and 2.7. You can install the whole azure meta-package or directly one specific service (i.e. azure-mgmt-compute).

We have some examples on how to use the SDK in our ReadTheDocs website.

Roadmap

First of all, the version is tagged as a Release Candidate. Why is that? Because in our team we care about quality of the product we ship. We trust in unit testing, continuous integration and coverage report. And we did not achieve the level of testing we estimate necessary to tag this SDK as stable. We will tag it as stable “when it’s ready”. Quality over quantity.

What kind of improvements can you expect for the SDK? Direct improvements follow two axes:

1. Autorest enhancement. Each simple new enhancement in the Autorest software can be provided to every service client in the SDK at the same time. One of the key feature that interests us is Python 3.5 async/await which is perfectly suitable for a cloud SDK. We also want to try to find the right balance between homogeneity between the others language SDK and the Pythonic way to write code, so that it feels natural to Python developers.
2. Swagger files enhancement. Each team works in parallel in their service Swagger files. Some service which are not available now will be available soon since they are currently in progress (DNS, Datalake or Search). This is also the central way for all language to ask for new service coverage (KeyVault, SQL Management,…)

There is currently no specific dated roadmap for Autorest new features. For the Swagger part, we would like to publish any new library as soon as we think that the Swagger file is at least functional as a preview version. Please feel free to ask for new features on our issue tracker (we will dispatch to the Autorest tracker as necessary) and to check/ask for new Azure service in the Swagger repo.

In addition, we are currently working on the automation process from the Swagger files to the SDK code. This would allow everyone who wants to contribute to every SDK at the same time to:

• Do a fork of the Swagger repo and a fork of the Python repo (or any other language you are interested in to test).
• Commit a Swagger modification, and (using Travis) the Python code will be automatically generated in a new branch in your SDK fork for you to test
• Submit a PR to the Swagger repo
• Et voilà!

Follow our blog for a detailed post about how to use this automation yourself soon!

Summary

With Azure Python SDK 2.0.0 generation, we provide a solid foundation based on the well-established Swagger format and a strong investment in the Autorest tool to scale the Python SDK over each Azure services. This provides:

• More consistency between the services
• Faster releases and updates once a new service is created to get the SDK
• An easy way to contribute to not only Python but all SDK (writing Swagger files)

And don’t forget, Microsoft Build is on this week in San Francisco, and we will be there with a booth and some talks. Come say hi! We’d love to meet you and hear how you’re using Python.