1

Azure Automation is a service for running scripts in the cloud, intended for the automation of administration tasks. While using it, I came across strangely outdated technologies being used under the hood. How can I live with them while staying productive and safe from security issues and acummulating technical debt?

PowerShell's current version is 7.5 and current LTS is 7.4 but the service does not allow using anything newer than 7.2. Azure PS (PowerShell module Az) current version is 13.3.0 and current LTS is 12.5.0 but the service does not allow using anything newer than 11.2.0. The docs on learn.microsoft.com are no longer available for such old versions of these technologies. In practice, I tried using a specific example from Azure PS docs related to Azure Storage but it failed with "Create Shared Access Signature is not supported while using OAuth." -- and similarly the types returned by many of the cmdlets are from different namespaces and assemblies than documented for the newer versions. I had to implement quite a bit more complicated solution that breaks best practices and even generates warnings about the dangers of storage account key use.

As far as I know and managed to find, the Azure Automation service nor the features I use are not deprecated but there is no way to update the aforementioned technologies used inside. The modules have a documented path for version change, but it serves mostly just as a downgrade path as only a fixed list of versions is available and the latest one of them was selected by default for me.

What are my options for dealing with this situation? I consider switching to a different service a last-resort solution as the service is quite commonly used and it fits my needs well overall. Also, my team already has an Azure subscription and attempts to use services outside Azure lead to a bureaucratic hell taking months to get approved. Currently, I try to extrapolate from current documentation based on what I see in the runtime (inspecting error messages, actually available types, etc.) but that feels pretty unproductive. I expect more from an actively supported service.

Palec
  • 125

1 Answers1

4

This is not an Azure or Powershell forum, so let me try to write an answer from a general software engineering point of view.

It is not uncommon when developing software that the platform one is bound to does not always support "the latest and the greatest" existing version of the components one would like to use. And when you run into that situation, you have basically three options:

  1. live with the restrictions of the older component versions

  2. try to update the platform

  3. choose a different platform

And it does not matter whether that "platform" is some Azure service, some operating system, or some programmable ERP or CAD system, the situation is often the same.

Option #3 is something you already investigated and want to avoid. Option #2 is something which is often not directly available, but maybe with the workaround mentioned in the comments by @freakish. This is very case specific and nothing for which I can tell you something general about.

So let's look at option #1, which is often better than developers feel about it. Of course, vendor marketing often pretends that older versions are crap and that you should only use their newest version, but in reality, there was a time when those "older components" came out and were "the latest and the greatest". Often, devs at that time managed it successfully to write some excellent software with it, so it could be still possible today.

Of course, there are some constraints for this option:

  • the older components as well as the platform must not be so old they become security risk
  • the older components must not miss a key feature which is absolutely essential for implementing some requirement and cannot be worked around

From what you wrote, the components in your case (Powershell 7.2 und PS-Az 11.2.0) still get vendor support (which hopefully means they get security updates). Heck, it is not uncommon the newest version of a component has more security flaws and more bugs than an older, mature version, when the vendor did not provide new features over the last years, but backported the important bug fixes to the older versions.

However, there is one key feature you really miss for those components, and that is their documentation. Still, I guess that can be worked around. As I mentioned in a comment, Powershell 7.2 docs are available by Microsoft, you just have to click yourself through the links to "prior versions" to find it. The PS Az module docs may not be so easy to find, still I guess when you just ask in a forum or directly contact the vendor and explain the situation, chances are not too bad you will get some docs which fit to that version.

Hence, though vendor advertising tells us to use and buy always the newest, most shiny component version, being somewhat conservative and live with an older version should always be an option to be considered seriously.

Doc Brown
  • 218,378