Far be it for a developer geek like me complain about new toys to play with, but the breakneck rate of Azure changes is starting to make my greying old head spin. At the recent Build event Microsoft proudly touted that there had been more than 500 releases on Azure in the preceding 12 months. While the crowd may applaud Microsoft’s new found agility, is 500 releases really manageable? Would you want to maintain and support a massive cloud based system that changed nearly twice a day? Here are the problems I’ve encountered with the sheer volume of change in Azure.
Documentation is out of date
With changes being made so quickly it’s very difficult to keep documentation up to date. Often you’ll find a document on MSDN that references screens that are significantly different or entirely gone. Google is making the situation worse by surfacing articles in searches that while less than a year old are already out of date. For example if you do a Google search for “azure web app scalability” the second item on the list is a document from 2014 entitled “Best Practices: Windows Azure Web Sites“. In this article they reference using Azure Cache Service for scalability with links to the documentation for Azure Cache Service on MSDN. But the Azure Cache Service is now no longer supported in the portals and developers are being urged to use Redis Cache instead included on the very document that the original article linked to. Several weeks ago I created a mobile service from the original Azure Management Portal. After creation I downloaded the starter code only to find that it wouldn’t compile. It was using Nuget references that were so old they didn’t know about the latest .NET Framework. Of course this might be fixed now, which is sort of the point.
Which Portal do we use?
Another major pain that if not caused by all the changes it certainly being made worse by it is the differences between features between the Azure Management Portal (old) and the Azure Preview Portal (new). Many features are only supported in one or the other portal and not both and many features that are supported in both behave differently in each portal. For example if you create a Web App in the Azure Management Portal there is no way to assign the Web App to a Resource Group, however if you go to the Azure Preview Portal you’ll see that it did in fact get assigned to one. And if you want to add Azure Active Directory Authentication to your web app, you can do that in the Preview Portal but then you have to go back to the Azure Management Portal to add the app to AAD and get the client id/secret. Are all of the developers in Microsoft so busy adding new features to Azure that they can’t get the old ones moved over to the new portal?
When all else fails, Powershell to the rescue
Another frustrating result of the level of change in Azure is that some new features aren’t supported by ANY portal. In those cases you have to resort to using PowerShell commandlets. One example I’ve had the need to use lately is that you can create a storage account for files in the portal but if you want to set up a file share so that your other services can access the files on that storage account you have to use the “New-AzureStorageShare” commandlet. Many other features are supported only by PowerShell and require a series of commands issued with just the right options to be successful.
In the long run, I do believe that the changes Microsoft is making in Azure are improving the product in leaps and bounds and as a developer I’m happy when I read about every new feature. But boy are my legs tired trying to keep up with them!