Vendors: Why We Do Not Need Your PowerShell SDKs

My recent post about things I dislike about PowerShell provoked some interesting reactions (see the comments). Several readers argued that PowerShell is not supposed to be a full-blown programming language but a kind of super-advanced shell scripting tool.

User Comments

Some examples:

PowerShell is the next generation command line

Powershell is glue. Not bulk code.

Scripting Tool - or Language?

I am not sure what its creators want it to be, but for obvious reasons PowerShell cannot compete with languages like C# or C++. And that is OK! There most definitely is a need and a place for an advanced systems management & automation tool. That is more or less what I see PowerShell as. And it is pretty good at that, too!

What is Wrong With PowerShell SDKs?

Nothing is wrong with PowerShell SDKs, except for when the PowerShell SDK is the only way to integrate with a product.

Integration is a key requirement for developers and admins. Both need ways to access a product’s functionality from the tools of their trade. The difference is that the former use languages like C++, C# or Java while the latter use PowerShell. A PowerShell “SDK” only caters to the latter. Developers have no clean way of integrating with a PowerShell only SDK (please do not tell me to call PowerShell from my C++ service).

What is an SDK Anyway?

According to Stack Overflow an API is an interface exposing the functionality, while an SDK is implementation tooling that uses the interface and facilitates using it.

That definition explains it all. Tooling is good, but please, pretty please, expose the underlying interface, too!

The Right Way

Native API

The proper way to build SDKs is a layered approach: you first expose a native API that is easily accessible from typical programming languages. A C-style API is the traditional way to do it and is the natural thing to do for products built in C/C++. A REST API exposing methods via HTTP would be appropriate for products written using web technologies.

Console

Next you (as the vendor) make sure to build your consoles using only the publicly available API documentation. This guarantees that a) the documentation is good enough to actually serve its purpose and that b) the API is complete, covering all the functionality of your product.

PowerShell and Command Line Tools: The SDK

Finally, you write PowerShell cmdlets that talk to your native API and make the product’s functionality available to people who script and automate. This is also the way to build standalone executables that expose (all or specific parts of) the functionality.

Why Not the Other Way Around?

Why not build consoles based on the PowerShell SDK? Performance! Citrix Studio, to name an example, would (hopefully) not be as unbearably slow as it is today if it interfaced directly with low-level APIs.

Remember: you can always build a perfect PowerShell cmdlet with a C API. But you can never build even a mediocre C API with a PowerShell cmdlet.

Who Am I Talking About

Yes, you, Citrix! You have neglected developer APIs for far too long. If you do not want us to ignore your products and turn to the competition you better move quickly!

There are probably others guilty of the same crime that I simply am not aware of. A Google search for PowerShell SDK yields 518,000 results.

Summary

PowerShell cmdlets exposing a product’s functionality are good! But they must not be the only way for a developer to integrate with a product. A lower-level API of some kind that is easily consumable from languages like C++ and C# is badly needed, too! Remember: SDK stands for Software Development Kit. As of October 2014 PowerShell is not even in the top 100 of the most popular programming languages…