I’ve been quite lax on the whole… posting thing. As usual. I found this post languishing in my drafts folder, and decided that anything that’s been in Drafts since August either needs to be published, or deleted.
I was thinking about what I’d written regarding updating applications for Azure, and realised I’d glossed over the future state and realising efficiency in the cloud.
Once organisations paying for resources on an hourly rate, and have eliminated some pretty major capital costs and operations, some of the costly procedural gaps in organisations become obvious. The time to deploy an update to the application, the ability to quickly roll back a failed change, and the manual work involved in maintaining the application on a regular basis all become obvious.
One of the best capabilities that you gain access to when moving to virtually any cloud platform is strong automation capabilities. If you haven’t been working with some level of automation yet, now’s the time to take a deep dive in and find out how much of your job you can replace with a small shell script or three.
Automation is sometimes conflated with DevOps, but let’s be clear – DevOps is more than automation. It’s fundamentally a cultural shift in how your IT Organisation operates. In today’s IT landscape, you need to be able to move faster than your competition. This isn’t a simple problem. Many pages have been written about the subject, and I’m not going to attempt to condense it into this blog post.
Automation can take a while to gain traction in organisations – small organisations can have trouble getting it off the ground without having people dedicated to the project, whereas larger organisations may have political or procedural challenges. Inertia is a huge problem, too – without upper management aggressively driving the project, it will likely fail . While you’re developing the process for your automation environment, take the opportunity to go through your code with an eye towards efficiency. When you’re paying for a server, the difference between 4 and 8 cores doesn’t seem like much, and as a result most companies over-provision. However, when you’re paying for a service, and the cost is instantly visible on a hour-by-hour basis, suddenly there’s a great business case for code optimisation.
Azure Automation provides a place where tasks can be run, on a schedule, as a service. This is different than having a Scheduled Tasks server, as the service understands and maintains its own availability – if a server underlying the service ceases to function properly, it will self-heal. With this, we’ve solved two problems: how to perform routine tasks, and how to make sure that the route tasks actually run. The last thing you want to do is turn one set of routine tasks into a different set of tasks. Azure Automation can store variables that your runbooks or scripts reference – which allows for the scripts to easily migrate between security domains. Simply configure the script to reference an Automation Credential, for example, and the script can migrate between development and production seamlessly. Automation is my go-to for replacing a wide variety of tasks, and it’s got huge cost saving potential – a lot of my clients keep dedicated VMs just to run scheduled tasks in their environment, something that is totally unnecessary.
Azure Automation also functions as a DSC Pull Server. PowerShell Desired State Configuration is Microsoft’s configuration management tool. The idea is that there are established modules used to configure the OS and applications, and the user can simply declare what the desired state is to be. For example, the user may wish to enforce Domain Membership and ensure IIS is not installed, and the DSC engine will read the provided configuration and determine how best to enforce it. The DSC Pull server functionality allows administrators to point to a given configuration in a central location, and update that configuration at will, and have a large degree of certainty that within a given timeframe, the servers that refer to the configuration will be updated. This can enable repeatable and reliable deployment and configuration.
A really-common use for Azure automation is VM cost management – resize or start/stop VMs depending on a variety of reasons, automatically. If load spikes between 6 and 10 am, it is possible to set up a script that resizes the VMs starting at 5am, without incurring downtime. Alternatively, you can configure non-production workloads to stop after work hours.
Automation is one of the most powerful tools you can use to modernise infrastructure management in Azure. If you’re not using it today, go give it a shot!