Azure .NET SDK: Q&A with Jeffrey Richter

Azure .NET SDK: Q&A with Jeffrey Richter

Recently Microsoft released a new version of its Azure .NET SDKs, available as a series of NuGet packages designed to provide a consistent and familiar interface to access Azure services from your .NET applications.

Recently Microsoft released a new version of its Azure .NET SDKs, available as a series of NuGet packages designed to provide a consistent and familiar interface to access Azure services from your .NET applications.

InfoQ interviewed Jeffrey Richter, a software architect on the Azure SDK team who worked on the design of the SDKs for various languages and many Azure services.

InfoQ: Why did Microsoft decide to launch a brand new .NET SDK for its Azure services?

Jeffrey Richter: There are many reasons for this. For starters, every Azure service team was responsible for its own SDK and this meant that they were all different and customers had to learn each SDK from scratch; there was no consistency. We’d like Azure to look like a holistic platform that customers enjoy using and we want customers to start using new Azure services easily and be productive

Second, we wanted the new SDKs to embrace cloud/distributed systems features such as cancellation, retries, and logging.

Third, we wanted the SDKs to have a sustainable architecture which allows features and changes to happen quickly without breaking existing customers. The HTTP pipeline we have enables a lot of this and, in fact, customers can extend this pipeline themselves and add their own features! For the older SDKs, we’ve had feature requests that we are just not able to accommodate in a non-breaking fashion due to the technical debt.

Fourth, we wanted to bring these same concepts to all SDK languages. Today, this includes .NET, Java, TypeScript, Python, C, C++, Go, Android, and iOS. And finally, we wanted a design that allows customers to easily diagnose their own problems. With distributed systems, many things can go wrong: network connections, credentials, timeouts, and so on. Our SDK design focuses heavily on mechanisms to help customers such as request ID generation, logging, distributed tracing, and error handling/messages.

InfoQ: In the blog post "Inside the Azure SDK Architecture", you've mentioned the possibility of adding custom policies to the HTTP pipeline. Can you give us a few possible scenarios where custom policies could be used?

Richter: Sure. Each SDK client library defines one or more XxxClient classes; each class knows how to talk to an Azure service. When constructing an XxxClient, you pass the service’s endpoint, credentials, and a set of options (like retry or logging options). The options are used to create an HTTP pipeline which is owned by that XxxClient object. All HTTP requests and responses go through this pipeline. The pipeline’s purpose is to apply consistent behavior to all XxxClient methods.

Yes, customers can create their own policy classes and insert instances of them into the pipeline. One example would be to implement client-side caching. The customer can insert a policy that sees that an HTTP request is being made, checks some local storage to see if the requested data is available and then simply returns it without communicating with the Azure service. If the data is not available, then the policy can call the Azure service, get the response, cache it locally (for a future request), and then return.

Another possible policy would be to implement the circuit-breaker pattern. We don’t have this today in our SDKs but we have considered adding this in the future. But a customer could easily implement this today if they choose. Customers could also create their own policies to support mocking and fault injection for reliability testing of their application.

InfoQ: You've mentioned the performance of the new SDK. Can you share some benchmarks of the new version compared to the previous versions?

Richter: Well, the performance of any given operation is overwhelmingly attributed to the service processing and network latency. By comparison, the client-side processing is minimal. That being said, the new SDK architecture ensures that XxxClient objects are sharable meaning that memory usage is less than the older SDKs and so there will be fewer garbage collections which improves performance.

Also, XxxClient objects are thread-safe with a lock only being taken when a credential updates its password or token. This allows a single XxxClient object to be used by multiple threads concurrently without any blocking; this also improves performance. The amount of performance improvement is dependent on your application and how it uses these XxxClient objects.

InfoQ: In your blog post, you've mentioned formalized patterns in order to increase the developer productivity. Can you explain what they are and give us a few samples?

Richter: Sure, the formalized patterns ensure that all the new Azure SDKs work the same way. Once you learn one of them, adopting another leverages your existing knowledge allowing you to focus on the new Azure service you’re interacting with. Here are a few of our formalized patterns:

  • Use an XxxClient class to have your application communicate with an Azure service.
  • Create the XxxClient using an endpoint, credentials, and options.
  • Each method on the XxxClient invokes one (sometimes more) operation on the Azure service.
  • Each method’s operation goes through the HTTP pipeline giving consistent behavior for retry, logging, etc.
  • Each method offers cancellation; important to prevent the client app from hanging due to a slow-responding service.

By the way, we publish all our Azure SDK guidelines for all our languages; you can find them here.

azure .net devops news

What is Geek Coin

What is GeekCash, Geek Token

Best Visual Studio Code Themes of 2021

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Create, Build, Deploy and Configure an Azure Function with Azure DevOps and Azure CLI

How to create, build, deploy and configure an Azure Function using Azure DevOps, Azure CLI and Powershell.

jQuery Ajax CRUD in ASP.NET Core MVC with Modal Popup

In this article, we’ll discuss how to use jQuery Ajax for ASP.NET Core MVC CRUD Operations using Bootstrap Modal. With jQuery Ajax, we can make HTTP request to controller action methods without reloading the entire page, like a single page application.

NET Core app using Docker, Azure DevOps, Azure Container Registry

This is a guide on how to use Azure DevOps to build and then publish a docker image as an Azure App Service, using Azure Container Registry.

Integration Testing for ASP.NET Core using EF Core Cosmos with XUnit and Azure DevOps

This article shows how integration tests could be implemented for an ASP.NET Core application which uses EF Core and Azure Cosmos. The database tests can be run locally or in an Azure DevOps build …

Updated: Announcing Azure DevOps Server 2020 RC1 | Azure DevOps Blog

Update: We received feedback in this blog and the Developer Community about an issue after upgrading from Azure DevOps Server 2019 Update 1.1 to Azure DevOps Server 2020 RC1.