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.
InfoQ: What would be the steps in order to move from previous versions to the new SDK? Is it possible to easily migrate or there is no compatibility at all?
Richter: Unfortunately, the new SDKs are not compatible with previous SDKs. There was just no way to accomplish all we wanted to without making significant changes. However, developers can continue to use old SDKs and also use the new SDKs. That is, write new code against the new SDKs and then, over time, modify the old code to use the new SDKs ultimately removing the technical debt of the old SDKs.
Again, a big focus of the new SDKs is to have a sustainable architecture which we can iterate on for decades to come. So, we do not expect to break customers again for the foreseeable future and therefore customers should have great confidence in the new SDKs.
About the Interviewee
Jeffrey Richter is a software architect on the Azure SDK team and helps on the design of the SDKs for various languages and many Azure services, and is a member on the Azure HTTP/REST API Review Board, which reviews HTTP APIs for Azure service teams looking for correctness, consistency, common patterns, versioning, sustainability, and idempotency. He is also on the Azure Breaking Change Review Board where he meets with Azure service teams that would like to make breaking changes to their service.