When your business hinges upon remote workers and remote offices, secure connections, and lots of data manipulation… how do you deal with some of your folks being extra remote? Granted the internet in 2020 is very different from the internet in say 2008 and the world has grown ever smaller as a result… but distance and all of the congested, intervening, network hops that come with it are still a reality. Particularly for remote workers living on other continents that have to interface regularly with systems in the United States as a part of their job.
The two big headaches for remote workers in other countries connecting to offices in the US are latency and bandwidth. In the past there were only and handful of solutions, most involving long-term contracts with a telcom and lengthy, complicated setups. I would argue that MPLS still falls squarely in this camp. SD-WAN has certainly improved on all of the above but it’s still enough of a headache that it typically involves contract terms and conversations with sales “engineers.”
I would like to propose something different using Azure.
The current state of the world has caused some unique stresses on IT infrastructure. For IT departments servicing internal teams, remote access infrastructure in particular has felt the brunt of the blow. To that end, I spent a couple of weeks testing out enterprise VPN solutions.
I work on Azure Tenants that utilize multiple subscriptions in their design. I wanted to centralize my Azure Automation work and use a single Automation account. By default, I found that powershell scripts I fired off from Azure Automation work within the subscription that the Automation account was created within. But business requirements necessitate multiple subscriptions and MY requirements necessitate using a single Automation Account to simplify my life (and the lives of everyone else that I work with). A running joke is that, when it comes to IT, well-intention’d laziness is a virtue… We rebrand laziness as “simplicity,” “automation,” and/or “efficiency,” depending on the context of the conversation of course. I often say somewhat tongue-n-cheek that “you don’t want your IT department to be “busy” all the time.” An all-the-time overly busy IT department typically means that something was poorly planned and/or your network is being held together with spit and frayed ethernet cable. Anyhow, I digress…
With that groundwork laid, the goal is a Powershell automation script that can essentially “hop” subscriptions as needed. I also value modularity. Goodness knows that in the pursuit of laziness we should never do the same work twice except in the most extreme or dire circumstances. To that end, I wrote a simple function I could just drop into any script along with an additional parameter and now said script can be used across subscriptions…
Continuing on my journey up the Azure Automation mountain, I recently completed a simple AZ PowerShell script that takes several input parameters and scales UP or scales DOWN a given AzureSQL database instance depending on what time of day it is.
Before I go any further, if you are just getting started in Azure Automation, I wrote another article here which may help you avoid some of the headaches I ran into as part of my initial foray:
Azure Automation – Powershell – Getting it Working – Authentication the “Easy” Way -and- Ditching AzureRM
Azure has excellent auto-scaling parameters built-in for scaling App Services horizontally (i.e. “out” and “in”… adding or decreasing instance count). However for vertical scaling of AzureSQL services, you are pretty much left to your own devices.
I have an “okay” amount of experience using AZ Powershell to script and get things done in my Azure Subscriptions and with that in mind and the task set in front of me of auto-scaling our AzureSQL databases based on time of day (scale up before the busy hours, scale down when the quiet hours start) I turned to Azure Automation to get the work done.
Being an IT professional of several years, I did what we all do… I turned to Google and searched for scripts I could just steal, modify, and use (I am nodding at you right now…). However, if your want to use “AZ” Powershell instead of the deprecated “AzureRM”… I think the term is… “forgetaboutit.” The templates and examples that I found were either based on Powershell “Workflows” which I didn’t want to mess with and/or used the old AzureRM Powershell syntax. So I then turned to… Powershell ISE… and started writing.
I have been using Powershell to manage pieces of Azure on and off for about a year and half now. I had heard tell of Azure Automation but never really had a good reason to justify spending the time climbing that particular mountain (hill really…).
Then the request came through… let’s scale AzureSQL databases up and down based on time of day for a given project… If you have worked in Azure you know Microsoft has built in a fairly robust and relatively easy to use auto scale-out configuration interface for Azure App services. Not so for “up/down” scale operations (increasing/decreasing the size of a single-instance). Hence, my foray into Azure Automation.
I have done a fair bit of Azure Powershell scripting just using the ISE interface and keeping scripts on my desktop. I started out with “AzureRM” and migrated to “AZ” as Microsoft starting a couple of years ago pretty much said “AZ” is the future… switch now.
With that background in place, I will state that I found starting out on Azure Automation to be a bit of a bumpy ride. I wanted to hopefully save you the reader some of the time I spent chasing my tail…