If you’re building applications that work against Azure services, it’s likely you’re using one or more of Microsoft’s . It’s an approach that makes sense, saves time, and keeps code under control. That’s because working directly against a Representational State Transfer API can be complex, as you have to construct the appropriate queries and parse the response JavaScript Object Notation.

Using an SDK that’s tailored to whatever language you’re using simplifies the process considerably, turning calls into methods and responses into objects. There’s no need to translate data formats or build complex query strings, reducing the risk of error. Microsoft has provided SDKs for Azure since the earliest days of its public cloud, adding new features to its libraries as they roll out.

That long history and Azure’s rapid growth has left the current set of SDKs somewhat out of phase with the way we build modern applications. While they work well enough, they’re not as easy to mix with current design thinking and don’t fit perfectly with the patterns and practices that are used in modern enterprise application development. When you’re launching a new service and getting it built into applications you must be fast. You don’t have time to sit down with the teams working on other SDKs for other aspects of the service and make your approaches consistent or understand how exactly your SDKs are being used.