Who said 3 was the magic number? Microsoft previews new Azure SDK in 4 programming languages

Source:- theregister.co.uk

No more cloud-based DLL Hell or libraries snafus, vows Redmond beastie

Microsoft’s new code libraries for programming its Azure cloud address a significant problem for developers: the inconsistency between the huge numbers of supporting libraries.

The issue has arisen after the rapid development of new features on Azure over a stretch of several years. The new code libraries have started with four languages and four services. The supported languages are Python, Java, JavaScript and C#/.NET. The initial services are Azure Storage, Cosmos DB, Key Vault, and Event Hubs.

There is also a cloud-era variant of DLL Hell, where dependencies between libraries for different services can conflict so that developers have to juggle with various versions to find a set that work together.

Another issue is that different software teams have taken different approaches to designing their libraries, causing friction for coders.

“We have been learning what patterns and practices were critical to developer productivity around these services,” said Microsoft principal group software engineering manager Peter Marcu.

Marcu outlined several goals for the new SDK, including easy to use APIs, APIs that feel native to the target language and ecosystem, and a high standard of documentation and samples.

This last is a key requirement. Microsoft’s samples vary from those which are too simplistic to be of any use, to projects that are so large and complex that they obscure the basics of how to use an API (Application Programming Interface). In other cases, important information may be hidden in a blog post or forum discussion. It is not easy to get this right, but the intent is welcome.

Microsoft’s approach is to create a set of guidelines for each of the four languages, like that for .NET here. A point to note about the .NET guidelines is the company’s commitment to cross-platform:

Use of platform-specific or native code requires an exception from the review board … DO test that sample apps execute as expected on Linux, Windows, and macOS.
There is always a downside. In this case, it is compatibility. Marcu said:

For some cases we have had to make breaking changes to get to a better foundation. We believe aligning on that foundation will help meet the productivity goals outlined above, and once it’s set we intend to provide a high degree of compatibility. As a final note on compatibility, we’ve looked at the dependencies that we took and tried to minimize them as much as possible to reduce future incompatibilities and versioning complexities which should make upgrading libraries and using other pieces of software alongside these libraries easier.
Most Azure services also have a REST API which you can use with any language. Each upgrade to the REST API may introduce breaking changes, but often calls that specify the previous version of the API continue to work. This means that breaking changes may not be as bad as they sound: existing code still runs, until you need some feature which requires a newer version. In some cases newer APIs offer better performance too.

The REST API is also the key to supporting languages other than those on Microsoft’s list. If for example you want to call an Azure API from Google’s Dart, used by the popular Flutter framework, you will need to wrap the REST API.

Some languages may be added to the new Azure SDK later. Asked whether the SDK for Go will be brought under the Azure SDK umbrella, Marcu tweeted “Probably will at some point”.

There are hundreds of Azure services and it will be a long time before everything is covered by the Azure SDK, which is today only in preview.